登录
首页 >  文章 >  java教程

Java分段锁与ConcurrentHashMap演变解析

时间:2026-03-03 17:46:33 393浏览 收藏

本文深入剖析了Java中分段锁思想在ConcurrentHashMap从1.7到1.8版本的演进历程:1.7版通过Segment数组实现粗粒度分段加锁,虽提升了并发度但存在哈希倾斜退化、size()阻塞、内存冗余等固有缺陷;而1.8版彻底摒弃Segment,转而采用CAS无锁插入+同步锁单个Node的细粒度策略,并引入红黑树优化高碰撞场景,显著提升吞吐与扩展性——这不仅是一次API升级,更是对“锁粒度与性能平衡”这一核心并发命题的深刻实践,值得每一位Java开发者重新审视底层设计逻辑与真实业务场景间的匹配关系。

什么是Java中的分段锁思想_ConcurrentHashMap从1.7到1.8的演进

分段锁在ConcurrentHashMap 1.7里怎么实现的

ConcurrentHashMap 1.7 的分段锁本质是把整个哈希表切成了 Segment 数组,每个 Segment 是一个独立的 ReentrantLock + 小型哈希表。写操作(如 put)只锁住对应 key 落入的那个 Segment,其他段还能并发读写。

常见错误现象:以为“分段”能彻底避免锁竞争——其实如果大量 key 哈希后落在同一个 Segment(比如自定义 hashCode 返回固定值),那它就退化成单点瓶颈,吞吐不升反降。

实操建议:

  • concurrencyLevel 参数只是初始化 Segment 数组长度的提示值,不是硬上限;实际段数会取大于等于该值的最小 2 的幂(如传 10 → 实际用 16 段)
  • 每个 Segment 内部仍是数组 + 链表,扩容时只扩本段,但 size() 需要尝试加锁所有段来累加,可能阻塞较久
  • JDK 1.7 的 get() 完全无锁,靠 volatile 变量和不可变节点保证可见性——这点常被误认为“读也加锁”,其实不是

为什么 1.8 彻底干掉了 Segment

因为 Segment 带来额外内存开销(每个段都有一套 table、count、modCount 等字段),且无法解决单个桶(bin)的并发冲突——只要两个线程往同一个链表头插入,还是得串行。

1.8 改用“CAS + synchronized 锁单个 Node”:数组元素(Node)本身作为锁粒度,配合 TreeBin 在链表过长时转红黑树,进一步降低哈希碰撞下的查找/插入成本。

实操建议:

  • 1.8 的 put() 先无锁 CAS 插入头节点,失败才用 synchronized (f) 锁住该桶的首节点(f),不是锁整个 table
  • 扩容(transfer)变成协作式迁移:多个线程可同时参与搬数据,每个线程负责一段 table 区间,通过 stride 控制粒度
  • 注意 computeIfAbsent 这类方法在 1.8 中可能触发树化或扩容,若 lambda 里有阻塞操作,会卡住整个桶,影响其他线程对该桶的操作

从 1.7 升级到 1.8 后哪些行为变了

最易踩坑的是迭代器语义和 size() 行为差异:1.7 的 keySet().iterator() 是弱一致性(weakly consistent),允许遍历时修改;1.8 的迭代器仍弱一致,但内部结构变化更频繁(树/链表切换、扩容中迁移),导致某些遍历结果更“跳跃”。

性能上,1.8 在高并发写+低哈希碰撞场景下优势明显;但若写操作极少、读极多,1.7 的无锁 get() 和更简单的结构反而更轻量。

实操建议:

  • size() 在 1.7 中需加锁统计所有 Segment,可能慢;1.8 改用 baseCount + CounterCell[] 的 CAS 累加,但仍是近似值——严格计数请改用 mappingCount()
  • 1.8 不再支持 rehash 相关监控(如 segments 字段已不存在),依赖反射或 JMX 查看内部状态的代码会直接失败
  • 自定义 Comparator 用于树化时,必须满足与 equals() 一致的逻辑,否则 containsKey 可能返回 false(即使 key 存在)

现在还该手动分段锁吗

几乎不该。除非你在 JDK 1.7 环境下维护老系统,或者面对的是极特殊场景:比如某个业务 key 天然聚合成几十个大组,每组内操作高度隔离,且你愿意承担自己实现锁分片、负载均衡、扩容协调的复杂度。

现实中,JDK 1.8 的 ConcurrentHashMap 已经把锁粒度压到单个桶,配合 CAS 和树化,对绝大多数场景足够。手动分段反而容易引入死锁(比如跨段操作没按固定顺序加锁)、状态不一致(段间计数不同步)等问题。

真正要注意的其实是:别把 ConcurrentHashMap 当作通用线程安全容器去塞各种复杂对象——它的线程安全只保障自身结构变更,value 对象内部状态是否线程安全,它不管。

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

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>