What's the Difference Between Concurrenthashmap and Collections.Synchronizedmap(Map)

What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)?

For your needs, use ConcurrentHashMap. It allows concurrent modification of the Map from several threads without the need to block them. Collections.synchronizedMap(map) creates a blocking Map which will degrade performance, albeit ensure consistency (if used properly).

Use the second option if you need to ensure data consistency, and each thread needs to have an up-to-date view of the map. Use the first if performance is critical, and each thread only inserts data to the map, with reads happening less frequently.

ConcurrentHashMap vs Synchronized HashMap

Synchronized HashMap：

1. Each method is synchronized using an object level lock. So the get and put methods on synchMap acquire a lock.

2. Locking the entire collection is a performance overhead. While one thread holds on to the lock, no other thread can use the collection.

ConcurrentHashMap was introduced in JDK 5.

1. There is no locking at the object level,The locking is at a much finer granularity. For a ConcurrentHashMap, the locks may be at a hashmap bucket level.

2. The effect of lower level locking is that you can have concurrent readers and writers which is not possible for synchronized collections. This leads to much more scalability.

3. ConcurrentHashMap does not throw a ConcurrentModificationException if one thread tries to modify it while another is iterating over it.

This article Java 7: HashMap vs ConcurrentHashMap is a very good read. Highly recommended.

What is difference between HashMap in synchronized block vs Collections.synchronizedMap().

Using the synchronizedMap method is more convenient and safer in that you know all accesses to the map will be protected (as long as you don't bypass it by calling methods on hm directly).

But using the synchronized block gives you the ability to control the granularity of locking, by holding the lock over multiple statements, which the synchronizedMap option doesn't allow for.

So if you need multiple statements to be executed without being interleaved with calls from other threads, you would have to choose the synchronized blocks (or else switch to something like ConcurrentHashMap if you're looking for something like putIfAbsent or similar functionality). If you don't need that, the synchronizedMap is easier.

Difference between Hashtable and Collections.synchronizedMap(HashMap)

Here are the answers I've gotten from a bit of (hopefully correct) research:

1. Both provide the same degree of synchronization. If you were to wrap Hashtable through Collections.synchronized you would have the same degree, but with another redundant layer, of synchronization.

2. The main difference between Hashtable and Collections.synchronizedMap(HashMap) exist more at the API level. Because Hashtable is part of Java's legacy code, you'll see that the Hashtable API is enhanced to implement the Map interface, to become part of Java's collections framework. This means that if you were to wrap Hashtable through Collections.synchronizedMap(), the API of the wrapped Hashtable would become limited to the Map API. So if the API of Hashtable is encompassed in your definition of behavior, then it is obviously altered/limited.

Java synchronized block vs concurrentHashMap vs Collections.synchronizedMap

If you want to have all read and write actions to your HashMap synchronized, you need to put the synchronize on all methods accessing the HashMap; it is not enough to block just one method.

ConcurrentHashMap allows thread-safe access to your data without locking. That means you can add/remove values in one thread and at the same time get values out in another thread without running into an exception. See also the documentation of ConcurrentHashMap

Difference between concurrentMap

They are identical. You should just call new ConcurrentHashMap and forget about Maps.newConcurrentHashMap.

Over a decade ago at this point, the <> were optional when invoking static methods but they weren't when invoking constructors. var also didn't exist yet. Thus, the only way to write the code "Make a field or variable for a Map object, and create a new Map object, and assign the reference to this newly made object to the newly made field/variable" which is a rather common thing to do, is:

Map<String, Integer> map = new ConcurrentHashMap<String, Integer>();

That's very wordy and the <String, Integer> part is straight up duplication, which is annoying. That's why google introduced the newConcurrentHashMap method in their guava library, because:

Map<String, Integer> map = Maps.newConcurrentHashMap();

is shorter, and you can static-import that method for the even shorter:

Map<String, Integer> map = newConcurrentHashMap();

That was the only point of all this: Shorter code. It does the same thing. These days, for local vars you can write:

var map = new ConcurrentHashMap<String, Integer>();

and for fields you can use the diamond syntax:

Map<String, Integer> map = new ConcurrentHashMap<>();

Hence, google's newXYZ methods are obsolete.

---

Related Topics