ConcurrentHashMap多线程扩容源码解析

ConcurrentHashMap 的“无锁读”设计堪称并发编程的精妙典范：get() 操作完全无视扩容过程，既不检查 sizeCtl、transferIndex，也不访问 nextTable，仅通过 volatile 读取、节点不可变性与有序写入保障数据一致性；无论其他线程正在执行 helpTransfer() 还是 transfer()，get() 始终安全地在原 table 或已迁移完成的节点中查找，真正实现了读写分离与高性能并发访问——原来“无锁”不是靠运气，而是靠底层原子语义与严谨状态隔离。

ConcurrentHashMap 的无锁读不依赖扩容过程，而是靠 volatile + 不可变性 + 有序写入保障；扩容本身是写操作，全程加锁或 CAS 控制，和 get() 无关。

get() 方法根本不关心是否正在扩容

调用 get() 时，只做三件事：算 hash、定位桶、顺着链表或红黑树查 key。整个过程不检查 sizeCtl、不读 transferIndex、不碰 nextTable —— 即使另一个线程正在执行 helpTransfer() 或 transfer()，get() 看到的仍是原 table 或已迁移完成的节点。

这是因为：

• tabAt() 读取桶头节点时，底层用的是 U.getObjectVolatile(tab, ((long)i ，强制从主内存读，保证看到最新写入
• 所有节点字段（如 next、val）都是 volatile 或 final，避免重排序和本地缓存 stale 值
• 扩容中迁移的节点会被包装成 ForwardingNode，get() 遇到它会直接跳转到 nextTable 继续查 —— 这个跳转是原子且无锁的

为什么 ForwardingNode 能让 get 安全跳转

ForwardingNode 是一个哑节点，其 hash = MOVED（-1），nextTable 指向新表。当 get() 在旧表中发现桶首是 ForwardingNode，就用相同 hash 去新表查 —— 这个逻辑在 find() 中硬编码，不涉及任何锁或 CAS。

关键点在于：

• ForwardingNode 的构造是「一次性写入」：nextTable 字段在构造器里赋值，之后永不修改
• setTabAt() 写入 ForwardingNode 到旧表桶位时，用的是 U.compareAndSwapObject() 或 U.putObjectVolatile()，确保其他线程能立即看到
• 即使新表尚未完全填满，只要目标桶有值（或为 null），get() 就能返回正确结果 —— 查不到不等于错，而是语义一致

扩容中的写操作如何避免干扰读

扩容由 transfer() 承担，它控制粒度是「桶区间」，不是单个节点。每个线程负责迁移一段连续桶，并通过 transferIndex 原子递减来分配任务。但这个过程对 get() 完全透明：

• 旧表始终可用，直到所有桶被标记为 ForwardingNode
• 新表是懒初始化的，只在首次需要时创建，且写入前先用 U.compareAndSwapObject() 确保可见
• 没有「中间态」暴露给读线程：要么读旧表，要么读新表，不存在半迁移到一半的桶被直接读取

换句话说，扩容的并发控制目标是「写写一致」，不是「读写同步」；get() 的一致性由内存模型（volatile + happens-before）兜底，不是靠等扩容结束。

容易忽略的边界：null 值与计算错误的 hash

很多人误以为「无锁读」意味着绝对安全，但实际有两个经典坑：

• 如果 key 的 hashCode() 返回值在多线程下不稳定（比如基于未同步的 mutable 字段），不同线程算出不同 hash，get() 可能查错桶位 —— 这不是 ConcurrentHashMap 的问题，而是 key 自身违反契约
• get() 返回 null 时，无法区分「key 不存在」还是「value 显式存了 null」，因为 ConcurrentHashMap 不允许 null value；这点和 HashMap 不同，但和无锁设计无关，纯属 API 约束

真正影响无锁读可靠性的，永远是 volatile 字段的正确使用、节点构造的不可变性、以及跳转逻辑的幂等性 —— 而不是扩容是否完成。

以上就是《ConcurrentHashMap多线程扩容源码解析》的详细内容，更多关于的资料请关注golang学习网公众号！