Don't forget to create account on our site to get access to more material made only for free registered user.  

Don't forget to create account on our site to get access to more material made only for free registered user.  


ConcurrentHashMap: It allows concurrent modification of the Map from several threads without the need to block them.  Use this if performance is critical, and each thread only inserts data to the map, with reads happening less frequently. The ConcurrentHashMap uses very sophisticated techniques to reduce the need for synchronization and allow parallel read access by multiple threads without synchronization and, more importantly, provides an Iterator that requires no synchronization and even allows the Map to be modified during insertion (though it makes no guarantees whether or not elements that were inserted during iteration will be returned). In this the lock is applied to a segment instead of an entire Map. Each segment manages its own internal hash table. The lock is applied only for update operations. Collections.synchronizedMap(Map) synchronizes the entire map. You can use these operations to implement certain compound operations without explict synchronization


·        putIfAbsent(key, value)

·        remove(key, value)

·        replace(key, value)

·        replace(key, oldValue, newValue)



Collections.synchronizedMap(map) : creates a blocking Map which will degrade performance, albeit ensure consistency (if used properly). Use this option if you need to ensure data consistency, and each thread needs to have an up-to-date view of the map. It makes sense really only if you need to wrap up a map with some other characteristics, perhaps some sort of ordered map, like a TreeMap. It synchronizes all operations (get, put, size, etc).


Hashtable: The "scalability issues" for Hashtable are present in exactly the same way in Collections.synchronizedMap(Map) - they use very simple synchronization, which means that only one thread can access the map at the same time. This is not much of an issue when you have simple inserts and lookups (unless you do it extremely intensively), but becomes a big problem when you need to iterate over the entire Map, which can take a long time for a large Map - while one thread does that, all others have to wait if they want to insert or lookup anything.





Remember: The main difference between these two is that ConcurrentHashMap will lock only portion of the data which are being updated while other portion of data can be accessed by other threads. However, Collections.synchronizedMap() will lock all the data while updating, other threads can only access the data when the lock is released. If there are many update operations and relative small amount of read operations, you should choose ConcurrentHashMap.

Also one other difference is that ConcurrentHashMap will not preserve the order of elements in the Map passed in. It is similar to HashMap when storing data. There is no guarantee that the element order is preserved. While Collections.synchronizedMap(0 will preserve the elements order of the Map passed in. For example, if you pass a TreeMap to ConcurrentHashMap, the elements order in the ConcurrentHashMap may not be the same as the order in the TreeMap, but Collections.synchronizedMap() will preserve the order. Furthermore, ConcurrentHashMap can guarantee that there is no ConcurrentModificationException thrown while one thread is updating the map and another thread is traversing the iterator obtained from the map. However, Collections.synchronizedMap() is not guaranteed on this.

·        Multiple partitions which can be locked independently. (16 by default)

·        Using concurrent Locks operations for thread safety instead of synchronized.

·        Has thread safe Iterators. synchronizedCollection's iterators are not thread safe.

·        Does not expose the internal locks. synchronizedCollection does.

As the ConcurrentHashMap implements the Map Interface, it does support all features every basic Map does as well. So yes: you can use it like any other map and ignore all the extra features. But then you will essentially have a slower HashMap.

The main difference between a synchronized Map and a concurrent Map is - as the name says - concurrency. Imagine you have 100 threads wanting to read from the Map, if you synchronize you block out 99 threads and 1 can do the work. If you use concurrency 100 threads can work at the same time. Now if you think about the actual reason why you use threads, you soon come to the conclusion that you should get rid of every possible synchronized block that you can.




You have no rights to post comments

Don't forget to create account on our site to get access to more material made only for free registered user.