ConcurrentHashMap Internals: From Segment to CAS + synchronized

In JDK 1.7, ConcurrentHashMap used a Segment-based design. The map was divided into an array of Segments — default 16 — and each Segment was a small HashMap protected by its own ReentrantLock. A write only locked one segment, so writes to different segments ran in parallel. The concurrency limit was the segment count, and size() required locking every segment (later optimized with retries and optimistic sums). In JDK 1.8 the design was rewritten. Segments were removed; the map is a Node array like HashMap, with a linked list or red-black tree per bucket. Thread safety is achieved with a combination of CAS and synchronized: for the very first insert into an empty bucket, a CAS swaps in a new head Node — no lock needed. For subsequent inserts into a non-empty bucket, synchronized locks on the head Node of that specific bucket. Different buckets are independent, so concurrency is effectively per-bucket rather than per-segment — much finer granularity. get() is lock-free: Node's val and next fields are volatile, so reads just traverse the bucket and return. This makes reads extremely fast even under heavy write concurrency. Resize is also parallel — when a thread attempts a put during a resize, it can be recruited to help transfer buckets to the new table. Transferred buckets are replaced with a sentinel ForwardingNode that points to the new table, so concurrent readers see the ForwardingNode and transparently follow it to the new bucket. size() in 1.8 uses LongAdder-style striped counters — each thread updates its own counter cell to avoid contention, and size() sums the cells. This approach gives much higher throughput than 1.7, especially for workloads with concentrated writes. The tradeoff is the code is more complex and synchronized on the head Node creates some contention on "hot" buckets — but in practice it's dramatically better than segment locks.