Reputation: 21310
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?
Upvotes: 19
Views: 25403
Reputation: 20442
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.
Upvotes: 27
Reputation: 3531
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.
Upvotes: 2
Reputation: 424953
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.
Upvotes: 8