ConcurrentHashMap分段锁原理详解

ConcurrentHashMap 1.7 通过 Segment 分段锁机制在哈希表中划分出默认16个独立加锁的并发单元，让不同Segment上的线程可并行写入，显著优于HashTable的全局锁，但其设计也埋下了性能与扩展性隐患：需两次hash定位、get依赖volatile导致弱一致性、size()等操作需遍历重试且性能低下，Segment数量在构造时由concurrencyLevel决定并向上取整为2的幂，不可动态调整，更致命的是Segment上限被硬编码为1（实际应为“最大支持1

ConcurrentHashMap 1.7 为什么用 Segment 分段锁？

因为直接给整个哈希表加锁（像 HashTable 那样）会把所有线程堵成一列，而 JDK 1.7 想让“不碰同一块数据”的线程能真正并行写入——Segment 就是那块被独立加锁的数据单元。

每个 Segment 本质是一个小型 HashEntry[] 数组 + ReentrantLock，默认 16 个，意味着最多 16 个线程可同时在不同 Segment 上执行 put；但只要两个线程的 key 落到同一个 Segment，就会排队等锁。

• 定位 key 需两次 hash：hash(key) → 算出 Segment 下标；再用部分 hash 值 → 算出该 Segment 内部数组下标
• get 操作全程无锁，只靠 volatile 保证可见性，但可能读到旧值（弱一致性）
• size() 和 containsValue() 必须遍历全部 Segment 并尝试加锁，可能阻塞或重试多次，性能差且结果未必实时

Segment 数量能动态调整吗？

不能。并发级别（concurrencyLevel）在构造时就决定了 segments 数组长度，之后固定不变；扩容只发生在单个 Segment 内部（即它的 HashEntry[] 数组），不会改变 Segment 总数。

• 传入 concurrencyLevel = 17，实际会向上取整为 32（最近的 2 的幂），不是“刚好 17 个锁”
• 设得太小（如 2）→ 锁竞争激烈，退化成接近 HashTable 性能
• 设得太大（如 65536）→ 内存占用高、初始化慢，且多数 Segment 长期空闲，无实际并发收益

Segment 里的 HashEntry 为什么用 volatile 修饰 next 和 value？

因为 get 不加锁，必须靠 volatile 保证其他线程对链表结构和值的修改能被立即看到；否则可能读到 null 或过期 value，甚至因指令重排序导致链表断裂。

• HashEntry 的 key 和 hash 是 final，天然安全；next 和 value 是 volatile，构成“安全发布”链路
• 但注意：volatile 不保证复合操作原子性，比如 value++ 仍需额外同步
• 链表头插入是唯一写法（避免 tail 竞争），所以 next 的 volatile 能覆盖大多数可见性场景

和 JDK 1.8 的 ConcurrentHashMap 相比，1.7 的 Segment 设计有哪些硬伤？

Segment 是一个权衡产物，它解决了全表锁问题，但也带来了结构性瓶颈：

• 两次 hash 计算开销比 1.8 的一次 hash 高；定位路径更长，CPU cache 友好度差
• Segment 数量上限硬编码为 1 ，无法支撑超大规模并发写入场景
• 扩容是单 Segment 串行进行，无法多线程协作迁移，扩容期间该 Segment 完全阻塞
• 链表无树化机制，当某个 Segment 内哈希冲突严重时，查询退化为 O(n)，且无法缓解

这些限制正是 JDK 1.8 彻底移除 Segment、改用 CAS + synchronized 锁单个桶（bin）的根本原因——粒度更细、结构更扁平、扩容可并行，但代价是代码逻辑复杂度大幅上升。

今天关于《ConcurrentHashMap分段锁原理详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！