ConcurrentHashMap locking

Question

I have read somewhere that in ConcurrentHashMap, the whole map object is not locked and instead a lock is made on a portion of the Map.

Can somebody elaborate when does locking come into the picture?

Is it right that while reading the Map there is no locking involved in it but while updating it only locking is used?

this article should help: http://www.ibm.com/developerworks/java/library/j-jtp08223/ — yegor256, May 14 '12 at 18:42
The [javadoc](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html) is pretty detailed in explaining the implementation. — trutheality, May 14 '12 at 18:44

score 26 · Accepted Answer · edited Aug 19 '18 at 00:24

26

Yes, ConcurrentHashMap uses a multitude of locks (by default, 16 of them), each lock controls one segment of the hash.

When setting data in a particular segment, the lock for that segment is obtained.

When getting data, a volatile read is used. If the volatile read results in a miss, then the lock for the segment is obtained for a last attempt at a successful read.

edited Aug 19 '18 at 00:24

Alex R

11,364
15
100
180

answered May 14 '12 at 18:43

Tim Bender

20,112
2
49
58

1

I didn't get "if the If the volatile read results in a miss, then the lock for the segment is obtained for a last attempt at a successful read". Can you please explain little in details? – Anand May 14 '12 at 18:53
1

@anand According to the JMM it is possible the volatile write of a field in the constructor may be visible to threads after the object finishes construction and is visible to other threads (this is not true for final fields). The lock he refers to will ensure happens-before ordering of that volatile write wrt other reads. Note: This was able to happen, however may never have and I've read in Java 6 never can - there was talk of just removing it because of all the confusion. – John Vint May 14 '12 at 18:57
2

And just to make clear constructor completing refers to the entry of the bucket. – John Vint May 14 '12 at 18:59

Bohemian · Answer 2 · 2012-05-14T19:10:23.277

Locking is minimized as much as possible while still being thread-safe.

To explain "part of the Map is locked", this means that when updating, only a "1/concurrencyLevel" of the Map (based on a hash of the key) is locked. This means that two updates can still simultaneously execute safely if they each affect separate "buckets", thus minimizing lock contention and so maximizing performance.

More importantly, trust the JDK implementation - you shouldn't have to worry about implementation details in the JDK (for one thing, it may change from release to release). Rather, just focus on writing your code.

score 2 · Answer 3 · answered Dec 29 '17 at 10:15

ConcurrentHashMap use Reentrant Lock mechanism. ConcurrentHashMap uses segments instead of buckets and when new record get insert lock will get acquire only on segment not the complete list of segments. So here idea makes its clear that multi level lock will get acquire on the same.

As no concurrency level has been set explictity, the ConcurrentHashMap gets divided into 16 segments. And each segment acts as an independent HashMap.

There is no lock applied on read operation in ConcurrentHashMap.

ConcurrentHashMap locking

3 Answers3

Linked