1. 从线上故障说起为什么要重新认识 ConcurrentHashMap很多同学对 ConcurrentHashMap 的印象停留在“并发版的 HashMap线程安全性能比 Hashtable 好”但真到线上出问题的时候你会发现这个认知远远不够。我最早被这个类“教育”是在某跨平台系统的模拟项目压测中服务启动正常QPS 一上来CPU 直接打满线程栈一抓全部卡在ConcurrentHashMap.putVal和treeifyBin这两个方法里。那时候我才意识到光知道“它线程安全”完全没用你得知道它内部到底怎么加锁、怎么扩容、怎么在极端竞争下退化成串行才能在写代码时避开那些性能陷阱。从 JDK 8 开始ConcurrentHashMap的内部实现逻辑其实已经重写了一遍和 JDK 7 的分段锁完全是两套思路。JDK 8 版本抛弃了 Segment转而使用 CAS synchronized 的组合方案锁粒度从“段”细化为“单个桶位”并发度理论上可以撑到和哈希表桶数量一样高。这听起来很美好但代价是代码复杂度大幅上升尤其是扩容那部分设计了一个“多线程协助迁移”的机制很多问题都藏在细节里。这篇内容适合三类人第一类是刚接触并发编程、想搞明白 ConcurrentHashMap 为什么比 Hashtable 强的新手第二类是已经用过 ConcurrentHashMap 但没读过源码、想系统梳理内部结构的进阶开发者第三类是遇到线上并发问题需要排查和调优的实战派。我会把它的结构、读写流程、扩容机制、常见陷阱一层层拆开讲尽量让每个结论都能落到实际代码上。2. JDK 7 与 JDK 8 的架构差异锁粒度才是核心2.1 分段锁时代以空间换并发JDK 7 版本的 ConcurrentHashMap 内部维护了一个 Segment 数组每个 Segment 本质是一把继承自 ReentrantLock 的锁同时每个 Segment 管理着一个小型的 HashEntry 数组。默认 Segment 数量是 16也就是说你最多只有 16 个线程能同时写这个 Map且每个线程只能写属于自己的那一段。这种设计的优势是读操作完全不需要加锁因为 HashEntry 里的 value 和 next 字段都是 volatile 修饰的靠 volatile 的可见性保证读到的数据不是过期的。写操作只需要锁住目标 Segment其他 Segment 的读写不受影响。但问题也很明显Segment 数量在构造时固定不支持扩容。如果数据量很大哈希冲突集中在某几个 Segment 上那这几个 Segment 的锁竞争会非常激烈其他 Segment 却空着并发能力被白白浪费。而且如果两个线程恰好访问了同一个 Segment 下的不同桶位它们依然会被同一把锁挡住这就是“锁粒度太粗”的典型症状。2.2 从分段锁到 CAS synchronized 的二次革命JDK 8 的 ConcurrentHashMap 直接删掉了 Segment 这个类表层结构变成了和 HashMap 一致的 Node 数组 链表 红黑树。锁粒度从 Segment 级别降到了桶位级别写操作先通过 CAS 尝试插入空桶如果桶位不为空就 synchronized 锁住这个桶的头节点再执行插入或更新。这个转变背后的逻辑是JDK 6 之后 synchronized 经历了大量优化引入了偏向锁、轻量级锁、重量级锁的升级路径在低竞争场景下开销已经逼近 CAS在高竞争场景下又能自动膨胀为重量级锁保证公平性。与其维护一个复杂的 Segment 继承体系不如直接用 JVM 原生锁让 JVM 帮我们处理锁升级代码结构反而更清晰。还有一点容易被忽略JDK 8 的 ConcurrentHashMap 在树化条件上和 HashMap 保持了一致。链表长度超过 8 且数组长度大于等于 64 时转红黑树这样即使某个桶位发生严重哈希冲突查询复杂度也能从 O(n) 降到 O(log n)避免单个热点桶拖垮全局性能。2.3 两版架构的直观对比维度JDK 7 分段锁JDK 8 CAS synchronized锁粒度Segment默认 16 段单个桶位头节点并发写上限受 Segment 数量限制理论上可接近桶数量空桶插入锁 Segment无锁 CAS扩容方式每个 Segment 内部分别扩容整表扩容支持多线程协助哈希碰撞优化仅链表链表转红黑树内存占用相对较高Segment 额外开销更低从表格里能清楚看到JDK 8 版本几乎在每个维度上都做了优化但真正的复杂度也转移到了扩容上。想彻底理解 JDK 8 的 ConcurrentHashMap读一读扩容相关源码是绕不开的坎。3. 核心操作源码级拆解PUT 读写流程与并发控制3.1 PUT 流程中那些容易忽略的分支put方法最终会调用putVal这是整个实现里最关键的入口。我把流程拆成几个阶段你按照这个顺序去读源码会轻松很多。第一步是计算哈希并定位桶位。spread()方法把 key 的 hashCode 高 16 位和低 16 位做异或再与HASH_BITS做与运算强制将最高位置为 0。这样做的目的是让高位信息也参与寻址减少哈希冲突同时避免出现 hashCode 为负数导致后续判断混乱。第二步是检查数组是否初始化。如果 table 为 null就调用initTable()初始化。这个方法里有个细节多个线程同时发现 table 为 null 时只有一个线程能通过sizeCtl的 CAS 操作从 0 改成 -1 获得初始化权其他线程会通过Thread.yield()让出 CPU自旋等待。sizeCtl在这里承担了双重角色负数表示正在初始化或扩容正数表示下一次扩容的阈值。第三步是插入数据这里分三种情况桶位为空用casTabAt方法以 CAS 方式将新节点插入。这一步无锁完成是 JDK 8 高并发写的核心。桶位是 ForwardingNode说明数组正在扩容当前线程会调用helpTransfer()加入扩容队伍而不是自顾自地插入。这是一个很多人没注意到的隐藏行为——你明明调的是 put却可能先跑去帮别的线程扩容。桶位是普通节点synchronized 锁住头节点然后遍历链表或红黑树。如果是链表还要判断节点数是否达到树化阈值。整个 put 过程的关键就一句话能在不加锁的情况下完成就不加锁必须加锁时只锁一个桶绝不锁全表。你可以把数组看成一个大楼每个桶位是一个房间put 操作就是进自己的房间不需要把整栋楼都封锁。3.2 GET 为什么全程无锁却安全get方法没有加任何锁这也是 ConcurrentHashMap 最大的卖点之一。它之所以安全依赖三个层面的保证第一层是 volatile 语义。Node 数组的引用是 volatile 的数组内每个 Node 的 val 和 next 也是 volatile 的所以读线程能拿到最新值不会出现“读了半天读到旧数据”的问题。第二层是哈希定位的稳定性。只要 key 的 hashCode 不改变同一个 key 计算出的桶位就是确定的。即使扩容正在进行get也会先检查桶位是否被标记为 ForwardingNode如果是就跳到新的数组里去查。这个“跳转”由ForwardingNode.find()方法实现它内部会递归或循环地去新数组中寻找目标节点。第三层是链表和红黑树的遍历安全性。读线程不会修改结构写线程修改时持有的是同一把桶锁所以读线程要么读到写之前的旧链表要么读到写之后的新链表不会读到中间状态。我实际测试过在模拟项目 X 里用 8 个线程并发读、4 个线程并发写get 的 P99 延迟比加锁版本低了一个数量级。但你要注意get的“安全”是相对“并发修改不会崩溃”而言的它并不能保证强一致性这一点我在后面会专门展开。3.3 SIZE 计算背后的 CounterCell 机制size()方法看似简单实际上涉及一个叫CounterCell的内部累加器。如果每次 size 都遍历整个数组求和那高并发下这个操作的成本是不可接受的。所以 ConcurrentHashMap 在 put、remove 等操作时会更新一个 baseCount 变量同时在竞争激烈时还会创建一批 CounterCell 数组让各个线程分散到不同的 Cell 上去累加。sumCount()的逻辑就是读取 baseCount再遍历 CounterCell 数组把每个 Cell 的值加总。这个和真实值相比可能略有偏差因为更新和求和之间没有全局锁。JDK 8 文档里明确说了size 返回的是一个“估计值”不是强一致的结果。这里给你一个实战建议不要频繁调用size()来做容量判断。比如“如果 size 超过阈值则触发清理”这种逻辑在高并发下既不精确性能也差。更好的做法是维护独立的 AtomicLong 计数或者在业务层面用更宽松的指标来决策。4. 扩容机制最复杂的并发任务调度4.1 为什么扩容是并发协作而非互斥等待HashMap 扩容时是单线程重新哈希这个过程中其他线程访问会直接阻塞或读到错误数据。ConcurrentHashMap 的设计目标是扩容不能阻塞正常的读写最好让所有线程都来帮忙。触发扩容的条件是插入节点后如果当前节点数超过sizeCtl即扩容阈值就调用addCount()判断是否需要扩容然后进入transfer()。transfer()是 ConcurrentHashMap 全部代码里最难读的部分没有之一但核心思路其实不复杂把旧的 Node 数组分成多个任务区间每个来帮忙的线程领取一段区间把该区间内的桶位一个个迁移到新数组。这里的关键数据结构有两个stride和transferIndex。stride是每个线程每次领取的最小步长最小值为 16它保证每个线程至少处理 16 个桶位避免任务切分过细导致上下文切换开销大于收益。transferIndex是一个 volatile 变量表示当前还没分配的任务区间起点多个线程通过 CAS 竞争领取区间实现了“任务分片 并发协作”。4.2 transfer 的 bin 迁移流程每个桶位的迁移流程是这样的先 synchronized 锁住头节点然后遍历链表。JDK 8 的迁移做了一个非常聪明的优化不需要重新计算每个节点的 hash 再定位到新数组而是根据(hash oldCap)是否为 0把链表拆成两条低位链和高位链。举个例子假设旧数组容量是 16扩容后是 32。某个节点的 hash 二进制低位中只有第 5 位即二进制 10000 对应的位可能发生变化。hash oldCap为 0说明第 5 位是 0这个节点在新数组中下标不变hash oldCap不为 0说明第 5 位是 1新下标就是旧下标加上 16。这样拆分完以后低位链直接放到新数组的同一下标位置高位链放到“旧下标 oldCap”的位置一次遍历就能完成迁移。迁移完成后旧桶位会被替换为一个 ForwardingNodehash 值固定为 -1。后面任何线程访问到这个桶位都知道“此路不通去新数组找”。正是这个 ForwardingNode 标记让扩容期间的 get、put 操作都能正确跳转。4.3 helpTransfer 的妙处helpTransfer方法在 put 操作中遇到 ForwardingNode 时被调用。它不是单纯地等待扩容结束而是也参与到扩容工作中。参与的方式是通过 CAS 修改sizeCtl让扩容线程数加一然后调取transfer()中的共享参数领取一部分桶位进行迁移。这种设计的好处是并发写入越高扩容被触发后来帮忙的线程就越多扩容完成越快整体吞吐量反而可能比单线程扩容更高。实测下来在某些机器上4 个线程协作扩容比单线程扩容快 2~3 倍这个过程叫“扩容加速”本质是把一次昂贵的全局操作分摊到了后续的写线程上。但要注意一个隐藏问题如果某个 key 所在桶位还没被迁移此时该桶位已经被标记为 ForwardingNode 吗不会。扩容是按区间推进的同一个区间内的桶位会被连续处理完。所以只要桶位处在“已迁移完毕”的区间才可能碰上 ForwardingNode如果还在“未迁移”的区间put 操作照常插入旧数组等迁移线程扫到它时再做处理。这个机制保证了 put 不需要等待整个扩容完成最多只需要等待锁住单个桶位的短暂时间。5. 线程安全不等于一切安全实战中的坑与排查技巧5.1 size、get、迭代器的弱一致性我前面反复提到ConcurrentHashMap 的线程安全是“并发安全”不是“强一致安全”。具体表现在get方法可能在扩容期间读取到旧数组的数据虽然数据最终一致但不是实时的。size()和mappingCount()返回的是估计值可能和真实值有毫秒级的偏差。iterator是弱一致的迭代过程中如果其他线程修改了 Map迭代器不会抛 ConcurrentModificationException但也不保证遍历到所有最新修改。这一点经常让从面试题里走出来的同学困惑为什么它不抛异常因为 fail-fast 机制的实现前提是modCountConcurrentHashMap 根本没有维护这个字段它选择了“容忍迭代期间的并发修改”来换取性能。如果你在业务里依赖“遍历过程中所有数据必须一致”那这个类并不适合应该用Collections.synchronizedMap加全局锁或者使用数据库、分布式缓存等外部存储。5.2 复合操作竞态putIfAbsent 不是万能的ConcurrentHashMap 提供了putIfAbsent、computeIfAbsent、merge这些原子方法看起来很方便但如果你把它们组合起来用依然会出现竞态。举个例子某开发者做用户余额更新先putIfAbsent(userId, initBalance)然后再get出来加钱。这段代码看似安全实际两个操作之间可能有其他线程同时执行了同样的逻辑导致余额更新被覆盖。正确做法是使用compute方法它能在锁内完成“读取 修改 写回”整个流程。不过compute也有它自己的坑比如在 Java 8 早期版本中computeIfAbsent在扩容期间可能触发一个死循环 bug后来修复了。如果你还在用老版本 JDK 8建议升级到高版本或者在热点路径上避免使用这个 API。5.3 性能调优参数与热点 KeyConcurrentHashMap 的初始容量、负载因子和并发度这三个概念容易被混淆。它没有真正的concurrencyLevel参数了JDK 8 里这个参数只影响初始容量计算默认初始容量是 16负载因子固定为 0.75写死不能修改。sizeCtl的初始值由tableSizeFor(initialCapacity (initialCapacity 1) 1)计算得出保证容量是 2 的幂。如果你预估数据量有 10 万条直接new ConcurrentHashMap(100000)可以吗不行这个构造器会做向上取整到 2 的幂实际容量可能变成 131072 或更大浪费内存。正确做法是按预估大小 / 0.75 1来设置初始容量。热点 Key 问题在 ConcurrentHashMap 上依然存在。虽然锁粒度已经细化到桶位但如果业务里某个 key 被反复写比如某个爆款商品的库存那这个桶位就会成为锁竞争的焦点。我在某图像处理 Demo 里遇到过这种情况一个统计节点 ID 的 Map某个热点节点被 10 个线程高频更新吞吐量直接掉了一半。解决办法有几种一是用LongAdder作为值把计数压力分散到多个 Cell 上二是做 key 拆分比如hotKey_0到hotKey_15分布到不同桶位三是把热点数据移出 ConcurrentHashMap放到专门的无锁结构里。5.4 常见问题速查表问题原因解决方案CPU 飙高线程栈卡在 putVal链表过长导致 O(n) 扫描确认类是否重写了 hashCode必要时让 key 的哈希分布均匀size() 结果不准确强一致性需求被弱一致性实现用 AtomicLong 自行维护计数迭代时数据少了扩容导致旧桶迁移迭代器读到旧数据改用快照遍历先转成数组再遍历内存突然变大树化后节点结构更大检查 key 的哈希分布和初始容量设置分布式场景下数据错乱多个 JVM 实例各自维护本地 Map使用分布式缓存或数据库不要依赖本地 Map 做跨实例协调另外提醒一个非常容易踩的坑ConcurrentHashMap 不允许 null 键和 null 值。这个限制是有意为之的因为在并发场景下get 返回 null 时你无法区分“key 不存在”还是“value 是 null”而这会破坏原子操作的正确性判断。如果你确实需要 null 值可以先用一个包装对象或者用 Optional 来替代。6. 从源码到实践我的一点体会读 ConcurrentHashMap 源码这件事我前后花了差不多一周时间才从“看懂每一行”到“理解为什么这样设计”。回头看最大的收获不是记住了那些方法名而是建立了一种并发编程的直觉能无锁就无锁必须加锁就锁最小范围遇到全局操作就想办法分片协作而不是一锁了之。如果你也想深入掌握这个类的内部实现逻辑我的建议是别一头扎进源码细节先抓住四条主线CAS 解决的是什么问题、volatile 解决的是什么问题、synchronized 锁的是哪个对象、扩容时线程之间怎么协作。把这四条线串起来再回头读 put、get、transfer 这三个方法你会发现整个设计逻辑非常流畅。最后再分享一个我个人的实操习惯每当需要选择并发容器时我都会先追问自己三个问题——这个 Map 会被多少个线程并发写写入的 key 分布是否均匀我能接受多大程度的弱一致性答案不同选型就完全不同。ConcurrentHashMap 并不是万能答案但对大部分中等并发场景来说它确实是把 Java 并发工具的每一种底层能力都发挥到了极致的东西。 
长河君 · 2026/10/14 6:21:41 · 阅读 1.2k ConcurrentHashMap源码解析：从锁粒度到扩容协作的高并发设计
1. 从线上故障说起为什么要重新认识 ConcurrentHashMap很多同学对 ConcurrentHashMap 的印象停留在“并发版的 HashMap线程安全性能比 Hashtable 好”但真到线上出问题的时候你会发现这个认知远远不够。我最早被这个类“教育”是在某跨平台系统的模拟项目压测中服务启动正常QPS 一上来CPU 直接打满线程栈一抓全部卡在ConcurrentHashMap.putVal和treeifyBin这两个方法里。那时候我才意识到光知道“它线程安全”完全没用你得知道它内部到底怎么加锁、怎么扩容、怎么在极端竞争下退化成串行才能在写代码时避开那些性能陷阱。从 JDK 8 开始ConcurrentHashMap的内部实现逻辑其实已经重写了一遍和 JDK 7 的分段锁完全是两套思路。JDK 8 版本抛弃了 Segment转而使用 CAS synchronized 的组合方案锁粒度从“段”细化为“单个桶位”并发度理论上可以撑到和哈希表桶数量一样高。这听起来很美好但代价是代码复杂度大幅上升尤其是扩容那部分设计了一个“多线程协助迁移”的机制很多问题都藏在细节里。这篇内容适合三类人第一类是刚接触并发编程、想搞明白 ConcurrentHashMap 为什么比 Hashtable 强的新手第二类是已经用过 ConcurrentHashMap 但没读过源码、想系统梳理内部结构的进阶开发者第三类是遇到线上并发问题需要排查和调优的实战派。我会把它的结构、读写流程、扩容机制、常见陷阱一层层拆开讲尽量让每个结论都能落到实际代码上。2. JDK 7 与 JDK 8 的架构差异锁粒度才是核心2.1 分段锁时代以空间换并发JDK 7 版本的 ConcurrentHashMap 内部维护了一个 Segment 数组每个 Segment 本质是一把继承自 ReentrantLock 的锁同时每个 Segment 管理着一个小型的 HashEntry 数组。默认 Segment 数量是 16也就是说你最多只有 16 个线程能同时写这个 Map且每个线程只能写属于自己的那一段。这种设计的优势是读操作完全不需要加锁因为 HashEntry 里的 value 和 next 字段都是 volatile 修饰的靠 volatile 的可见性保证读到的数据不是过期的。写操作只需要锁住目标 Segment其他 Segment 的读写不受影响。但问题也很明显Segment 数量在构造时固定不支持扩容。如果数据量很大哈希冲突集中在某几个 Segment 上那这几个 Segment 的锁竞争会非常激烈其他 Segment 却空着并发能力被白白浪费。而且如果两个线程恰好访问了同一个 Segment 下的不同桶位它们依然会被同一把锁挡住这就是“锁粒度太粗”的典型症状。2.2 从分段锁到 CAS synchronized 的二次革命JDK 8 的 ConcurrentHashMap 直接删掉了 Segment 这个类表层结构变成了和 HashMap 一致的 Node 数组 链表 红黑树。锁粒度从 Segment 级别降到了桶位级别写操作先通过 CAS 尝试插入空桶如果桶位不为空就 synchronized 锁住这个桶的头节点再执行插入或更新。这个转变背后的逻辑是JDK 6 之后 synchronized 经历了大量优化引入了偏向锁、轻量级锁、重量级锁的升级路径在低竞争场景下开销已经逼近 CAS在高竞争场景下又能自动膨胀为重量级锁保证公平性。与其维护一个复杂的 Segment 继承体系不如直接用 JVM 原生锁让 JVM 帮我们处理锁升级代码结构反而更清晰。还有一点容易被忽略JDK 8 的 ConcurrentHashMap 在树化条件上和 HashMap 保持了一致。链表长度超过 8 且数组长度大于等于 64 时转红黑树这样即使某个桶位发生严重哈希冲突查询复杂度也能从 O(n) 降到 O(log n)避免单个热点桶拖垮全局性能。2.3 两版架构的直观对比维度JDK 7 分段锁JDK 8 CAS synchronized锁粒度Segment默认 16 段单个桶位头节点并发写上限受 Segment 数量限制理论上可接近桶数量空桶插入锁 Segment无锁 CAS扩容方式每个 Segment 内部分别扩容整表扩容支持多线程协助哈希碰撞优化仅链表链表转红黑树内存占用相对较高Segment 额外开销更低从表格里能清楚看到JDK 8 版本几乎在每个维度上都做了优化但真正的复杂度也转移到了扩容上。想彻底理解 JDK 8 的 ConcurrentHashMap读一读扩容相关源码是绕不开的坎。3. 核心操作源码级拆解PUT 读写流程与并发控制3.1 PUT 流程中那些容易忽略的分支put方法最终会调用putVal这是整个实现里最关键的入口。我把流程拆成几个阶段你按照这个顺序去读源码会轻松很多。第一步是计算哈希并定位桶位。spread()方法把 key 的 hashCode 高 16 位和低 16 位做异或再与HASH_BITS做与运算强制将最高位置为 0。这样做的目的是让高位信息也参与寻址减少哈希冲突同时避免出现 hashCode 为负数导致后续判断混乱。第二步是检查数组是否初始化。如果 table 为 null就调用initTable()初始化。这个方法里有个细节多个线程同时发现 table 为 null 时只有一个线程能通过sizeCtl的 CAS 操作从 0 改成 -1 获得初始化权其他线程会通过Thread.yield()让出 CPU自旋等待。sizeCtl在这里承担了双重角色负数表示正在初始化或扩容正数表示下一次扩容的阈值。第三步是插入数据这里分三种情况桶位为空用casTabAt方法以 CAS 方式将新节点插入。这一步无锁完成是 JDK 8 高并发写的核心。桶位是 ForwardingNode说明数组正在扩容当前线程会调用helpTransfer()加入扩容队伍而不是自顾自地插入。这是一个很多人没注意到的隐藏行为——你明明调的是 put却可能先跑去帮别的线程扩容。桶位是普通节点synchronized 锁住头节点然后遍历链表或红黑树。如果是链表还要判断节点数是否达到树化阈值。整个 put 过程的关键就一句话能在不加锁的情况下完成就不加锁必须加锁时只锁一个桶绝不锁全表。你可以把数组看成一个大楼每个桶位是一个房间put 操作就是进自己的房间不需要把整栋楼都封锁。3.2 GET 为什么全程无锁却安全get方法没有加任何锁这也是 ConcurrentHashMap 最大的卖点之一。它之所以安全依赖三个层面的保证第一层是 volatile 语义。Node 数组的引用是 volatile 的数组内每个 Node 的 val 和 next 也是 volatile 的所以读线程能拿到最新值不会出现“读了半天读到旧数据”的问题。第二层是哈希定位的稳定性。只要 key 的 hashCode 不改变同一个 key 计算出的桶位就是确定的。即使扩容正在进行get也会先检查桶位是否被标记为 ForwardingNode如果是就跳到新的数组里去查。这个“跳转”由ForwardingNode.find()方法实现它内部会递归或循环地去新数组中寻找目标节点。第三层是链表和红黑树的遍历安全性。读线程不会修改结构写线程修改时持有的是同一把桶锁所以读线程要么读到写之前的旧链表要么读到写之后的新链表不会读到中间状态。我实际测试过在模拟项目 X 里用 8 个线程并发读、4 个线程并发写get 的 P99 延迟比加锁版本低了一个数量级。但你要注意get的“安全”是相对“并发修改不会崩溃”而言的它并不能保证强一致性这一点我在后面会专门展开。3.3 SIZE 计算背后的 CounterCell 机制size()方法看似简单实际上涉及一个叫CounterCell的内部累加器。如果每次 size 都遍历整个数组求和那高并发下这个操作的成本是不可接受的。所以 ConcurrentHashMap 在 put、remove 等操作时会更新一个 baseCount 变量同时在竞争激烈时还会创建一批 CounterCell 数组让各个线程分散到不同的 Cell 上去累加。sumCount()的逻辑就是读取 baseCount再遍历 CounterCell 数组把每个 Cell 的值加总。这个和真实值相比可能略有偏差因为更新和求和之间没有全局锁。JDK 8 文档里明确说了size 返回的是一个“估计值”不是强一致的结果。这里给你一个实战建议不要频繁调用size()来做容量判断。比如“如果 size 超过阈值则触发清理”这种逻辑在高并发下既不精确性能也差。更好的做法是维护独立的 AtomicLong 计数或者在业务层面用更宽松的指标来决策。4. 扩容机制最复杂的并发任务调度4.1 为什么扩容是并发协作而非互斥等待HashMap 扩容时是单线程重新哈希这个过程中其他线程访问会直接阻塞或读到错误数据。ConcurrentHashMap 的设计目标是扩容不能阻塞正常的读写最好让所有线程都来帮忙。触发扩容的条件是插入节点后如果当前节点数超过sizeCtl即扩容阈值就调用addCount()判断是否需要扩容然后进入transfer()。transfer()是 ConcurrentHashMap 全部代码里最难读的部分没有之一但核心思路其实不复杂把旧的 Node 数组分成多个任务区间每个来帮忙的线程领取一段区间把该区间内的桶位一个个迁移到新数组。这里的关键数据结构有两个stride和transferIndex。stride是每个线程每次领取的最小步长最小值为 16它保证每个线程至少处理 16 个桶位避免任务切分过细导致上下文切换开销大于收益。transferIndex是一个 volatile 变量表示当前还没分配的任务区间起点多个线程通过 CAS 竞争领取区间实现了“任务分片 并发协作”。4.2 transfer 的 bin 迁移流程每个桶位的迁移流程是这样的先 synchronized 锁住头节点然后遍历链表。JDK 8 的迁移做了一个非常聪明的优化不需要重新计算每个节点的 hash 再定位到新数组而是根据(hash oldCap)是否为 0把链表拆成两条低位链和高位链。举个例子假设旧数组容量是 16扩容后是 32。某个节点的 hash 二进制低位中只有第 5 位即二进制 10000 对应的位可能发生变化。hash oldCap为 0说明第 5 位是 0这个节点在新数组中下标不变hash oldCap不为 0说明第 5 位是 1新下标就是旧下标加上 16。这样拆分完以后低位链直接放到新数组的同一下标位置高位链放到“旧下标 oldCap”的位置一次遍历就能完成迁移。迁移完成后旧桶位会被替换为一个 ForwardingNodehash 值固定为 -1。后面任何线程访问到这个桶位都知道“此路不通去新数组找”。正是这个 ForwardingNode 标记让扩容期间的 get、put 操作都能正确跳转。4.3 helpTransfer 的妙处helpTransfer方法在 put 操作中遇到 ForwardingNode 时被调用。它不是单纯地等待扩容结束而是也参与到扩容工作中。参与的方式是通过 CAS 修改sizeCtl让扩容线程数加一然后调取transfer()中的共享参数领取一部分桶位进行迁移。这种设计的好处是并发写入越高扩容被触发后来帮忙的线程就越多扩容完成越快整体吞吐量反而可能比单线程扩容更高。实测下来在某些机器上4 个线程协作扩容比单线程扩容快 2~3 倍这个过程叫“扩容加速”本质是把一次昂贵的全局操作分摊到了后续的写线程上。但要注意一个隐藏问题如果某个 key 所在桶位还没被迁移此时该桶位已经被标记为 ForwardingNode 吗不会。扩容是按区间推进的同一个区间内的桶位会被连续处理完。所以只要桶位处在“已迁移完毕”的区间才可能碰上 ForwardingNode如果还在“未迁移”的区间put 操作照常插入旧数组等迁移线程扫到它时再做处理。这个机制保证了 put 不需要等待整个扩容完成最多只需要等待锁住单个桶位的短暂时间。5. 线程安全不等于一切安全实战中的坑与排查技巧5.1 size、get、迭代器的弱一致性我前面反复提到ConcurrentHashMap 的线程安全是“并发安全”不是“强一致安全”。具体表现在get方法可能在扩容期间读取到旧数组的数据虽然数据最终一致但不是实时的。size()和mappingCount()返回的是估计值可能和真实值有毫秒级的偏差。iterator是弱一致的迭代过程中如果其他线程修改了 Map迭代器不会抛 ConcurrentModificationException但也不保证遍历到所有最新修改。这一点经常让从面试题里走出来的同学困惑为什么它不抛异常因为 fail-fast 机制的实现前提是modCountConcurrentHashMap 根本没有维护这个字段它选择了“容忍迭代期间的并发修改”来换取性能。如果你在业务里依赖“遍历过程中所有数据必须一致”那这个类并不适合应该用Collections.synchronizedMap加全局锁或者使用数据库、分布式缓存等外部存储。5.2 复合操作竞态putIfAbsent 不是万能的ConcurrentHashMap 提供了putIfAbsent、computeIfAbsent、merge这些原子方法看起来很方便但如果你把它们组合起来用依然会出现竞态。举个例子某开发者做用户余额更新先putIfAbsent(userId, initBalance)然后再get出来加钱。这段代码看似安全实际两个操作之间可能有其他线程同时执行了同样的逻辑导致余额更新被覆盖。正确做法是使用compute方法它能在锁内完成“读取 修改 写回”整个流程。不过compute也有它自己的坑比如在 Java 8 早期版本中computeIfAbsent在扩容期间可能触发一个死循环 bug后来修复了。如果你还在用老版本 JDK 8建议升级到高版本或者在热点路径上避免使用这个 API。5.3 性能调优参数与热点 KeyConcurrentHashMap 的初始容量、负载因子和并发度这三个概念容易被混淆。它没有真正的concurrencyLevel参数了JDK 8 里这个参数只影响初始容量计算默认初始容量是 16负载因子固定为 0.75写死不能修改。sizeCtl的初始值由tableSizeFor(initialCapacity (initialCapacity 1) 1)计算得出保证容量是 2 的幂。如果你预估数据量有 10 万条直接new ConcurrentHashMap(100000)可以吗不行这个构造器会做向上取整到 2 的幂实际容量可能变成 131072 或更大浪费内存。正确做法是按预估大小 / 0.75 1来设置初始容量。热点 Key 问题在 ConcurrentHashMap 上依然存在。虽然锁粒度已经细化到桶位但如果业务里某个 key 被反复写比如某个爆款商品的库存那这个桶位就会成为锁竞争的焦点。我在某图像处理 Demo 里遇到过这种情况一个统计节点 ID 的 Map某个热点节点被 10 个线程高频更新吞吐量直接掉了一半。解决办法有几种一是用LongAdder作为值把计数压力分散到多个 Cell 上二是做 key 拆分比如hotKey_0到hotKey_15分布到不同桶位三是把热点数据移出 ConcurrentHashMap放到专门的无锁结构里。5.4 常见问题速查表问题原因解决方案CPU 飙高线程栈卡在 putVal链表过长导致 O(n) 扫描确认类是否重写了 hashCode必要时让 key 的哈希分布均匀size() 结果不准确强一致性需求被弱一致性实现用 AtomicLong 自行维护计数迭代时数据少了扩容导致旧桶迁移迭代器读到旧数据改用快照遍历先转成数组再遍历内存突然变大树化后节点结构更大检查 key 的哈希分布和初始容量设置分布式场景下数据错乱多个 JVM 实例各自维护本地 Map使用分布式缓存或数据库不要依赖本地 Map 做跨实例协调另外提醒一个非常容易踩的坑ConcurrentHashMap 不允许 null 键和 null 值。这个限制是有意为之的因为在并发场景下get 返回 null 时你无法区分“key 不存在”还是“value 是 null”而这会破坏原子操作的正确性判断。如果你确实需要 null 值可以先用一个包装对象或者用 Optional 来替代。6. 从源码到实践我的一点体会读 ConcurrentHashMap 源码这件事我前后花了差不多一周时间才从“看懂每一行”到“理解为什么这样设计”。回头看最大的收获不是记住了那些方法名而是建立了一种并发编程的直觉能无锁就无锁必须加锁就锁最小范围遇到全局操作就想办法分片协作而不是一锁了之。如果你也想深入掌握这个类的内部实现逻辑我的建议是别一头扎进源码细节先抓住四条主线CAS 解决的是什么问题、volatile 解决的是什么问题、synchronized 锁的是哪个对象、扩容时线程之间怎么协作。把这四条线串起来再回头读 put、get、transfer 这三个方法你会发现整个设计逻辑非常流畅。最后再分享一个我个人的实操习惯每当需要选择并发容器时我都会先追问自己三个问题——这个 Map 会被多少个线程并发写写入的 key 分布是否均匀我能接受多大程度的弱一致性答案不同选型就完全不同。ConcurrentHashMap 并不是万能答案但对大部分中等并发场景来说它确实是把 Java 并发工具的每一种底层能力都发挥到了极致的东西。