Java synchronized block vs concurrentHashMap vs Collections.synchronizedMap

Question

Tell me If you have a synchronized method and inside this method, I update the hash file as follows:

public synchronized void method1() { myHashMap.clear(); //populate the hashmap, takes about 5 seconds. } 

now that method1 is executed and the hashmap is re-populated, if there are other threads to get the value of the hash map, I assume that they will be blocked?

Now instead of using the synchronization method, if I change hashmap to ConcurrentHashMap, as shown below, what is the behavior?

 public void method1() { myConcurrentHashMap.clear(); //populate the hashmap, takes about 5 seconds. } 

What if I use Collections.synchronizedMap? it is the same?

Answer 1

If you want all read and write operations to be synchronized with your HashMap , you need to put synchronize for all methods that access the HashMap ; blocking just one method is not enough.

ConcurrentHashMap allows thread-safe access to your data without blocking. This means that you can add / remove values ​​in one thread and at the same time receive values ​​in another thread without throwing an exception. See Also Documentation for ConcurrentHashMap

Answer 2

CHM (ConcurrentHashMap), instead of synchronizing each method with a common lock, restricting access to one thread at a time, it uses a finer-grained locking mechanism called locking to provide a greater degree of sharing. Arbitrarily many reading streams can simultaneously access the map, readers can access the map at the same time as writers, and a limited number of authors can simultaneously change the map. The result is much higher throughput with parallel access, with single-threaded access. ConcurrentHashMap, along with other concurrent collections, synchronized collection classes by providing iterators that do not throw a ConcurrentModificationException, which eliminates the need to lock the collection during iteration.

As with all improvements, there are still a few tradeoffs. The semantics of the methods that work on the entire Map, such as size and isEmpty, were slightly weakened to reflect the parallel nature of the collection. Since the size result may be outdated at the time of its calculation, this is really only an estimate, so the size is allowed to return an approximation instead of an exact calculation. Although this may seem alarming at first, in reality methods such as size and isEmpty are much less useful in parallel environments because these quantities drive the targets.

Secondly, Collections.synchronizedMap

It's just a simple HashMap with synchronized methods - I would call it an obsolete dute in CHM

Answer 3

you could do

 volatile private HashMap map = newMap(); private HashMap newMap() { HashMap map = new HashMap(); //populate the hashmap, takes about 5 seconds return map; } public void updateMap() { map = newMap(); } 

The reader sees a permanent card, so reading does not require synchronization and is not blocked.