ConcurrentHashMap并发安全实现解析

ConcurrentHashMap 的并发安全并非依赖传统的大锁机制，而是通过 volatile 字段的内存可见性保障、CAS 无锁写入、细粒度桶级同步（仅锁单个 Node 头节点）以及渐进式扩容等精巧设计实现高效读写分离：get 操作全程无锁、仅三次内存访问，借助 volatile 和 happens-before 语义确保原子读取与自动路由新表；put 则按需升级为轻量同步，避免全局阻塞；扩容更以协作式、分段迁移的方式让读写持续可用。从 JDK 1.7 的固定分段锁到 1.8 的动态桶锁+红黑树优化，其演进本质是用更少的锁、更准的控制和更强的内存模型语义，在高并发场景下兼顾性能、安全与可伸缩性——理解它，就是理解现代 Java 并发编程的底层智慧。

ConcurrentHashMap 为什么 get 不加锁也能安全？

因为 Node 的关键字段都声明为 volatile：比如 val 和 next。只要一个线程写入了新值，其他线程读取时就能立刻看到最新结果——这是 JVM 内存模型的 happens-before 保证，不是靠锁，而是靠语义约束。

常见错误现象：有人误以为 “没加锁 = 可能读到中间状态”，但在 get 场景下，只要不涉及复合操作（比如先读再算再写），单次读取 volatile 字段就是原子且可见的。

• get 操作全程无锁，只做三次内存访问：定位数组索引 → 读首节点 → 遍历链表或红黑树（若存在）
• 如果首节点是 ForwardingNode（hash = -1），说明正在扩容，get 会直接去新表查，无缝切换
• 红黑树节点封装在 TreeBin 中，其内部查找也用 volatile 保护结构字段，不依赖锁

put 是怎么避免竞争覆盖的？CAS + 自旋 + 细粒度锁

putVal 的核心不是“抢一把大锁”，而是分阶段控制：先用 CAS 尝试无锁写入空槽；失败则退到 synchronized 锁住单个桶（Node 首节点）；极端情况（如链表转树）才升级锁范围。

容易踩的坑：以为 “synchronized 锁的是整个 ConcurrentHashMap”，其实它只锁当前桶的头节点（f），其它桶完全不受影响。

• 首次插入空桶：调用 casTabAt(tab, i, null, new Node(...))，成功即退出
• 发现桶非空且未扩容：用 synchronized(f) 锁住该 Node，再遍历链表/树插入或更新
• 遇到 ForwardingNode（hash == -1）：说明有线程正在扩容，当前线程主动调用 helpTransfer 协助搬数据
• 不允许 null key/value：一上来就抛 NullPointerException，这点和 HashMap 不同

扩容过程如何做到读写不阻塞？

扩容不是“停服重建”，而是渐进式迁移：新旧两张表并存，用 sizeCtl 控制状态，每个线程只负责搬自己分到的一小段（stride 默认 16 个桶），老表仍可读写，新表逐步填充。

性能影响：扩容期间 get 自动路由到新旧表，put 若命中已迁移的桶则直接写新表，否则先帮搬再写——所以并发越高，扩容越快，但单次 put 延迟可能略升。

• 触发条件：addCount 检测到元素数超过 sizeCtl（≈ table.length × 0.75）
• 初始扩容线程将 sizeCtl 设为负数标记（如 -2），后续线程通过 CAS 递增计数器加入协作
• 每个线程处理一个区间：从高位开始逐段扫描，搬完一段就更新 transferIndex，避免重复
• 搬完后，最后一个线程把 nextTable 赋给 table，并重置 sizeCtl 为新容量阈值

JDK 1.7 和 1.8 的并发模型差异在哪？

1.7 是“分段锁（Segment）”，1.8 是“桶级锁（synchronized on Node）+ CAS”，前者锁粒度固定（默认 16 段），后者动态适配实际冲突热点，更轻量、更灵活。

兼容性注意：1.7 的 concurrencyLevel 参数在 1.8 中仅保留用于向后兼容，实际不再划分 Segment，传参无效。

• 1.7：每个 Segment 是 ReentrantLock 子类，锁住整个段，最多支持 concurrencyLevel 个线程并发写
• 1.8：彻底去掉 Segment，用 Node[] + volatile + CAS + synchronized 替代，锁只落在具体桶的头节点上
• 1.8 新增红黑树支持：当链表长度 ≥ 8 且数组长度 ≥ 64，自动树化，查找从 O(n) 降到 O(log n)
• 1.8 的 spread 方法对 hash 做二次扰动（高16位异或低16位），比 1.7 的两次哈希更简洁高效

真正难啃的是扩容协作逻辑和各种状态码（如 MOVED、TREEBIN、RESERVED）的边界判断——这些不是靠死记，而是在调试多线程压测时，盯着 sizeCtl 和 nextTable 的变化才能真正吃透。

本篇关于《ConcurrentHashMap并发安全实现解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！