ConcurrentHashMap分段锁机制解析

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《ConcurrentHashMap分段并发控制详解》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

ConcurrentHashMap在JDK 7中采用Segment分段锁，JDK 8+改用CAS+synchronized单桶锁；前者默认16段，后者锁粒度更细、支持协助扩容，且size()均为近似值。

ConcurrentHashMap 在 Java 中实现分段并发控制的方式，取决于你使用的 JDK 版本：JDK 7 用的是“分段锁（Segment）”，而 JDK 8 及以后彻底改用“CAS + synchronized + 链表/红黑树”方案，不再有传统意义上的“分段”。

JDK 7：基于 Segment 的分段锁机制

在 JDK 7 中，ConcurrentHashMap 内部维护一个 Segment 数组，每个 Segment 本质是一个加了锁的 HashEntry 数组，相当于一个小型的 Hashtable。

• 默认有 16 个 Segment，即最多支持 16 个线程并发写入不同段，互不阻塞
• put 操作时，先根据 key 的 hash 值定位到具体 Segment，再对该 Segment 加锁（可重入锁），其他 Segment 仍可被其他线程操作
• get 不加锁，通过 volatile 修饰的 value 和引用保证可见性
• 扩容是单个 Segment 自行扩容，不影响其他段

JDK 8+：放弃 Segment，转向细粒度锁优化

JDK 8 彻底移除了 Segment，改用更轻量、更灵活的并发策略：

• 底层仍是数组 + 链表/红黑树结构，但锁粒度降到“单个桶（bin）”级别
• put 操作先无锁尝试 CAS 插入；失败后，若该桶头节点已存在，则对头节点 synchronized 加锁（锁对象是链表头或红黑树根）
• 多个线程往不同桶写入完全不冲突；即使哈希冲突，也只锁冲突链/树的头节点，不影响其他桶
• 扩容采用“多线程协助扩容”机制：首次触发扩容的线程初始化新数组，后续 put 发现正在扩容，会主动帮助迁移部分旧桶数据

为什么 JDK 8 要去掉 Segment？

Segment 虽然比 Hashtable 更高效，但仍存在一些局限：

• Segment 是可重入锁，本身有较大内存和调度开销
• 固定段数（默认 16）无法动态适配 CPU 核心数或实际并发压力
• 跨段操作（如 size()、containsValue()）需遍历所有 Segment 并加锁，性能差且结果可能不精确
• CAS 和 synchronized 在现代 JVM 中优化得更好，单桶锁的实际竞争概率更低

使用建议与注意事项

无论哪个版本，ConcurrentHashMap 都不是“绝对线程安全”的万能替代品：

• 复合操作（如“检查再插入”）仍需手动同步，推荐用 computeIfAbsent / merge 等原子方法
• 迭代器弱一致性：遍历时允许其他线程修改，不会抛 ConcurrentModificationException，但可能看不到最新更新
• size() 返回的是近似值（JDK 8 中通过 baseCount + CounterCell 数组估算），如需精确计数，应考虑 LongAdder 或额外同步
• 不要把它当“线程安全的 HashMap”盲目替换 —— 如果场景是读多写少且无强一致性要求，它很合适；但涉及复杂逻辑时，仍要审视是否真需要它的并发能力

基本上就这些。理解它“怎么锁”比死记 API 更重要 —— 锁在哪、锁多久、谁在等，直接决定你的并发性能和正确性。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ConcurrentHashMap分段锁机制解析》文章吧，也可关注golang学习网公众号了解相关技术文章。