Why Java 8 ConcurrentHashMap.get() Is Lock‑Free and How Volatile Guarantees Thread‑Safety

ConcurrentHashMap is a thread‑safe concurrent collection in Java. Unlike earlier versions, the get method in JDK 1.8 performs no explicit locking, which raises the question of how it avoids dirty reads.

ConcurrentHashMap Overview

In JDK 1.7 the implementation relied on Segment + HashEntry + ReentrantLock. JDK 1.8 replaced the bulky segment design with a simpler Node + CAS + synchronized approach, reducing lock granularity from segment level to individual hash entries.

Lock granularity is now per hash entry (the first node) rather than per segment.

The data structure is simpler, using synchronized for updates and eliminating the need for segment locks.

Long linked‑list buckets are replaced by red‑black trees when a threshold is exceeded, improving lookup performance.

Lock‑Free get Logic

The get operation follows these steps:

Compute the hash and locate the table index.

If the first node matches the hash, return its value.

If the node indicates an ongoing resize ( ForwardingNode) or a tree bin, delegate to the appropriate find method.

Otherwise traverse the linked list until a matching key is found or the end is reached.

public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    int h = spread(key.hashCode()); // compute hash
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (e = tabAt(tab, (n - 1) & h)) != null) {
        if ((eh = e.hash) == h) {
            if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                return e.val;
        } else if (eh < 0) {
            return (p = e.find(h, key)) != null ? p.val : null;
        }
        while ((e = e.next) != null) {
            if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek))))
                return e.val;
        }
    }
    return null;
}

Notice that no lock is acquired anywhere in this method.

Role of volatile

Visibility in Java is ensured by the volatile keyword, which guarantees that writes to a volatile variable are immediately flushed to main memory and that subsequent reads see the latest value. It does not provide atomicity.

In the context of ConcurrentHashMap:

The array holding the bins is declared transient volatile Node<K,V>[] table;. Marking the array volatile ensures that when the table reference changes during a resize, all threads see the new array.

Each Node contains volatile V val; and volatile Node<K,V> next;. These volatile fields make updates to a node’s value or its successor visible to other threads without additional locking.

static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    volatile V val;          // visible to other threads
    volatile Node<K,V> next;  // visible to other threads
    ...
}

The array’s volatile modifier does not affect individual element reads; it only guarantees that the reference to the array itself is visible after a resize.

Summary

In JDK 1.8, ConcurrentHashMap.get() is lock‑free, contributing to higher throughput compared with older synchronized maps.

The lock‑free property stems from volatile‑marked val and next fields in Node, not from the volatile array itself.

The array is declared volatile solely to make the new table visible to all threads during resizing.