Key level locking in ConcurrentHashMap

Question

I understand that the ConcurrentHashMap uses bucket level locking instead of locking the entire map object on modify operations. This allows two threads trying to modify keys in different buckets to make the modification simultaneously. But if threads are trying to modify two different keys in the same bucket then only one will be allowed at a time.

I want to understand, what is the challenge in implementing key level locking in which threads trying to modify different keys are always allowed simultaneous modification. SQL DBs implement row level locking. How are they able to do it efficiently? What is the cost of increasing the number of locks/concurrencyLevel in ConcurrentHashMap from the default (which I believe is 16) to a higher number?

Answer 1

Operations locking everything

Even if you lock buckets, you might still have operations that lock need to the whole data structure. For example, you might need to resize the Map which requires you to lock the whole data structure (or all buckets) before being able to recreate the data structure.

Acquiring multiple locks

Aside from that, you may even get worse performance when locking buckets instead of the whole data structure. For example, you might have frequent operations that require acquiring multiple locks (eg iterating over the whole data structure needs to make sure nothing writes to any part of it in the meantime). Needing to check multiple locks is a performance cost which increases with the number of locks to check.

When acquiring multiple locks together, you might also run into deadlocks.

Locks are not free

Furthermore, locks are costly. They require additional memory. If you have lots and lots of buckets, you need lots of locks as well which can cumulate This gets worse the more locks you have.

Faulty implementations

Lastly, it complicates your implementation and is error-prone as you might introduce logic errors that are hard to debug. While ConcurrentHashMap likely doesn't have those errors, your own implementations might.

Final notes

Note that these things vary from application to application/depending on your use-case. If you change anything for better performance/concurrency, check before and after your changes and verify whether or not it got better.

If you data structure (or whatever you need to lock) is not frequently contended, you might be better off with a single lock. Bucketing locks is only useful when you have frequent concurrent operations on different buckets from different threads.

Disclaimer: This is just what I came up with, there may be other problems/difficulties.