Java 8 ConcurrentHashMap 改用 CAS + synchronized 的核心目的是将锁粒度从 Segment 缩至单个桶头节点，实现按需锁定；CAS 处理无竞争操作，synchronized 仅保护桶内结构变更，配合 JVM 对 synchronized 的优化，使细粒度锁高效可行。
Java 8 的 ConcurrentHashMap 放弃分段锁、改用 CAS + synchronized，核心目的不是简单换锁，而是把“锁住什么”这件事做到极致精细——从一段数组，缩到一个节点；从粗放管控，转向按需锁定。
锁粒度从 Segment 降到单个桶头
JDK 7 中，ConcurrentHashMap 使用 Segment 数组，默认 16 段，每个 Segment 是一个继承自 ReentrantLock 的独立锁。哪怕只往同一个哈希桶写数据，只要它落在同一段内，其他桶的操作也会被阻塞。
JDK 8 彻底移除 Segment，底层是 Node[] 数组。当线程执行 put 时：
- 先通过哈希值定位到具体桶（即
tab[i]） - 若该桶为空，直接用 CAS 尝试插入新节点，全程无锁
- 若该桶非空（已有链表或红黑树），才对桶的首节点（
tab[i]指向的Node）加synchronized
这意味着：两个线程操作不同桶，完全不竞争；只有哈希冲突到同一桶时，才会进入同步块——锁范围精准控制在“一个链表头”或“一棵红黑树的根节点”上。
立即学习“Java免费学习笔记（深入）”；
CAS 承担无竞争路径，synchronized 守住结构变更临界区
CAS 不是替代锁，而是与 synchronized 分工协作：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- CAS 用于初始化数组、更新数组引用、设置
next指针、协助扩容迁移等“无状态修改”场景，避免线程挂起开销 -
synchronized只在真正需要改变桶内结构时介入，比如：
– 向非空链表尾部插入新节点
– 触发链表转红黑树（treeifyBin）
– 扩容时迁移当前桶的所有节点
这种组合让高并发下绝大多数操作走轻量无锁路径，仅在真正发生结构竞争时才启用重量级保障，既保安全，又控成本。
JVM 对 synchronized 的优化让细粒度锁真正可行
早期 synchronized 是重量级锁，依赖操作系统互斥量，上下文切换代价高。但 JDK 6 起，JVM 加入多层优化：
- 偏向锁：无竞争时，直接将锁对象标记为某线程持有，零开销
- 轻量级锁 + 自旋：竞争不激烈时，线程在用户态忙等，避免陷入内核态
- 锁消除 / 锁粗化：JIT 编译器可识别局部锁作用域，自动剔除或合并
正因这些优化，JDK 8 才敢把 synchronized 用在每个桶头上——它不再是“大锁”，而成了可伸缩的、按需激活的“微锁单元”。
对比效果：从固定瓶颈走向动态适配
分段锁的缺陷在于静态分配：
- 段数写死（默认 16），负载低时大量段闲置，浪费锁资源
- 负载高时段数不够，多个桶挤在同一段，锁竞争反而加剧
- 扩容需整段复制，无法并行，吞吐受限
而 Node + CAS + synchronized 方案天然支持动态伸缩：
- 锁数量随实际使用桶数增长，空桶不占锁
- 扩容由多线程协作完成，每个线程负责若干桶的迁移，读写不中断
- 写热点只出现在哈希严重碰撞的个别桶，而非全局段争抢
