jdk 8 中 concurrenthashmap 彻底移除 segment 分段锁，改用 cas + synchronized 桶级锁，链表超阈值转红黑树，并支持多线程协同扩容，显著提升并发性能与吞吐量。
ConcurrentHashMap 在 JDK 8 中的重构，核心是彻底移除了 JDK 7 的 Segment 分段锁机制，转而采用更轻量、更细粒度的 CAS + synchronized 锁机制，并在链表过长时升级为红黑树，显著提升了高并发下的吞吐量与扩容效率。
Segment 被淘汰：从分段锁到更细粒度的桶级加锁
JDK 7 中 ConcurrentHashMap 用 Segment 数组模拟“小 HashMap”，每个 Segment 是一个可重入锁（ReentrantLock），写操作需锁定整个 Segment，虽然比 Hashtable 全局锁好，但仍有锁竞争和内存开销问题。JDK 8 彻底废弃 Segment，改用 Node 数组 + volatile + CAS 操作管理元素；真正需要加锁时，只对发生冲突的单个桶（即数组某个索引位置）使用 synchronized，锁粒度从“一段”缩小到“一个桶”，并发度大幅提高。
CAS 成为读写协调的核心基础
大多数无冲突的写操作（如 putIfAbsent、computeIfAbsent）通过 Unsafe 的 CAS 原子操作完成，无需加锁；只有当目标桶为 null 或发生哈希冲突（如多个线程同时向同一桶插入）时，才进入 synchronized 块处理。CAS 保证了 head 节点更新、链表头插、扩容标记等关键步骤的原子性，避免了锁带来的上下文切换开销。
红黑树解决链表退化性能瓶颈
当同一个桶中链表节点数 ≥ 8 且 table 长度 ≥ 64 时，链表会转换为红黑树；反之，删除后节点 ≤ 6 时再退化回链表。该设计并非单纯为了“更快”，而是防止极端哈希碰撞下 O(n) 查找退化为 O(log n)，保障最坏情况下的查询/更新时间复杂度。注意：树化前提是数组已足够大（≥64），避免小表频繁树化带来额外开销。
扩容机制升级：支持多线程协同迁移
JDK 8 引入了 helpTransfer 和 transfer 协作扩容机制：当一个线程触发扩容，其他线程在访问到正在扩容的桶时，会主动协助迁移数据；扩容不是全量复制，而是将原 table 拆分为多个任务块，由多个线程并行搬运，极大缩短扩容阻塞时间。迁移过程中，新旧 table 并存，查找逻辑自动兼容两个结构。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
