当前位置：首页 > news >正文

ConcurrentHashMap扩容过程中如何保证更新一致性

news 2026/3/26 22:25:01

在 ConcurrentHashMap（CHM）的扩容过程中，更新一致性（即：不会丢失写入、不会读到中间状态、所有线程看到一致的数据视图）是通过一系列精巧的并发控制机制实现的。下面从写操作（put/update）和读操作（get）两个维度，深入解析扩容期间如何保证更新一致性。

一、核心原则：迁移完成前，旧表仍有效

CHM 扩容采用 “双表并存 + 原子切换” 策略：

扩容期间，旧表（table）和新表（nextTable）同时存在
只有当一个桶（bucket）迁移完成后，才将旧表该位置替换为 ForwardingNode
在此之前，所有对该桶的读写仍作用于旧表

✅ 这保证了：任何时刻，每个 key 要么在旧表，要么在新表，不会“消失”或“分裂”

二、写操作（put/update）的一致性保障

当线程执行 put(key, value) 时：

情况 1：目标桶尚未迁移（仍是普通 Node）

直接在旧表中插入或更新
后续迁移线程会将这个新写入的节点一起迁移到新表
✅ 不会丢失更新

情况 2：目标桶已迁移（头节点是 ForwardingNode）

当前线程调用 helpTransfer() 协助扩容
扩容完成后，重新执行 put 操作（循环 retry）
此时 key 会直接插入到新表的正确位置
✅ 最终写入成功，且只存在于一个地方

🔁 关键：putVal() 方法内部是一个 for(;😉 循环，直到成功插入为止。

for (int i = 0;; ++i) {
if (tab == null || tab.length == 0)
initTable();
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
if (casTabAt(tab, i, null, newNode(hash, key, value, null)))
break;
}
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f); // 协助扩容后，tab 指向新表，继续循环
else {
// 锁住 f，插入或更新
}
}

💡 结论：无论扩容是否发生，put 操作最终都会成功写入唯一一份数据，不会重复、不会丢失。

三、读操作（get）的一致性保障

get(key) 在扩容期间完全无锁，但依然强一致：

如果桶未迁移

直接从旧表读取 → 正确

如果桶已迁移（ForwardingNode）

调用 ForwardingNode.find(hash, key)
该方法会自动跳转到 nextTable 查找
✅ 读到的是最新值

如果桶正在迁移（但尚未 CAS 成功）

由于迁移是最后一步才设置 ForwardingNode
此时桶仍是普通链表 → 从旧表读取 → 正确

📌 关键点：

ForwardingNode 的设置是原子的（CAS）
Node.next 是 final 的，链表结构不可变
table 和 nextTable 字段都是 volatile，保证可见性

因此，get 永远不会看到“部分迁移”的链表，也不会读到 null 或错误值。

四、并发写 + 扩容：如何避免覆盖？

假设有两个线程：

线程 A：正在迁移桶 X
线程 B：同时对桶 X 执行 put

执行顺序分析：

若线程 B 先执行：
- 桶 X 还是普通节点 → B 成功写入旧表
- 线程 A 迁移时会包含 B 写入的新节点 → 一致
若线程 A 先完成迁移（设置 ForwardingNode）：
- 线程 B 发现 MOVED → 协助扩容 → 重试 put
- 重试时直接写入新表 → 一致
若线程 A 正在迁移，但未完成：
- 桶 X 仍是原链表 → B 写入旧表
- A 的迁移是遍历当前完整链表，会包含 B 的写入
- 最后 CAS 设置 ForwardingNode → 原子切换