Hashtable vs ConcurrentHashMap，答案是否正确，为什么？

Question

I read somewhere about replacing Hashtable with ConcurrentHashMap:

Since Hashtable locks whole Map instead of a portion of Map, compound operations like if(Hashtable.get(key) == null) put(key, value) works in Hashtable but not in concurrentHashMap. instead of this use putIfAbsent() method of ConcurrentHashMap

Since there is a gap between the get and the put, why does the hashtable work?

if(Hashtable. get (key) == null) put (key, value)

Answer 1

In your question you quoted this as fact:

"Since Hashtable locks whole Map instead of a portion of Map , compound operations like if (hashtable.get(key) == null) hashtable.put(key, value) works in Hashtable but not in ConcurrentHashMap ."

Unfortunately it is incorrect. That code using Hashtable does NOT work... in the sense that the author means.

Yes, the get and put methods do lock the entire table. But these methods only hold the lock for the duration of the operation. Between the get and put , the above code will release the lock on hashTable and then reacquire it.

This means that a second thread could call put to put a different value for the key. The sequence might look like this:

1. thread A - hashtable.get("a") -> null
2. thread B - hashtable.get("a") -> null
3. thread B - hashtable.put("a", 1)
4. thread A - hashtable.put("a", 2)

And we have called put twice with different values for the same key.

Which thread will "win"? In general, we can't say. It depends on the precise timing, and other things. It is not predictable.

So, if the intended behavior is that the first thread to call get on the key should always win, then this is not a thread-safe implementation.