Question

Is there some optimal value for ConcurrencyLevel beyond which ConcurrentHashMap’s performance starts degrading?

If yes, what’s that value, and what’s the reason for performance degradation? (this question orginates from trying to find out any practical limitations that a ConcurrentHashMap may have).

Answer 1

The Javadoc offers pretty detailed guidance:

The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing.

The table is internally partitioned to try to permit the indicated number of concurrent updates without contention. Because placement in hash tables is essentially random, the actual concurrency will vary. Ideally, you should choose a value to accommodate as many threads as will ever concurrently modify the table. Using a significantly higher value than you need can waste space and time, and a significantly lower value can lead to thread contention. But overestimates and underestimates within an order of magnitude do not usually have much noticeable impact. A value of one is appropriate when it is known that only one thread will modify and all others will only read.

To summarize: the optimal value depends on the number of expected concurrent updates. A value within an order of magnitude of that should work well. Values outside that range can be expected to lead to performance degradation.