Does getting a synchronized collection from collections class synchronize a class?

Question

I am trying to understand what does synchronizedCollection, synchronizedList, synchronizedMap, synchronizedSet and other such methods do. From what I understand synchronization can be done on blocks and methods and not on classes so let's say if I have a hashmap.

HashMap<Integer,String> hashMap = new HashMap<Integer,String>();
HashMap<Integer,String> syncHashMap = Collections.synchronizedMap(hashMap);

Questions

1. So did the above code just synchronized whole syncHashMap class or every method inside it?

2. If we can simply use a threadsafe collection such as ConcurrentHashMap or SynchronizedMap in multithreading scenario then what's the need of Collections.synchronizedMap(hashMap) and other similar methods in Collections class

Will deeply appreciate some direction on this, thanks in advance.

Answer 1

1. So did the above code just synchronized whole syncHashMap class or every method inside it?

Not sure what do you mean by synchronized whole syncHashMap class and every method inside it.

If you look into the source code of method Collections.synchronizedMap(hashMap), you will find it uses synchronized keyword to decorate every method of the original map. Which means for the decorated map object, you can only call one of its methods at one time. But the different maps, you can call them at one time.

2. You can find the usage of them in here. ConcurrentHashMap vs Synchronized HashMap

Answer 2

As far as I understand it Collections.synchronizedMap does not guarantee that fields values inside stored objects will be synchronized but that each entry inside the map will be synchronized when modified within a synchronized method. It does not guarantee anything else. Whenever a synchronized map is modified in another thread other references of the same map in other threads will fall in sync.

This is my superficial understanding of it according to this source as well as Java documentation.

Answer 3

There are several terms touching the subject you are asking about.

Synchronization

There are number of interfaces and classes that help synchronize your code between threads. A Semaphore, a CyclicBarrier or synchronous collections like BlockingQueue. See java.util.concurrent package for a list of those classes.

The synchronized block is also a way of synchronizing, though using it properly requires more experience.

Mutex

Different languages (and libraries) implement the standard mutex differently. The idea remains the same - in order to proceed with execution of particular code, a MUTually EXclusive token, a mutex has to be acquired. In java this acquisition happens before entering a synchronized block.

Thread-safety

To put it simply, a class is thread safe when all its methods can be accessed in any order from any number of threads concurrently. There are several ways of acheiving thread-safety. For example, Strings are thread safe. They are not synchronized, but they are immutable and that also causes thread safety. All Collections.synchronized*() methods return thread safe wrappers for collections, privided that all future* (*see happens-before relationship) access to them is executed through those wrappers (that's why it's a good rule for beginners to call the Collections.synchronized*() on new objects only.

The answer

Having the knowledge from previous paragraphs, to answer your question: no, it does not synchronize a class. It does not change the original Collection implementation at all. It does create a read and write thread-safe synchronized mutable kind-of-proxy to that class, however.

Answer 4

Before answering your question, lets reiterate some basics of synchronization

• The synchronization is always on an object/instance. Every synchronized instance is guarded by a lock (called mutex).
• Any thread invoking a synchronized method on the object, has to acquire that lock first and then invoke that method.
• This lock acquisition is not needed why an unsychronized method is called.

To answer your questions:

1. So did the above code just synchronized whole syncHashMap class or every method inside it?

Yes it does. Just look at the source code of Collections.SynchronizedMap here. Notice almost every method has synchronized (mutex) block.

2. If we can simply use a threadsafe collection such as ConcurrentHashMap or SynchronizedMap in multithreading scenario then what's the need of Collections.synchronizedMap(hashMap) and other similar methods in Collections class?

Well there are disadvantages of synchronizing every method (including read-only type methods). It slows down the read operation unnecessarily and hence your observation is right i.e. to use the implementations such as ConcurrentHashMap which lock only the method which is modifying the collection. The read-only methods are not synchronized and hence its faster in multithread scenario with concurrent read/write operations.

The only advantage Collections.synchronizedMap offers is to preserve the order of the keys entered. So when you need that you use Collections.synchronizedMap.