Implementation Principles of ConcurrentHashMap (CurrentHashMap) in JDK 1.7 and JDK 1.8

Hash tables store data as key‑value pairs, allowing fast lookup by hashing the key. Simple integer keys can be mapped directly to array indices, while more complex keys require a hash function to distribute entries across buckets.

In a chained hash table each bucket is a linked list (or "chain"). Insertion hashes the key to a bucket and inserts the new node at the head of the list; lookup and removal first locate the bucket, then traverse the chain to find the target element.

Typical use cases include in‑memory caches such as Redis or Memcached, and Java collections like HashMap and ConcurrentHashMap.

Differences among Map implementations:

HashMap is not thread‑safe; concurrent puts can cause infinite loops and high CPU usage.

Hashtable has a similar structure but disallows null keys/values and synchronizes every operation, effectively applying a single global lock.

ConcurrentHashMap was created to provide a thread‑safe alternative with higher concurrency.

Both HashMap and ConcurrentHashMap use an array of buckets, but ConcurrentHashMap adds concurrency control. In JDK 1.7 it employs an array + Segment + lock design, where each Segment is a ReentrantLock‑protected sub‑map containing its own bucket array and linked lists.

The JDK 1.7 structure requires two hash computations: the first to locate the Segment, the second to locate the bucket within that Segment. This fine‑grained locking allows multiple threads to operate on different Segments simultaneously, improving throughput.

Advantages of the segment design include reduced contention (only the Segment containing the target entry is locked) and the ability to support as many concurrent writes as there are Segments, provided the workload is evenly distributed. The drawback is an extra hashing step compared to a plain HashMap.

In JDK 1.8 the segment concept was removed. ConcurrentHashMap now uses an array + linked list + red‑black tree structure similar to HashMap, but with extensive use of CAS (compare‑and‑swap) and synchronized blocks for safety. When a bucket’s chain exceeds a threshold (typically 8), it is transformed into a red‑black tree, reducing lookup complexity from O(N) to O(log N).

The core node type in JDK 1.8 is class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; volatile V val; volatile Node<K,V> next; // ... other fields and methods } , which stores the hash, key, value, and a volatile reference to the next node.

Overall, the evolution from JDK 1.7 to JDK 1.8 shows a shift from coarse‑grained segment locks to fine‑grained node‑level synchronization with lock‑free techniques, resulting in higher concurrency, reduced contention, and improved lookup performance thanks to the optional red‑black tree conversion.