ConcurrentHashMap源码精读：从CAS桶锁到扩容协作

如果你已经能背出 HashMap 的“数组+链表+红黑树”结构，那 ConcurrentHashMap 绝对值得你再较真儿一次。它是 JDK 并发包里信息密度最高的源码之一，一趟读下来，你会把 volatile、CAS、synchronized、哈希扰动、树化阈值、扩容协作这些知识点全部串起来。很多人读它只记住了“CAS + 桶锁”六个字，可真要问“扩容时别的线程怎么帮忙搬数据”“size 为什么可能不准”“get 为什么不用加锁”，能讲清楚的人并不多。

我自己立过一个 flag：把 ConcurrentHashMap 的核心方法逐行读完，并且给每行能写注释的都写注释。读完最大的感慨是：作者不是在写数据结构，而是在设计一套高并发的状态机。这篇文章就把我逐行批注时觉得最关键的几条线重新走一遍，包括怎么读、为什么这么设计、哪些地方容易想当然。

1. 读之前先想清楚：ConcurrentHashMap 在并发之下到底解决了什么

很多源码分析一上来就贴代码，我觉得这是最大的误区。看源码之前必须先搞清楚设计目标，否则看到一堆 if-else 只会觉得“好复杂”，而不会觉得“这步太妙了”。

1.1 从 JDK 7 的分段锁到 JDK 8 的 CAS 加桶锁

JDK 7 的 ConcurrentHashMap 用的是分段锁：内部维护一个 Segment 数组，每个 Segment 继承 ReentrantLock，里面又维护一个小 HashEntry 数组。数据被拆到多个 Segment 里，写不同的 Segment 互不影响。听起来不错，但问题在于：分段数量是初始化时固定的，默认只有 16 个；一旦写压力集中在某个 Segment，这个 Segment 就会变成瓶颈，其他 Segment 再空闲也帮不上忙。而且每写一个桶都要经过一次可重入锁的获取与释放，哪怕桶里只有一个元素，也要走完整的锁流程。

JDK 8 把 Segment 直接砍掉了，回到一张大哈希表，用 volatile 修饰数组引用和节点 value，空桶用 CAS 直接写入，非空桶用 synchronized 锁住桶头节点。锁粒度从“段”降到了“桶”。两个线程写不同的桶时，各自锁不同的头节点，互不干扰；写同一个桶时，锁的也只是这一条链或这棵树，全表其他位置照常读写。这个改动让并发粒度真正细到了单桶级别。

1.2 读源码之前需要准备好的三块拼图

读这份源码需要的基础知识其实不算多，但缺一不可：

• volatile 的可见性语义：知道读 volatile 字段能看到最新值，写 volatile 字段会立即刷新到共享内存；
• CAS 的基本操作：知道 compareAndSwapXxx 是“比较并交换”的原子操作，失败后会循环重试；
• HashMap 的扩容思路：尤其是容量为什么是 2 的幂、为什么下标要用(n - 1) & hash。

红黑树那一块，建议先不用背旋转算法，只需要知道它是一棵自平衡二叉搜索树，能保证查找 O(log n) 即可。真到了 TreeBin 里的 putTreeVal 和 find 时，知道左小右大、需要变色旋转就够你读懂了。

1.3 我推荐的阅读路线：字段到 put，再回头补扩容

如果从第一个方法按顺序读下去，大概率读不到一半就晕了。我比较顺的路线是：先把静态常量和字段过一遍，理解“状态变量”都长什么样；然后精读 putVal，因为它是所有写路径的总入口；读完 putVal 自然就看到了扩容入口 addCount 和 transfer，再专门啃 transfer；最后回来看 get、size、remove、compute 这些方法。先把骨架立起来，再往上面挂血肉，就不会迷路。

2. 先别急着进 put，看看静态常量和字段透露了哪些设计信号

我读源码的习惯是先看“公共设施”。ConcurrentHashMap 的字段数量不多，但每一个都承担了至少两三种职责。不理解它们，后续所有眼花缭乱的操作都会失去锚点。

2.1 spread() 这个扰动函数为什么还要和 HASH_BITS 取与

先看这段高频使用的函数：

static final int spread(int h) { return (h ^ (h >>> 16)) & HASH_BITS; }

第一个操作是h ^ (h >>> 16)，把 key 的 hashCode 高 16 位和低 16 位搅在一起。原因很直白：哈希表定位下标时用的是(n - 1) & hash，容量 n 是 2 的幂，所以 n-1 的低位全是 1，高位全是 0。如果 key 的 hashCode 高位差异很大、低位恰好相同，不做扰动就会出现大量碰撞。让高 16 位参与异或之后，任何一位的变化都能传递到低位决策上。

第二个操作是& HASH_BITS，而HASH_BITS = 0x7fffffff，作用是强制最高位变成 0。为什么要多此一举？因为普通节点的 hash 值必须是非负数。这样在遍历时看到“hash 小于 0”的节点，就可以直接断定它不是普通链表节点，而是 ForwardingNode、TreeBin 或 ReservationNode 这三种特殊节点之一。一个字段同时肩负数据定位和类型识别两个职责，这是读源码时容易忽略的点。

2.2 sizeCtl 一个变量当三个用

ConcurrentHashMap 里最容易被误解的字段就是 sizeCtl。它表面上是 int，实际上是个状态机：

初始化完成后，正数时它等于n - (n >>> 2)，也就是 0.75n 的扩容阈值。扩容时它变成负数，通过高位的 resizeStamp 区分是第几轮扩容，用低位的线程数判断还有多少线程没退出。一个变量承担了标识、计数、阈值三种作用，也正因为如此，所有修改都必须通过 CAS 进行，否则多线程一改就会乱套。

2.3 节点 hash 的四个特殊值和 ForwardingNode 的使命

普通节点的 hash 是 spread 后的非负数，但还存在三个角色：

static final int MOVED = -1; // ForwardingNode static final int TREEBIN = -2; // TreeBin 的根 static final int RESERVED = -3; // ReservationNode

MOVED 节点就是扩容时的“路标”，它内部保存了 nextTable 引用。任何线程读到 MOVED 节点，都知道旧数组这个桶已经被迁移完了，而且可以直接通过它的 find 方法到新数组里去查数据。TREEBIN 是红黑树桶的标记，注意它和 TreeNode 不同，TreeBin 是树的头管理对象，锁也锁在它身上。RESERVED 是 computeIfAbsent 这类计算型方法用的占位节点，防止同一个 key 被多个线程同时初始化。

2.4 构造函数为什么不急着建表

new ConcurrentHashMap()的构造函数几乎是空的，只是初始化了相关字段；new ConcurrentHashMap<>(initialCapacity)也只是顺手把容量换算进 sizeCtl：

int cap = tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1); this.sizeCtl = cap;

tableSizeFor 会把传入值调整成不小于它的 2 的幂。这里多加了(initialCapacity >>> 1)是为了给 0.75 的负载因子提前留出余量，免得刚初始化完就立刻扩容。真正建表要等到第一次 put 时在 initTable 里做。这个设计是为了让“不用的容器不占空间”，同时也把并发初始化的问题统一到了 initTable 一个入口里面。

3. putVal 逐行走读：从 CAS 投递到 synchronized 锁链

putVal 是 ConcurrentHashMap 最核心的写入口。读完它，你会明白空桶、冲突桶、扩容桶、树化桶分别走了哪条分支。下面这段是去掉边界分支后的主流程骨架，我用注释标出每一行的意图：

final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); int binCount = 0; for (Node<K,V>[] tab = table;;) { Node<K,V> f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // 表还没建，先抢初始化 else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value))) break; // 空桶，直接 CAS 放入 } else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); // 遇到扩容路标，先帮一把 else { V oldVal = null; synchronized (f) { // 锁住这个桶的头节点 if (tabAt(tab, i) == f) { // 二次确认头没变 if (fh >= 0) { // 普通链表桶 // 遍历链表找 key，找到就替换，找不到就尾插 } else if (f instanceof TreeBin) { // 红黑树桶，交给 TreeBin.putTreeVal } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); // 可能转红黑树 addCount(1L, binCount); // 计数并可能触发扩容 } } } return null; }

3.1 空桶的快速路径：为什么敢用 CAS 不设锁

当目标桶位置是 null 时，代码没有加锁，而是直接casTabAt。CAS 的语义是“只有当前值是 null 时，我才把新节点写进去”，所以不会出现两个线程同时插入到同一个空桶的问题。如果 CAS 失败，说明另外一个线程抢先写入了，当前线程就跳到下一轮循环重新判断，该走链表分支就走链表分支。这个路径连 synchronized 都没碰，性能自然好。

这里有个容易忽略的点：tabAt和casTabAt并不是普通的数组读写，它们走的是 Unsafe 的 getObjectVolatile / compareAndSwapObject。Java 数组元素本身不具备 volatile 语义，如果直接tab[i] = node，另一个线程可能看不到这次写入。所以源码里所有对桶位置的读写都必须通过这两个工具方法，这就是“读数组元素也讲可见性”的细节。

3.2 遇到 ForwardingNode 时的态度：先帮忙扩容，再谈写入

如果定位到的桶头节点 hash 是 MOVED，说明这个桶已经迁移到新数组 nextTable 中了。此时当前线程不能直接往旧数组里写，因为旧数组的该位置已经变成了“路标”，写了也是白写，最终新数组里也看不到。所以代码调用 helpTransfer，把自己也变成扩容劳动力之一。

helpTransfer 的逻辑是先检查 nextTable 是否存在，然后用 CAS 调整 sizeCtl 的线程计数，最后调用 transfer 领取任务。这个过程是“顺手帮忙”，而不是“排队等待”。在扩容期间，多个写线程可以同时进入 transfer，每人分一段桶去搬，工作量被拆成了众包。

3.3 非空桶的 synchronized 块：二次检查是底线

当桶里已经有节点时，代码进入了synchronized (f)。这里锁的是桶头对象，不是整个表。但进入同步块之后，第一件事是if (tabAt(tab, i) == f)。为什么要二次确认？因为线程在执行到 synchronized 之前，另一个线程可能已经把桶头换掉了，比如发生过一次扩容，当前桶位置已经变成了 ForwardingNode。锁一个过期的头节点没有任何意义，所以必须重新读一次 volatile 桶位置，确认锁的还是当前有效的头。

在锁内部，普通链表节点走遍历查找。找到相同 key 就按 onlyIfAbsent 决定是否覆盖；找不到就在链表尾部新增节点。这里没有 hash 冲突时的独立处理，因为链表的顺序并不敏感，只有树化之后才需要遵循红黑树规则。

3.4 binCount 到 8 之后，为什么还要看看数组长度够不够

binCount 记录的是链表中节点数量。插入完成后，代码发现 binCount 达到 TREEIFY_THRESHOLD(8) 就调用 treeifyBin。但 treeifyBin 内部还有一个致命判断：

if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY) tryPresize(n << 1);

只有 table 长度不小于 MIN_TREEIFY_CAPACITY(64) 时才真的把链表转成红黑树；否则只做扩容，把容量翻倍。原因是：冲突严重不一定是 key 的哈希分布差，也可能是因为桶太少了。在容量只有 16 或 32 时，多个本来分散的 key 被迫落到同一个桶里，这时候最合理的手段是把桶变多，而不是花高昂代价去维护一棵红黑树。红黑树节点多两个指针、维护成本高，只有确认“桶已经足够多却仍然长链化”，树化才值得。

4. transfer 扩容：一场不需要全局锁的众筹式搬迁

ConcurrentHashMap 最精彩的地方就是 transfer。整个扩容过程没有一把全表锁，多个线程各领一段，搬完一个桶就把旧位置标记成 ForwardingNode，读线程遇到路标自动去新数组找，写线程遇到路标也会加入搬迁。我第一遍读到这里时，起了一身鸡皮疙瘩。

4.1 扩容是怎么被触发的：addCount 和 tryPresize

写操作最后会调用addCount(1L, binCount)。addCount 不只是计数，它还承担扩容检测。关键逻辑可以理解为：当 binCount 大于等于 0 时，说明当前是一次真实写入，写完后检查counterCells和 baseCount 的总和是否超过 sizeCtl，如果超过就调用 transfer 开始扩容。而 treeifyBin 里发现容量不够 64 时调用的 tryPresize，走的是另一条主动扩容路径，它直接根据目标容量去 resizeStamp 并启动 transfer。两条路最终都会汇入同一个 transfer。

4.2 stride、transferIndex 和 bound：把大数组切成任务包

transfer 一开始，先计算每个线程一步最多搬多少个桶：

int stride = (n >>> 3) / NCPU; if (stride < MIN_TRANSFER_STRIDE) stride = MIN_TRANSFER_STRIDE;

n 是旧数组长度，NCPU 是 CPU 核数。默认情况下，一个线程一次至少要领 MIN_TRANSFER_STRIDE 个桶，避免线程数太多时任务切得太碎，反而增加 CAS 争抢。实际领取时，transferIndex 是一个 volatile 字段，记录当前任务边界。线程通过 CAS 从 transferIndex 扣下一段区间，然后把本线程负责的区间设为[bound, i]。

因为扩容任务是异步的，参与者随时可能加入或退出，所以 while 循环里用--i >= bound来代表从高索引向低索引逐个搬。这个从后往前搬的顺序本身没有特殊意义，只是为了和 transferIndex 递减逻辑保持一致，让每次 CAS 减出来的区间不重叠。

4.3 链表迁移的杀手锏：一次 hash & n 切两半

迁移一个链表桶时，源码没有傻到逐节点计算新位置，而是用了一个决定性技巧。Array 容量翻倍后，节点的新下标要么保持原下标 i，要么变成 i + n，关键看它的 hash 在新增的那一位上是 0 还是 1。也就是：

if ((ph & n) == 0) { // 放入低位链 } else { // 放入高位链 }

这行代码几乎是 transfer 里最精华的一行。n 在扩容前是 old table 的长度，它的二进制只有一个 1 位。一个节点的 hash 和 n 做与运算，结果非零，说明它新增位的值是 1，新位置是 i + n；结果是 0，新位置仍是 i。所以一次遍历就能把链表拆成两条，一条留在原索引 i，一条放到 i + n，根本不用为每个节点重新计算下标。

再看一个叫 lastRun 的优化。代码从链表头开始往后找“最后一段 runBit 相同的尾巴”，然后直接把这段尾巴整体挂过去，只处理它之前的节点。这是因为一段连续的后缀节点既然 hash&n 的结果都一样，它们在新旧数组中的相对位置完全不变，可以整段复用，省掉一部分新建节点的操作。这个优化在链表很长、尾部连续相同的情况下收益明显。

4.4 TreeBin 和 TreeNode 的拆分也有高低位

如果桶头是 TreeBin，迁移逻辑不直接遍历红黑树，而是先顺着 TreeBin.first 这条链表把所有 TreeNode 扫一遍，同样用hash & n分成 lo 和 hi 两半。然后对每一半重新判断节点数量：如果少到 UNTREEIFY_THRESHOLD(6) 以下，说明这半边退化回链表更高效，就 new 普通 Node 串成链表；否则新建一棵 TreeBin。这个“6”和“8”之间留了 2 个节点的缓冲，就是为了避免在树化和退化之间反复横跳。

迁移完桶内所有节点后，源码会在旧数组的这个桶位置放入 ForwardingNode：

setTabAt(tab, i, fwd);

这行非常重要。它是“这个桶已经被人搬完了”的唯一标志。后续线程如果还没领到这个桶，看到它的位置是 ForwardingNode 就会跳过；如果准备写入这个桶，也会先帮忙扩容而不是直接覆盖。

4.5 最后一个线程负责收尾：nextTable 转正与 sizeCtl 更新

多线程一起扩容，怎么判断“扩容结束了”？源码用了一个非常巧妙的 CAS 计数：每个线程搬完自己领到的区间后，会尝试通过 CAS 把 sizeCtl 减 1。但这个值减到多少才算结束，取决于 resizeStamp 的换算关系。只有当最后一次 CAS 使计数满足退出条件时，这个线程才是真正的“收尾线程”，它负责把 nextTable 赋给 table，并清空 nextTable。

此后 sizeCtl 更新为(n << 1) - (n >>> 1)，这里 n 是旧容量，所以新容量是 2n，新阈值就是 2n 的 0.75，也就是(2n - n/2) = 1.5n。所有参与扩容的线程都各回各家，表正式完成翻倍。

5. get、size、遍历：没有锁也敢读的底气

ConcurrentHashMap 的读方法从来不直接加锁。给人的第一感觉是“不设防”，实际上它的安全建立在 volatile 和特殊节点的配合上。

5.1 get 为什么可以全程无锁

get 的流程非常简单：

Node<K,V>[] tab = table; int n = tab.length; Node<K,V> e = tabAt(tab, (n - 1) & h); if (e == null) return null; if (e.hash == h && key 相等) return e.val; else if (e.hash < 0) return e.find(h, key); else 遍历链表;

依赖 volatile 见到的 table 引用自然能看到最新的数组结构。读到一个普通的桶头，说明该桶还没有被迁移，直接遍历即可。读到 MOVED 节点，就会调用 ForwardingNode.find，把查询转发到新数组；读到 TreeBin，会用树查找；读到 ReservationNode，直接返回 null。这些 find 方法内部都是无锁的，靠的是节点本身不被修改或修改时使用 volatile 写入。

那“读一半，写一半”会不会读到脏数据？答案是：读线程能看到的是同一时刻某个中间态，但绝不会出现指针撕裂之类的非法状态。节点的 next 字段是用 volatile 修饰的，链表的拼接顺序保证了读到的每个节点都是已经完整构造好的对象。它的读结果不保证是你调用 get 那一刻之前的“最终态”，这就是弱一致性。

5.2 size() 的 baseCount 和 CounterCell 是怎么配合的

size 的难点是：每个写线程都去 CAS 一个大变量，冲突会非常严重。源码的解决办法是分散计数。增加计数时先尝试给 baseCount 做 CAS，如果失败，说明竞争激烈，就转而找到一个 CounterCell 单元格，对这个 cell 的 value 做 CAS。每个线程通过 ThreadLocalRandom.getProbe 获取一个 probe 值，再根据 cells 长度取模确定用哪个格子。

真正执行 size() 时，则是把 baseCount 和所有 CounterCell 的 value 全部加起来。因为加了这么多个格子，且每个格子都在随时变化，所以最终结果只能是一个近似值。如果追求严格一致性，那每次 size() 都得阻塞全部写操作，这对一个并发容器来说是得不偿失的。官方文档也直接说明 size 返回的是一个估计值，不要拿它当精确水位线。

5.3 遍历器的弱一致性到底“弱”到什么程度

ConcurrentHashMap 的迭代器不会抛出 ConcurrentModificationException。它不是快照式遍历，而是顺着当前桶数组移动，并且能看到迭代过程中已经发生的修改。如果你在遍历时恰逢扩容，可能出现某些在旧数组里的桶已经搬到新数组里、而迭代器还没走到的情况，于是这次“漏”掉了那个桶里的元素。这种“弱一致”在很多场景下是能接受的，比如统计、清理、批量打印；但如果你的业务是“遍历时必须看到某个时刻的完整副本”，那就得先 clone 或 lock 一把大局。

6. 较真儿之后，我实际验证过的几条经验

源码读完了，不代表真的理解了。我发现自己至少凭空踩过几个坑，下面这几条是我验证过并且觉得很有用的经验。

6.1 验证“桶锁不锁全表”的正确姿势

我一直知道 ConcurrentHashMap 是桶锁，但真正感受到它是在一个压测里：16 个线程同时往两个不同 key 的桶里写，通过 JFR 的锁竞争事件能看到 synchronized 锁几乎不争抢。而如果把所有线程都压到同一个 key 上，锁竞争会立刻飙升。对比实验非常直观：不管并发多大，只要 key 分散，桶锁的设计就能扛住；可一旦 key 聚集，它也会退化为一种“局部串行”。这说明官方推荐用不可变对象和分散性好的 hashCode 做主键，不是空话。

6.2 扩容期间的观察实验：读请求会去哪儿

我曾经用一个大 map 在后台循环 put，同时在前台循环 get 某个不存在的 key，然后故意把所有 put 集中到触发扩容的容量临界点。用 JFR 观察线程栈可以看到，有些读线程短暂地跑到 transfer 方法里帮忙迁移。这不是 bug，而是读路径遇到 ForwardingNode 后主动帮助扩容的证明。读线程不写数据，但它帮忙把桶位置标记为 ForwardingNode，从而加速后续读写。理解了这一点之后，再看 helpTransfer 这个名字，就觉得作者真的太会取名了。

6.3 一份更进阶的源码阅读清单

读完这一轮之后，我觉得还差点火候，又补了这几个点：

• remove 方法里的 replaceNode 逻辑，它同时处理了链表删除和红黑树退化，和 putVal 形成对照；
• computeIfAbsent 里的 ReservationNode 占位思想，理解了它就能明白为什么这个操作允许“只计算一次”；
• addCount 的 fullAddCount 方法，里面涉及 CounterCell 初始化和扩容，非常值得单独看；
• HashMap 里的 resize 逻辑，里面的(e.hash & oldCap)拆分思想和 ConcurrentHashMap 一脉相承。

如果非要给后来者一个建议：不要光看注释和博客，自己准备一个源码工程，在每个核心方法里打断点，用多线程 Debug 配合日志观察线程名。纸上得来终觉浅，这句老话放在并发源码上特别成立。等你亲眼看到一个线程走进 helpTransfer、另一个线程在 transfer 里领到一段任务包，你会真正理解“并发容器”这四个字的分量。