Java ConcurrentHashMap

java.util.concurrent.ConcurrentHashMap<K, V> is the thread-safe map that eliminates the scalability bottleneck that Hashtable and Collections.synchronizedMap() create. Both older approaches serialise every operation — reads and writes — on a single global lock, so adding more threads adds more contention, not more throughput. ConcurrentHashMap reads without any lock at all and writes by locking only the individual bucket being modified. The result scales with thread count instead of collapsing under it.

What Is Java ConcurrentHashMap?

ConcurrentHashMap<K, V> is a concrete class in java.util.concurrent that implements ConcurrentMap<K, V>. It delivers the same key-value semantics as HashMap — O(1) average put(), get(), and remove() — while remaining fully safe for concurrent reads and writes from multiple threads simultaneously.

The diagram below shows where ConcurrentHashMap sits relative to other Map options and the thread-safety spectrum.

THREAD-SAFETY SPECTRUM FOR JAVA MAPS:

  HashMap                  ← NOT thread-safe at all
  LinkedHashMap            ← NOT thread-safe
  TreeMap                  ← NOT thread-safe

  Collections.synchronizedMap(new HashMap<>())
                           ← single global lock on every method
                           ← reads AND writes serialised
                           ← 100 reader threads → 99 blocked

  Hashtable                ← same as synchronizedMap, legacy
                           ← additionally: no null keys or values

  ConcurrentHashMap        ← lock-free reads (volatile fields)
                           ← bucket-level lock on writes
                           ← 100 reader threads → 100 proceed
                           ← 16 writer threads in different buckets → 16 proceed

  ConcurrentSkipListMap    ← sorted concurrent map (like TreeMap + ConcurrentHashMap)

KEY FACTS:
  Package    : java.util.concurrent
  Since      : Java 1.5
  Implements : ConcurrentMap<K,V>, Serializable
  Null keys  : NOT allowed — NullPointerException immediately
  Null values: NOT allowed — NullPointerException immediately
  Ordering   : no guaranteed iteration order
  Thread-safe: YES — reads lock-free, writes per-bucket
  Default capacity   : 16 buckets
  Default load factor: 0.75

Basic Overview — What Changes Between HashMap and ConcurrentHashMap

HASHMAP INTERNALS (not thread-safe):
  table[]     ← plain Object[] array
  Node.val    ← plain field
  Node.next   ← plain reference

  Two threads calling put() simultaneously can:
    — corrupt a bucket chain (one insertion lost)
    — trigger simultaneous resize → corrupt table[] reference
    — Java 6 and earlier: create a circular linked-list during resize
      causing get() to loop infinitely

CONCURRENTHASHMAP INTERNALS (thread-safe):
  table[]     ← volatile Node<K,V>[]  (volatile ensures visibility across CPUs)
  Node.val    ← volatile V            (writes immediately visible to all threads)
  Node.next   ← volatile Node<K,V>    (chain traversal sees latest structure)

  get() path:
    Read table[index] — volatile read, no lock
    Walk chain reading volatile val fields — no lock
    Returns instantly regardless of concurrent writers

  put() path — CASE 1: bucket is empty:
    CAS (Compare-And-Swap) table[index] from null to newNode
    Single atomic CPU instruction — no lock, no contention
    If CAS fails (another thread beat us), loop and retry

  put() path — CASE 2: bucket already has entries:
    synchronized(table[index])  ← locks ONLY this one bucket head node
    Walk chain, insert or update
    Treeify if chain exceeds 8 nodes

  KEY DIFFERENCE: 16 writers can modify 16 different buckets simultaneously.
  Hashtable: only 1 writer at a time, regardless of which bucket.

When to Use ConcurrentHashMap

USE ConcurrentHashMap WHEN:
  1. A Map is shared across multiple threads and any thread may write
     — session registry, permission cache, feature flag store
     — any @Service or @Component field that holds a Map

  2. High-read, low-write access patterns
     — configuration loaded at startup, read on every request
     — product catalogue refreshed hourly, served millions of times

  3. Atomic compound operations are needed
     — putIfAbsent: register a key exactly once, no double-insert race
     — computeIfAbsent: lazy-initialise per key, no double-creation
     — merge: atomic counter increment without external locks

  4. Concurrent iteration is needed
     — ConcurrentHashMap.entrySet() never throws CME during iteration
     — background eviction threads can removeIf() while readers iterate

CHOOSE HashMap WHEN:
  - Completely single-threaded code — HashMap is slightly faster
    and uses less memory (no volatile fields, no bucket lock overhead)

CHOOSE Collections.synchronizedMap WHEN:
  - Code predates Java 5 (unlikely) or cannot import java.util.concurrent
  - Note: even synchronizedMap needs explicit external sync for iteration
    and compound operations — ConcurrentHashMap is almost always better

NEVER USE Hashtable IN NEW CODE:
  - Single global lock on every method even in single-threaded scenarios
  - Does not expose atomic compound operations
  - ConcurrentHashMap has been its explicit replacement since Java 5

NEVER USE ConcurrentHashMap WHEN multi-key atomicity is required:
  - CHM guarantees atomicity per single key operation
  - To atomically transfer a value from keyA to keyB, you need
    external synchronisation or a different design — CHM cannot help

How ConcurrentHashMap Works Internally

The Bucket Array — Four Node Types

ConcurrentHashMap uses the same conceptual bucket array as HashMap but with volatile fields and four possible node types that reflect different states.

CONCURRENTHASHMAP BUCKET STATES:

  table[i] = null
    → bucket is empty, accept CAS insert

  table[i] = Node<K,V>
    → normal linked-list node (same as HashMap)
    → fields: volatile hash, volatile K key, volatile V val, volatile Node next

  table[i] = TreeBin
    → wraps a Red-Black tree (treeified after chain > 8 AND table.length >= 64)
    → same Java 8 treeification as HashMap — O(log n) worst-case per bucket

  table[i] = ForwardingNode (hash = -1)
    → signals that this bucket is being moved during a resize operation
    → any get() that sees a ForwardingNode follows it to the new table
    → guarantees reads are never blocked even during resize

How Size Tracking Works — LongAdder Cells

HashMap tracks size with a single int size field. In ConcurrentHashMap, incrementing a shared counter from multiple threads creates contention. Java 8 solves this with a distributed approach.

SIZE TRACKING IN CONCURRENTHASHMAP:

  baseCount    ← a volatile long, used when contention is low
  CounterCell[] counterCells  ← an array of cells, each with a volatile long

  When a write succeeds:
    1. Try CAS on baseCount — if succeeds, done
    2. If CAS fails (contention), pick a CounterCell based on thread ID
       and CAS on that cell instead

  size() and mappingCount() sum all cells:
    total = baseCount + sum(counterCell[i].value for all cells)
    This sum is an ESTIMATE — it may not reflect concurrent inserts
    happening at the exact moment size() is called.

  WHY THIS MATTERS FOR PRODUCTION CODE:
    map.size() == 0 does not mean no one is inserting right now.
    map.size() > MAX_CAPACITY check has a race condition.
    Never use size() to enforce capacity limits under concurrency.
    Use compute() or a separate AtomicInteger if exact counts are needed.

CAS in Detail — The Empty-Bucket Fast Path

SCENARIO: Thread 1 and Thread 2 both want to insert into bucket[3] (empty)

  Thread 1:
    expected = null
    newNode  = Node("user:001", sessionA)
    casTabAt(table, 3, null, newNode)
    CPU executes: LOCK CMPXCHG [table+3*8], null, newNode
    → atomic: IF table[3] == null THEN table[3] = newNode → SUCCESS

  Thread 2 (simultaneously):
    expected = null
    newNode  = Node("user:002", sessionB)
    casTabAt(table, 3, null, newNode)
    → FAILS: table[3] is no longer null (Thread 1 won)
    → Thread 2 loops back to the top of the put() loop
    → table[3] != null now → takes synchronized(table[3]) path
    → Acquires lock on bucket head, walks chain, appends sessionB

  RESULT:
    table[3]: Node("user:001",sessionA) → Node("user:002",sessionB) → null
    No lock was ever acquired by Thread 1.
    Thread 2 only held a lock for the few nanoseconds to append to the chain.

Why Null Is Prohibited

REASON NULL IS FORBIDDEN IN CONCURRENTHASHMAP:

  HashMap allows null values. map.get("key") = null means EITHER:
    (a) key does not exist in the map, OR
    (b) key exists and its value is null

  In HashMap (single-threaded), this is disambiguated by:
    if (map.containsKey("key")) { ... }  ← safe: no thread intervenes

  In ConcurrentHashMap (multi-threaded):
    value = map.get("key");         // returns null — Thread 2 inserts here
    map.containsKey("key");         // now returns true!
    // The check-then-act is NOT atomic — race condition

  By prohibiting null values entirely:
    map.get("key") == null  ←→  key is DEFINITELY absent
    No containsKey() disambiguation needed.
    Code using ConcurrentHashMap is safer by design.

Core Operations with Examples

Thread-Safe Reads and Writes

Output:
Initial: {/checkout=0, /home=0, /products=0}
After 10 threads × 200 hits each:
  /checkout    2000 hits
  /home        2000 hits
  /products    2000 hits

=== get() and containsKey() ===
get(/home)        : 2000
get(/missing)     : null
containsKey(/home): true
getOrDefault(/api): 0

=== remove() ===
remove(/checkout) : 2000
After remove      : {/home=2000, /products=2000}

Atomic Compound Operations — The Core Advantage

Output:
=== putIfAbsent — register once, atomically ===
putIfAbsent TXN-9921 first  : null
putIfAbsent TXN-9921 second : processed
Map: {TXN-9921=processed}

=== computeIfAbsent — group-by, thread-safe ===
  PAYMENT: [txn-001, txn-002, txn-003]
  LOGIN: [user-A, user-C]
  LOGOUT: [user-B]

=== merge — atomic counter pattern ===
Error counts: {DB_TIMEOUT=3, AUTH_FAIL=2, NPE=1}

=== compute — atomic stock management ===
After -5 units: SKU-001 = 95
Still present (qty > 0): true

=== optimistic update ===
replace PENDING→PROCESSING: true
replace PENDING→PROCESSING again: false
Current status: PROCESSING

Weakly Consistent Iteration and Bulk Operations

Output:
=== for-each — weakly consistent, no CME ===
  Laptop       Rs. 49999.00
  Mouse        Rs.   999.00
  Keyboard     Rs.  2499.00
  Monitor      Rs. 18999.00
  Webcam       Rs.  3499.00
Map now has 6 entries (Trackpad added)

=== entrySet().removeIf() — safe concurrent removal ===
After removing items below Rs.2000: [Laptop, Keyboard, Monitor, Webcam, Trackpad]

=== newKeySet() — thread-safe Set ===
Active users: [user-priya, user-rohan, user-ananya]
Size: 3

=== forEach bulk operation ===
  Laptop       Rs. 49999.00
  Keyboard     Rs.  2499.00
  Monitor      Rs. 18999.00
  Webcam       Rs.  3499.00
  Trackpad     Rs.  4999.00

Real-World Example — Swiggy Real-Time Delivery Metrics

A delivery platform like Swiggy tracks live metrics across thousands of concurrent delivery agents — active orders per zone, delivery success rates, and error counts — while simultaneously serving these metrics to a dashboard that reads them every second. ConcurrentHashMap handles concurrent agent updates on write threads and dashboard reads on read threads without any external synchronisation.

Output:
========================================================================
  SWIGGY LIVE DELIVERY METRICS  [events: 110]
========================================================================
  HSR Layout     active=0    delivered=15    failed=5   rate=75.0%
  Indiranagar    active=0    delivered=24    failed=6   rate=80.0%
  Koramangala    active=0    delivered=50    failed=0   rate=100.0%
  Whitefield     active=0    delivered=10    failed=0   rate=100.0%
========================================================================

Koramangala success rate: 100.0%

Zones with active orders:

Performance Considerations

Lock-free reads scale linearly: At 1,000 concurrent reader threads on a ConcurrentHashMap, all 1,000 proceed without any contention. On Hashtable or synchronizedMap, 999 block waiting for the one permitted reader to finish. This is the critical difference for read-heavy production caches.

Write throughput scales with bucket count: With default capacity 16, up to 16 threads can write to 16 different buckets simultaneously. At higher concurrency, pre-sizing to a larger capacity (new ConcurrentHashMap<>(capacity)) spreads writes across more buckets and reduces per-bucket contention.

Memory overhead: ConcurrentHashMap entries use volatile fields, which consume additional memory for the CPU cache coherence protocol. The size counter uses LongAdder-style distributed cells under high concurrency. Total memory per entry is roughly 1.5-2× that of HashMap. For maps holding tens of millions of entries, this overhead is significant.

Best Practices

Always use atomic compound operations — never check-then-act. map.putIfAbsent(key, value) is a single atomic operation. if (!map.containsKey(key)) map.put(key, value) is two operations separated by a window where another thread can insert — a classic race condition in any concurrent code. Similarly, map.computeIfAbsent(key, k -> new ArrayList<>()) creates the value exactly once per key even when 100 threads call it concurrently. map.merge(key, 1, Integer::sum) is the correct atomic counter pattern.

Never use size() for capacity enforcement logic. size() returns an estimate that can lag behind concurrent inserts and removes. The pattern if (map.size() < MAX_SIZE) { map.put(key, value); } has a race condition — two threads can both see size below the limit and both insert, exceeding it. Enforce limits inside a compute() that checks and acts atomically within the same lambda.

Declare the variable as ConcurrentMap<K, V> rather than ConcurrentHashMap<K, V>. Using the interface type gives you the putIfAbsent(), compute(), computeIfAbsent(), computeIfPresent(), merge(), and replace() atomic operations without coupling callers to the concrete class. Swapping to ConcurrentSkipListMap for sorted concurrent access requires no signature changes when the interface is declared.

Use ConcurrentHashMap.newKeySet() for thread-safe Sets. Collections.newSetFromMap(new ConcurrentHashMap<>()) and ConcurrentHashMap.newKeySet() both produce a Set<E> backed by ConcurrentHashMap. The newKeySet() factory is cleaner and produces a KeySetView<E, Boolean> that inherits all the concurrent read/write guarantees. This is the correct replacement for a Collections.synchronizedSet(new HashSet<>()).

Common Mistakes

Mistake 1 — Non-Atomic Check-Then-Act Pattern

Mistake 2 — Inserting null Key or Value

Mistake 3 — Wrapping ConcurrentHashMap in synchronizedMap

Mistake 4 — Using size() to Guard Capacity Limits

Interview Questions

Q1. What is ConcurrentHashMap and why was it introduced?

ConcurrentHashMap is a thread-safe Map in java.util.concurrent that replaced Hashtable as the correct solution for concurrent map access. Hashtable synchronises every method on a single global lock — every get() and put() from any thread acquires the same lock, serialising all operations. Under 100 concurrent threads, only one proceeds at a time while the other 99 wait. ConcurrentHashMap uses lock-free reads via volatile fields and per-bucket synchronisation for writes, allowing many threads to read simultaneously and multiple writers to operate in different buckets concurrently. It also provides atomic compound operations — putIfAbsent(), computeIfAbsent(), merge() — that Hashtable does not.

Q2. How does ConcurrentHashMap achieve lock-free reads?

ConcurrentHashMap marks its internal table[] array as volatile Node<K,V>[], and each node's val and next fields as volatile. In Java's memory model, a volatile read always returns the most recently written value — no CPU cache can return a stale copy. When get(key) executes, it reads table[bucketIndex] (volatile) and then walks the chain reading node.val (volatile), without acquiring any lock. A concurrent put() that completes before the get() starts is guaranteed to be visible. A put() still in progress at the moment of get() may or may not be visible — this is the weakly consistent read guarantee.

Q3. What is the CAS operation and where does ConcurrentHashMap use it?

CAS (Compare-And-Swap) is a single hardware instruction that atomically checks whether a memory location contains an expected value and replaces it with a new value only if the check succeeds. It either succeeds and updates the memory, or fails and returns — no spin, no lock. ConcurrentHashMap uses CAS to insert into an empty bucket: casTabAt(table, bucketIndex, null, newNode) — atomically place newNode only if that slot is currently null. If two threads race to insert into the same empty bucket, exactly one CAS wins and the loser retries through the synchronized(bucketHead) path. This makes the common case of inserting into uncrowded buckets entirely lock-free.

Q4. Why does ConcurrentHashMap not allow null keys or values?

Prohibiting null values eliminates an entire class of race conditions. In HashMap, get(key) returning null is ambiguous — it could mean the key is absent, or the key maps to null. Disambiguation requires containsKey(), but in concurrent code containsKey() and get() are two separate non-atomic operations — another thread can insert or remove between them. By prohibiting null values entirely, get() returning null unambiguously means the key is absent, removing the need for a second round-trip check. The same reasoning applies to null keys: the null-key handling in HashMap goes to bucket 0, but the ConcurrentHashMap bucket-locking design assumes non-null key comparisons.

Q5. What is the difference between compute(), computeIfAbsent(), and merge() in ConcurrentHashMap?

All three are atomic compound operations that avoid external synchronisation. computeIfAbsent(key, mappingFn) runs the mapping function only if the key is absent, atomically stores the result, and returns it — the function executes exactly once per key even under 100 concurrent callers. compute(key, remappingFn) always runs the function with the current value (or null if absent) and stores the return value, removing the key if null is returned. merge(key, value, mergeFn) stores value when the key is absent; when the key exists, calls mergeFn(existingValue, value) atomically and stores the result. merge(key, 1, Integer::sum) is the canonical thread-safe counter pattern.

Q6. What is weakly consistent iteration in ConcurrentHashMap?

A ConcurrentHashMap iterator never throws ConcurrentModificationException — it can be used safely even while other threads add or remove entries. The iterator reflects the state of the map at iterator creation time for entries that existed then. Entries added after the iterator was created may or may not be visited; entries removed after creation may or may not still appear. This "weakly consistent" contract contrasts with HashMap's fail-fast iterator (CME on any structural change) and CopyOnWriteArrayList's snapshot iterator (always sees exactly the state at creation). For monitoring, logging, and eviction sweeps, weakly consistent iteration is sufficient and the cost is zero — no snapshot copy is made.

FAQs

Is it safe to iterate ConcurrentHashMap while another thread modifies it?

Yes. ConcurrentHashMap's iterator is weakly consistent — it never throws ConcurrentModificationException regardless of concurrent modifications. The iteration reflects some partially consistent view: elements that existed at iteration start are visited; elements added or removed during iteration may or may not appear. For most monitoring and eviction use cases this is acceptable. If snapshot consistency is required, copy the map first: new HashMap<>(concurrentHashMap).

What is the difference between size() and mappingCount() in ConcurrentHashMap?

Both return an estimate of the number of entries and neither is exact under active concurrent modification. size() returns an int — capped at Integer.MAX_VALUE. mappingCount() returns a long — appropriate for maps that could theoretically exceed two billion entries. For business logic that depends on an exact count under concurrent access, maintain a separate AtomicLong counter alongside the map.

Can ConcurrentHashMap be used as a simple thread-safe cache?

Yes for basic caching — computeIfAbsent() loads values lazily and exactly once per key, remove() evicts entries, and entrySet().removeIf() performs bulk eviction safely. For production caches with TTL expiry, LRU eviction, statistics, and maximum size enforcement, consider the Caffeine library instead. It is built on ConcurrentHashMap internals but adds all cache-specific semantics.

What replaced the Segment array from Java 7 ConcurrentHashMap?

Java 7 divided the bucket array into 16 fixed Segment objects each with a ReentrantLock. The maximum true concurrency was the number of segments. Java 8 removed segments entirely and replaced them with bucket-level synchronized blocks combined with CAS for empty-bucket inserts. The effective concurrency level is now the number of occupied buckets — much higher than 16 — and the implementation is simpler, faster, and more adaptive.

How do I create a thread-safe Set using ConcurrentHashMap?

ConcurrentHashMap.newKeySet() returns a Set<E> backed by ConcurrentHashMap with all concurrency guarantees. add(), remove(), and contains() are all thread-safe. Iteration is weakly consistent. This is the correct replacement for Collections.synchronizedSet(new HashSet<>()).

Is ConcurrentHashMap safe for multi-key atomic operations?

No. ConcurrentHashMap guarantees atomicity only for single-key operations. The atomic methods — putIfAbsent, compute, merge, replace — are each atomic on their single key. There is no built-in way to atomically read key A and key B together or atomically move a value from A to B. For multi-key atomicity, use external synchronisation on a shared lock, or design the data model to avoid cross-key dependencies.

Summary

ConcurrentHashMap<K, V> achieves thread-safe O(1) map operations without a global lock. Reads are lock-free because every relevant field is volatile — no thread sees a stale value. Writes lock only the single bucket being modified. Empty-bucket inserts use CAS — a single hardware instruction, no lock at all. Multiple threads writing to different buckets never contend with each other.

Four rules govern correct production use: never insert null keys or values, never use size() for capacity enforcement (it is approximate), always prefer atomic compound operations over check-then-act patterns, and never wrap ConcurrentHashMap in synchronizedMap or add external locks to individual operations.

For interviews: explain lock-free reads via volatile fields, describe the CAS empty-bucket insert and the synchronized full-bucket path, explain why null is prohibited (the race between get and containsKey), describe weakly consistent iteration versus fail-fast, and walk through computeIfAbsent() as the correct thread-safe lazy-init pattern. These questions cover fresher rounds at TCS through senior architecture discussions at Flipkart, Razorpay, and Swiggy.

What to Read Next