Understanding the Implementation of Java ConcurrentHashMap (Differences Between JDK 1.7 and JDK 1.8)

ConcurrentHashMap is a core topic in many large‑scale system interviews; this article walks through its implementation details and the evolution from JDK 1.7 to JDK 1.8.

Contents: 1. Hash tables 2. Differences among ConcurrentHashMap, HashMap, and Hashtable 3. Changes between JDK 1.7 and JDK 1.8 implementations

1. Hash Table Basics

A hash table stores data as key‑indexed entries, allowing fast lookup by computing a hash of the key. Simple integer keys can be mapped directly to array indices; more complex keys require a hash function to distribute entries across buckets.

In a chained hash table each bucket is a linked list (or later a tree). Insertion hashes the key to a bucket, then inserts at the head of the list; lookup and removal first locate the bucket, then traverse the list.

Common cache systems (e.g., Redis, Memcached) and Java collections such as HashMap and ConcurrentHashMap are built on this principle.

2. Differences Between ConcurrentHashMap, HashMap, and Hashtable

HashMap is not thread‑safe; concurrent put operations can cause infinite loops and CPU spikes, so it must not be used in multithreaded contexts.

Hashtable provides thread safety by synchronizing every method, effectively placing a single lock on the entire table. This coarse‑grained locking serializes all operations and degrades performance under contention.

ConcurrentHashMap was created to address HashMap’s concurrency issues. It employs lock‑free techniques (volatile, final, CAS) and fine‑grained locking to reduce contention.

Both HashMap and ConcurrentHashMap use an array plus linked‑list structure; in JDK 1.8 the linked list can be replaced by a red‑black tree when a bucket becomes large.

3. JDK 1.7 Implementation of ConcurrentHashMap

JDK 1.7 uses an array + Segment + segment lock design.

Segment (segment lock) : each segment is a ReentrantLock that contains an internal Entry array and a linked list of entries, similar to a HashMap.

Data is first hashed to locate a Segment, then hashed again to locate the bucket within that segment. This two‑level hashing allows multiple threads to operate on different segments concurrently.

The advantages are that write operations lock only the relevant segment, enabling up to segmentCount concurrent writes. The drawback is the extra hashing step and the overhead of maintaining segment structures.

4. JDK 1.8 Implementation of ConcurrentHashMap

JDK 1.8 adopts the array + linked list + red‑black tree model, similar to JDK 8 HashMap, and relies heavily on CAS (compare‑and‑swap) operations.

CAS is an optimistic lock that updates a memory location only if it matches an expected value, reducing the need for heavyweight synchronization.

JDK 1.8 discards the Segment concept and introduces Node objects that store final int hash; final K key; volatile V val; volatile Node<K,V> next; . Nodes are placed directly in the array; synchronization is achieved via CAS and synchronized blocks.

When a bucket’s linked list exceeds a threshold (typically 8), it is transformed into a red‑black tree, improving lookup complexity from O(N) to O(log N).

5. Summary of ConcurrentHashMap Evolution

JDK 1.8’s structure closely mirrors HashMap, adding only the concurrency controls (CAS, synchronized) and the optional tree bins. Key differences include:

Data structure: from Segment‑based array + linked list to array + linked list + red‑black tree.

Thread‑safety mechanism: Segment locks (JDK 1.7) vs. CAS + synchronized (JDK 1.8).

Lock granularity: segment‑level locks vs. per‑node (bucket) locks.

Bucket conversion: linked list → red‑black tree when size > 8, reducing lookup time.

Overall, the JDK 1.8 implementation offers higher concurrency and better performance while preserving the familiar HashMap‑like API.