Inside ConcurrentHashMap: Architecture, Features, and Performance Tricks

This article answers three main questions about ConcurrentHashMap:

Overall Architecture

In JDK 1.8 the storage structure consists of an array, singly‑linked lists, and red‑black trees. When a ConcurrentHashMap instance is created, it initializes an array of length 16. Because the core is still a hash table, hash collisions are inevitable.

ConcurrentHashMap resolves collisions with chaining. When a bucket’s chain becomes long, the lookup complexity would degrade to O(n). Therefore, when the array length exceeds 64 and a chain length reaches 8, the linked list is transformed into a red‑black tree. Conversely, during dynamic resizing, if a tree’s size falls below 8, it collapses back to a linked list.

Basic Functionality

ConcurrentHashMap is essentially a thread‑safe version of HashMap. It provides the same API as HashMap, but ensures concurrent safety by locking individual Node entries during updates.

Performance Optimizations

Lock granularity was refined in JDK 1.8: locks are applied to individual bins rather than the larger Segment objects used in JDK 1.7, reducing contention. The introduction of red‑black trees lowers lookup complexity to O(log n). During resizing, a multithreaded expansion mechanism partitions the original array so that multiple threads migrate different segments concurrently, improving resize throughput.

For the size() method, ConcurrentHashMap uses two strategies to maintain an accurate element count with low overhead. When contention is low, a CAS operation increments a counter directly. Under high contention, an array of counters is used; a random counter is selected and incremented via CAS, distributing the load across multiple cells.