Hashtable, synchronizedMap and the concurrent maps

For this lesson, we'll focus on Hashtable, Collections.synchronizedMap, the ConcurrentMap atomic methods, a high-level view of ConcurrentHashMap, and ConcurrentSkipListMap for sorted concurrent keys. We'll keep the deep internals of ConcurrentHashMap for the Concurrency module. Here, the goal is to choose the right map and avoid the classic race: map.put(k, map.get(k) + 1).

01Picture it first: one turnstile or many lanes

A synchronized wrapper is like putting one turnstile in front of the whole building. It is easy to reason about, and only one person enters at a time. ConcurrentHashMap is closer to a supermarket with many checkout lanes: different bins can often be updated independently, while a busy bin still has a local queue.

The diagram below is the one I draw when someone says "but synchronizedMap is thread-safe too". Both protect structure; they do not scale the same way.

Fig. 1

A synchronizedMap wraps the whole map behind one mutex, while ConcurrentHashMap lets different bins proceed independently and only synchronizes on a bin head when that bin needs an update

Notice that this is a locking model, not a magic promise that every business operation is atomic. If your operation is "read, calculate, write", it must be one map method such as merge or compute, or one external synchronized block.

02Hashtable and synchronizedMap under the hood

Hashtable is the old built-in synchronized map. Each public method, including get, put, remove, containsKey and size, synchronizes on the Hashtable object. That means a read blocks a write and a write blocks a read, even when the keys live in different buckets.

It also has old API baggage. It rejects null keys and null values, it has keys() and elements() methods that return Enumeration, and it predates the Collections Framework interfaces that arrived in Java 1.2. You will mostly see it in older code, framework defaults and interview comparisons.

Collections.synchronizedMap is more useful to know because it wraps any Map you choose:

Map<String, Integer> counts = Collections.synchronizedMap(new HashMap<>());
counts.put("paid", 1);      // synchronized through the wrapper
Integer paid = counts.get("paid");

Each wrapper method synchronizes on one mutex. By default that mutex is the wrapper object itself. The important rule is in the Javadoc: when iterating over a view, you must synchronize manually on the wrapper map.

Map<String, Integer> counts = Collections.synchronizedMap(new HashMap<>());
counts.put("NEW", 2);
counts.put("PAID", 5);

for (String status : counts.keySet()) {        // wrong: no external lock
    System.out.println(status + "=" + counts.get(status));
}

The keySet() call is synchronized, but it returns a view. The iterator then runs through several calls, and those calls are not automatically wrapped in one long critical section. Another thread can modify the map between iterator steps.

Here is the version you should write if you choose a synchronized wrapper:

Map<String, Integer> counts = Collections.synchronizedMap(new HashMap<>());

synchronized (counts) {
    for (Map.Entry<String, Integer> entry : counts.entrySet()) {
        System.out.println(entry.getKey() + "=" + entry.getValue());
    }
}

03ConcurrentMap: make the whole operation atomic

The ConcurrentMap interface exists because a single safe get and a single safe put are not enough. The race happens in the gap between them. Two threads can read the same old value, both compute the same new value, and one update overwrites the other.

This is the scenario question in real form: multiple threads need to access and update a shared collection without data inconsistency. For a shared key-value structure, the default answer is ConcurrentHashMap, through the ConcurrentMap API.