ConcurrentHashMap

#Introduction

ConcurrentHashMap is one of the most important Java collections for senior-level interviews, especially for questions involving multithreading, concurrent access, thread safety, atomic operations, high-throughput applications, caching, counters and Java 8+ concurrency. The central idea:

ConcurrentHashMap allows multiple threads to safely access and update a Map concurrently without locking the entire Map for every operation.

#What Is ConcurrentHashMap?

Package:

java.util.concurrent.ConcurrentHashMap

It implements ConcurrentMap<K,V> → Map<K,V>.

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

#Why Do We Need ConcurrentHashMap?

HashMap<String, Integer> map = new HashMap<>();

Now multiple threads perform put(), get(), put() and remove() at the same time. HashMap doesn't provide the necessary thread-safety guarantees for concurrent mutation. You could synchronize:

synchronized (map) {
    map.put(key, value);
}

But now Thread 1 locks the entire map and Threads 2, 3 and 4 all wait. This limits concurrency. ConcurrentHashMap is designed to allow much more concurrent access.

Main Goal

ConcurrentHashMap tries to achieve thread safety + high concurrency + good performance, rather than thread safety + one giant lock.

HashMap vs ConcurrentHashMap

#Why Doesn't ConcurrentHashMap Allow Null?

A very common interview question.

map.put(null, value);   // NullPointerException
map.put(key, null);     // also not allowed

Why Are Nulls Prohibited?

The major reason is ambiguity in concurrent operations. If map.get(key) returns null, does that mean:

1. the key doesn't exist, or
2. the key exists with a null value?

For ConcurrentHashMap, eliminating null values removes this ambiguity — particularly important for atomic/concurrent APIs.

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

map.put("A", 10);     // valid
map.put("B", null);   // NullPointerException

#Java 7 vs Java 8+ Architecture

This is extremely important for interviews.

Java 7 — Segments

ConcurrentHashMap used Segments. Each segment acted somewhat like an independently lockable portion.

Java 8+ — CAS and bin-level synchronization

The segmented architecture was removed. The implementation uses:

• CAS
• volatile operations
• bin-level synchronization
• tree bins for heavy collisions

This is the architecture you should focus on for modern Java interviews.

Why Was Segmentation Removed?

Java 8 introduced a more fine-grained design. Instead of large segment locks, the implementation can synchronize much smaller portions of the table when necessary — only the relevant bin may need locking for certain updates. This provides better concurrency and flexibility.

Java 8+ Internal Structure

#CAS and Volatile

CAS

CAS means Compare-And-Swap.

For example: current = null, expected = null, newNode = X → CAS(current, null, X). If another thread changed the location first, CAS fails, and the operation can retry or take another path.

Why CAS Is Useful

CAS allows certain operations to happen without taking a traditional lock.

Volatile Reads

ConcurrentHashMap also relies heavily on memory-visibility guarantees: Thread A writes → memory visibility → Thread B reads. Volatile semantics help ensure threads see appropriate updates. You don't need to memorize every internal memory-barrier detail for most interviews. The key terms are CAS, volatile, synchronization.

#Locking Behaviour

Does ConcurrentHashMap Lock the Entire Map?

No. This is one of the biggest differences from Collections.synchronizedMap(...), which typically uses a single synchronization mechanism around operations. ConcurrentHashMap uses a much more fine-grained approach:

Important Clarification

The better statement: it avoids a single global lock and uses fine-grained synchronization combined with CAS and volatile operations.

get() Operation

map.get(key);

Are Reads Locked?

Normally, simple reads such as get() and containsKey() do not require locking the entire Map. This is a major reason ConcurrentHashMap scales much better than a single-lock approach for read-heavy workloads.

put() Operation

Empty Bin + CAS

If the target bin is empty, the implementation can often attempt to insert using CAS: empty bin → CAS(null, newNode) → success. No conventional lock is required for that insertion path.

Occupied Bin

If the bin already contains nodes (Node → Node → Node), the implementation may synchronize on an appropriate node/bin structure while modifying that bin. This prevents conflicting updates to that portion of the table.

Why Fine-Grained Locking Helps

Thread A on Bin 2 and Thread B on Bin 9 may proceed concurrently. Contrast this with synchronizedMap → one lock → only one thread at a time. This is the key scalability advantage.

#Collisions, Tree Bins and Resizing

Hash Collisions

ConcurrentHashMap still has to deal with hash collisions — e.g. Keys A, B and C all → bucket 5 (A → B → C). If collisions become heavy enough, tree-based structures can be used.

Tree Bins

Similar to modern HashMap, ConcurrentHashMap can use tree bins: many collisions → TreeBin → Red-Black Tree. This prevents a heavily contended/collided bin from degrading into a long linear chain.

Treeification Threshold

You may encounter TREEIFY_THRESHOLD = 8 and MIN_TREEIFY_CAPACITY = 64. These are implementation details and should not be treated as universal API guarantees. For interviews: know that sufficiently collision-heavy bins can become tree-based.

Resize

ConcurrentHashMap also needs resizing when the table becomes sufficiently full: small table → threshold exceeded → resize → larger table. But resizing is designed to happen concurrently.

Concurrent Resizing

One impressive feature is that multiple threads can participate in resizing — threads encountering the resize can help transfer bins. This is different from "one thread locks the entire Map and moves everything." Modern ConcurrentHashMap has mechanisms for cooperative resizing.

Why Resizing Is Complicated

Other threads may simultaneously perform get(), put() and remove() while buckets are being moved. The implementation uses specialized coordination/state mechanisms so threads can safely interact with the old and new tables during transfer. For interviews: understand cooperative resizing, not every source-level transfer detail.

size()

A common misconception is "size() always takes one global lock." Not necessarily. ConcurrentHashMap maintains internal counting mechanisms designed for concurrency (counters/cells that may be aggregated). For interview purposes: its size accounting is designed to work efficiently under concurrent updates.

mappingCount()

map.mappingCount();

returns a long, because a very large concurrent map can conceptually exceed the int range used by Map.size(). For most applications size() is sufficient, but mappingCount() is worth knowing.

isEmpty() and Stale Answers

map.isEmpty();

No Snapshot Semantics

map.size() doesn't mean "freeze the Map and calculate an immutable snapshot." Likewise, iteration doesn't represent a guaranteed immutable snapshot.

No Ordering Guarantee

ConcurrentHashMap doesn't guarantee insertion order or sorted order. For insertion order use LinkedHashMap; for sorted concurrent keys use ConcurrentSkipListMap.

#Weakly Consistent Iterators

This is a major interview topic. ConcurrentHashMap iterators are weakly consistent — they do not behave like ordinary fail-fast iterators.

What Does Weakly Consistent Mean?

for (String key : map.keySet()) {
    // ...
}

while another thread modifies the Map. The iterator:

• Does not throw ConcurrentModificationException merely because concurrent updates occur.
• May reflect some updates made after iteration begins.
• Is not guaranteed to provide a snapshot of the Map at one exact moment.

Think: iteration sees a moving Map — safe from fail-fast CME, but not a snapshot.

Fail-Fast vs Weakly Consistent vs Snapshot

These are three different concepts.

Is ConcurrentHashMap's Iterator Fail-Safe?

You will often hear "ConcurrentHashMap has fail-safe iterators." This terminology is common in interview discussions, but "weakly consistent" is the more precise JDK terminology. Use it in a senior-level interview.

Example

// Thread 1
for (Integer key : map.keySet()) {
    System.out.println(key);
}

// Thread 2
map.put(100, "X");

The iterator does not simply fail because of that concurrent modification — but you should not assume it must see 100 either. The iteration is not a snapshot.

Weakly Consistent Views

keySet(), values() and entrySet() provide views designed for concurrent use. Iteration over them is weakly consistent: safe under concurrent modification + not a snapshot + may reflect some concurrent changes.

Modifying While Iterating

for (String key : map.keySet()) {
    map.put("X", 10);
}

With ConcurrentHashMap this doesn't inherently produce the fail-fast behaviour associated with HashMap iterators. However, modifying a collection while traversing it can still have application-level consequences, so don't treat weak consistency as "iteration sees everything predictably."

#Atomic Compound Operations

putIfAbsent()

One of the most useful methods. Naive approach:

if (!map.containsKey(key)) {
    map.put(key, value);
}

This is not atomic. Two threads can both call containsKey → false, then both put — a race condition.

Correct approach:

map.putIfAbsent(key, value);

This provides an atomic compound operation: if absent + put happens as one Map operation.

computeIfAbsent()

map.computeIfAbsent(key, k -> createValue(k));

Meaning: if the key isn't present, compute and associate the value. Especially useful for caches, grouping, per-key state and lazy initialization.

Example — Grouping

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

map.computeIfAbsent("Java", k -> new ArrayList<>()).add(10);

Result: Java → [10]. If Java already exists, the existing list is returned.

Important Concurrency Caveat

compute()

map.compute(key, (k, oldValue) -> /* ... */);

Atomically computes a new value. Useful for atomic per-key state transitions.

merge()

map.merge(key, 1, Integer::sum);

Useful for counters: existing value + new value, with the remapping function applied atomically for the key.

Concurrent Counter Example

ConcurrentHashMap<String, Integer> counts = new ConcurrentHashMap<>();

counts.merge("Java", 1, Integer::sum);

If Java → 4, after the merge Java → 5. This is far safer than:

counts.put("Java", counts.get("Java") + 1);

because the latter is a non-atomic read-modify-write sequence.

Why get() + put() Is Dangerous

Integer value = map.get("Java");
map.put("Java", value + 1);

Use merge() or another suitable atomic approach.

Atomicity Is Usually Per-Key

Methods such as putIfAbsent(), compute(), computeIfAbsent(), computeIfPresent(), merge() and replace() provide atomic semantics for their Map operation. But don't infer that every sequence of multiple Map operations is automatically atomic:

if (map.containsKey(a) && map.containsKey(b)) {
    // ...
}

is not one atomic transaction.

Compound Operations Cheat Sheet

replace()

map.replace(key, oldValue, newValue);

Compare-and-replace semantics: if current == oldValue, replace with newValue — atomic for that mapping.

replaceAll() and forEach()

map.replaceAll((key, value) -> /* ... */);

map.forEach((key, value) -> /* ... */);

Don't interpret replaceAll() as an atomic transaction over the entire Map. Concurrent collections provide strong guarantees for individual operations, not arbitrary multi-operation business transactions. Bulk traversal methods (and parallel bulk-operation APIs) are designed with concurrent Map semantics in mind rather than requiring you to freeze the entire Map.

putIfAbsent() vs computeIfAbsent()

replace() vs put()

map.put(key, newValue) unconditionally inserts/replaces. map.replace(key, oldValue, newValue) only replaces if the current value matches the expected old value — useful for atomic conditional updates.

Compare-and-Set Mental Model

Current value == expected? → Yes → replace. This is similar conceptually to CAS-style coordination and useful for simple state transitions.

Example — State Transition

An order is NEW and you want NEW → PROCESSING:

map.replace(orderId, "NEW", "PROCESSING");

The operation succeeds only if the expected current state is still "NEW".

#computeIfAbsent() Details

Avoid Recursive Mutation

Don't perform complex Map mutations from inside the mapping function that recursively modify the same Map — e.g. a mapping function that calls computeIfAbsent() on the same map again. Keep mapping functions simple, side-effect controlled and non-recursive where practical.

Mapping Function Should Not Return Null

For computeIfAbsent(), if the mapping function returns null, the mapping isn't inserted. This differs from ordinary put() because ConcurrentHashMap doesn't permit null values.

merge() and Null

Since ConcurrentHashMap doesn't allow null values, a remapping function returning null removes an existing mapping according to the Map.merge() contract.

compute() Returning Null

map.compute(key, (k, v) -> null);

If a mapping exists, returning null removes it. If no mapping exists, it remains absent. This follows the Map.compute() semantics.

Does ConcurrentHashMap Guarantee Only One Computation?

For computeIfAbsent, the mapping function is applied atomically for the key according to the method's contract. Multiple threads don't simply perform an uncontrolled check-then-put race for the same missing key. However, mapping functions should still be written carefully and should not assume arbitrary global serialization across unrelated keys.

Per-Key Atomicity

Operations on key A and key B are each atomic, and ConcurrentHashMap is designed to allow operations on unrelated keys to proceed concurrently where possible. This is one reason it scales well.

#Real-World Patterns

Atomic Counter Pattern

ConcurrentHashMap<String, Long> counts = new ConcurrentHashMap<>();

counts.merge("login", 1L, Long::sum);

Much better than counts.put("login", counts.getOrDefault("login", 0L) + 1);, which isn't atomic.

Frequency Map

ConcurrentHashMap<String, Integer> frequency = new ConcurrentHashMap<>();

frequency.merge(word, 1, Integer::sum);

Useful for concurrent log processing, event counting, request counters and metrics aggregation.

Cache Pattern

ConcurrentHashMap<String, User> cache = new ConcurrentHashMap<>();

User user = cache.computeIfAbsent(userId, this::loadUser);

Advantages: thread-safe Map + atomic per-key initialization + no explicit global lock. But production caches often also need TTL, maximum size, eviction, refresh and metrics — ConcurrentHashMap alone doesn't provide those policies.

LongAdder and ConcurrentHashMap

A popular high-performance counter pattern. Instead of ConcurrentHashMap<String, Long>, use ConcurrentHashMap<String, LongAdder>:

ConcurrentHashMap<String, LongAdder> counts = new ConcurrentHashMap<>();

counts.computeIfAbsent("requests", k -> new LongAdder()).increment();

This can reduce contention for heavily updated counters.

Why LongAdder?

With many threads incrementing the same counter, an AtomicLong is one shared counter → high contention. LongAdder can spread updates across internal cells and combine them when reading — especially useful for high-contention metrics.

Mutable Values Are Still Your Problem

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

map.computeIfAbsent("A", k -> new ArrayList<>()).add(10);

The Map operation may be thread-safe, but concurrent .add() calls on the same ArrayList are not automatically made safe by the Map. Alternatives include CopyOnWriteArrayList or Collections.synchronizedList, depending on workload.

#Performance and Hashing

Hash Distribution Still Matters

ConcurrentHashMap is hash-based. Poor hashCode() implementations can still cause collisions and increased contention/work in a bin. Good hash distribution remains important.

Hash Collision ≠ Thread Collision

They can be related (many keys in the same bin → more localized contention), but they are not the same thing.

Typical Complexity

Subject to hashing, collisions, resizing, contention and implementation details. Tree bins can make heavily collided lookup behaviour logarithmic within the tree structure.

Is ConcurrentHashMap Faster Than HashMap?

Not necessarily for single-threaded workloads — HashMap has less concurrency-related machinery. The advantage appears when multiple threads share a Map. Don't say "ConcurrentHashMap is always faster." Better: "It is designed to provide much better concurrency and scalability than coarse-grained synchronization, while retaining efficient average Map operations."

Is ConcurrentHashMap Lock-Free?

No — another common trap. It uses CAS + volatile + synchronization. Some operations may proceed without locking, but the overall data structure is not simply "lock-free."

Why HashMap Is Not Thread-Safe

Simplistic answer: "Because multiple threads can modify it." Better answer: HashMap doesn't provide the synchronization and memory-visibility guarantees required for concurrent mutation. Concurrent operations can race, producing lost updates and inconsistent observations, and compound operations such as check-then-act are not atomic.

#Comparisons

ConcurrentHashMap vs Hashtable

Why Is Hashtable Usually Slower?

Hashtable: one synchronized method → coarse-grained contention. ConcurrentHashMap: fine-grained coordination + CAS + volatile + localized synchronization. Therefore more threads can make progress concurrently.

ConcurrentHashMap vs synchronizedMap()

Map<K,V> map = Collections.synchronizedMap(new HashMap<>());

This provides synchronization around Map operations, but generally uses a common lock. ConcurrentHashMap offers better concurrency, weakly consistent iteration and atomic concurrent Map methods.

ConcurrentHashMap vs CopyOnWriteArrayList

These solve different problems: ConcurrentHashMap → concurrent key-value access; CopyOnWriteArrayList → concurrent list access with many reads/few writes. Choose based on the data structure required.

ConcurrentHashMap vs ConcurrentSkipListMap

If you need floorKey(), ceilingKey() or range queries in a concurrent environment, ConcurrentSkipListMap is often the appropriate choice.

#Decision Framework

If you need insertion/access order, ConcurrentHashMap doesn't provide it — you need a different concurrency design.

Complete Map Selection

Final Mental Model