ConcurrentHashMap的无锁读不依赖扩容过程，而是靠volatile+不可变性+有序写入保障；get()只算hash、定位桶、遍历查找，不检查sizeCtl、transferIndex或nextTable，即使正在扩容也只读原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 字段的正确使用、节点构造的不可变性、以及跳转逻辑的幂等性 —— 而不是扩容是否完成。
