如何分析 ConcurrentHashMap 在 JDK 1.8 中通过 CAS 与 synchronized 实现的分段锁优化

大家好，我们又见面了啊~本文《如何分析 ConcurrentHashMap 在 JDK 1.8 中通过 CAS 与 synchronized 实现的分段锁优化》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

JDK 1.8 中 ConcurrentHashMap 彻底移除了 Segment 和分段锁，改用 CAS + 单桶（table[i]）级 synchronized 实现更细粒度并发控制；size()、扩容等均基于 table 数组与 CounterCell 协作完成，无任何“段”概念。

ConcurrentHashMap 在 JDK 1.8 中根本没有分段锁 —— 它彻底移除了 Segment，所谓“分段锁优化”是误传或混淆了 JDK 1.7 的设计。真正起作用的是 CAS + 单桶（table[i]）级 synchronized，粒度比 Segment 更细，也更轻量。

为什么说“分段锁优化”这个说法本身就不成立

JDK 1.7 确实用 Segment 数组实现分段锁，每个 Segment 是一个独立的 ReentrantLock，并发度默认为 16；但 JDK 1.8 的源码里已完全删掉 Segment 类，ConcurrentHashMap 的核心字段只剩 table、nextTable、sizeCtl 和 baseCount。所有“分段”“段锁”“并发度设置”等概念在 1.8 中既无对应类，也无对应逻辑。

• 调用 new ConcurrentHashMap(16, 0.75f, 32) 时，第三个参数（原 JDK 1.7 的 concurrencyLevel）会被忽略，仅用于计算初始容量
• size() 不再遍历多个 Segment 求和，而是依赖 baseCount + CounterCell 数组的 CAS 累加
• 扩容不再按 Segment 分批进行，而是由多个线程协作迁移 table 中的桶（transfer 方法）

tabAt 和 casTabAt 是 CAS 操作的实际入口

所有无锁写入都围绕这两个 Unsafe 辅助方法展开，它们直接操作 table 数组的指定下标，不依赖锁：

• tabAt(table, i)：volatile 读取 table[i]，保证看到其他线程写入的最新节点
• casTabAt(table, i, c, v)：比较并交换 table[i]，仅当当前值等于 c 时才设为 v；失败则重试（如 putVal 中的 for 自旋）
• 初始化 table、插入首个节点、协助扩容标记位（MOVED）、更新计数器等关键路径都优先走 CAS

注意：casTabAt 失败不等于操作失败，而是进入下一步：检查是否需要加锁（比如该桶已有节点，需 synchronized 链表头节点）。

什么时候会触发 synchronized？只锁链表/红黑树的首节点

不是锁整个数组，也不是锁某个逻辑“段”，而是当 CAS 插入失败且桶非空时，对 table[i] 当前引用的首节点加锁：

• 锁对象是 f（即 tabAt(table, i) 返回的 Node），不是 this，也不是全局锁
• 加锁后检查该桶是否已被其他线程改为红黑树（fh ），若是则走树的插入逻辑；否则遍历链表或插入尾部
• 红黑树的读写操作（putTreeVal、find）内部也只对树根节点加锁，不影响其他桶
• 这意味着：两个线程往不同桶（i != j）写，完全无竞争；往同一桶写，才可能因锁首节点而短暂阻塞

容易被忽略的细节：volatile 的边界与 sizeCtl 的多重语义

volatile 修饰的字段不是万能的，它只保证单变量的可见性，不保证复合操作原子性。例如：

• table 是 volatile，但 table[i] = new Node(...) 这一赋值本身是原子的；而 table[i].val = value 依赖节点内 val 字段也是 volatile 才可见
• sizeCtl 是个“多面手”：初始化时为 -1，扩容中为 -(1 + 参与扩容线程数)，扩容结束前为新容量阈值，正常运行时为下次扩容阈值；读写它必须配合 CAS，不能直接赋值
• 链表转红黑树的条件有两个缺一不可：binCount >= TREEIFY_THRESHOLD (8) 且 tab.length >= MIN_TREEIFY_CAPACITY (64)；少一个都不会触发树化，这点常被调试时忽略

真正难啃的部分不在“怎么加锁”，而在理解 sizeCtl 状态机、transfer 协作迁移协议、以及 CounterCell 如何避免计数热点 —— 这些才是 JDK 1.8 并发设计的实质复杂点。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《如何分析 ConcurrentHashMap 在 JDK 1.8 中通过 CAS 与 synchronized 实现的分段锁优化》文章吧，也可关注golang学习网公众号了解相关技术文章。