ConcurrentHashMap读操作为何不加锁却能保证线程安全？

Question

为什么ConcurrentHashMap的`get()`等读操作无需加锁，却能保证线程安全？其核心在于：**读操作依赖volatile语义与不可变性设计，而非锁机制**。JDK 8中，Node的`val`和`next`字段均被声明为`volatile`，确保读线程总能见到最新写入的值；同时，链表头结点（table[i]）的更新通过`Unsafe.compareAndSetObject`配合volatile写完成，具备happens-before关系。此外，ConcurrentHashMap禁止修改已有Node的`val`或`next`（即写操作仅通过CAS插入新节点或扩容重建），保证读取过程中结构不会发生“半初始化”或“撕裂”现象。值得注意的是，这仅保障单次读的可见性与一致性，不提供读-读、读-写之间的原子性组合（如`containsKey`+`get`非原子），也不保证遍历过程的实时一致性（弱一致性迭代器）。因此，“无锁读安全”本质是JMM、volatile、CAS与不可变设计协同作用的结果，而非零成本的“绝对安全”。

Answer 1

```html

一、现象层：为什么 get() 看似“无锁”却不会读到脏数据？

初学者常困惑：没有 synchronized 或 ReentrantLock，ConcurrentHashMap.get() 怎么敢保证线程安全？答案不在“锁”，而在 JVM 内存模型（JMM）的底层契约。它不阻止并发读，而是通过语义约束让每次读都“合法可见”。例如，即使写线程刚用 CAS 更新了某个桶的头节点，读线程也能立即感知——这不是运气，是 volatile 字段与原子写操作共同构建的 happens-before 链。

二、机制层：volatile + 不可变性 + CAS 的三重保障

• volatile 语义固化：JDK 8 中 Node<K,V> 的 val 和 next 均为 volatile 字段。这不仅禁止指令重排序，更强制每次读取都从主内存（或最新缓存行）加载，杜绝寄存器/本地缓存 stale 值。
• 结构不可变性设计：Node 实例一旦创建，其 val 和 next 永不原地修改（即无 setter）。所有更新均通过新建 Node + CAS 替换指针实现，规避了“写一半被读”的撕裂风险。
• CAS 驱动的头节点发布：向 table[i] 插入首个节点时，调用 Unsafe.compareAndSetObject(table, ((long)i << TSHIFT) + TBASE, null, node)。该操作包含 volatile 写语义，建立对后续读线程的强 happens-before 关系。

三、模型层：JMM 视角下的安全边界与局限

下表对比了 ConcurrentHashMap 读操作在 JMM 中的保障能力与典型误区：

保障维度	是否满足	技术依据	反例说明
单次 get(k) 的值可见性	✅ 是	val 为 volatile；查找路径中所有 next 跳转均依赖 volatile 读	—
containsKey(k) && get(k) 原子性	❌ 否	两次独立 volatile 读之间无同步点，中间可能被删除	返回 true 后 get() 返回 null
迭代器遍历的实时一致性	❌ 否（弱一致性）	迭代器基于快照式链表扫描，不阻塞写，也不反映中途插入/删除	keySet().iterator() 可能跳过新插入项

四、实现层：关键源码逻辑与内存屏障映射

// JDK 8 ConcurrentHashMap.Node 定义节选
static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    volatile V val;        // ← volatile 读写触发 LoadLoad / StoreStore 屏障
    volatile Node<K,V> next; // ← 同上，保障链表遍历的顺序可见性
    // ...
}

当执行 tab[i] = newNode（即 CAS 设置桶头）时，Unsafe 的 compareAndSetObject 在 x86 上编译为 lock cmpxchg 指令，隐含 full memory barrier；在 ARM 上则显式插入 dmb ish。这确保了此前所有写操作（如 new Node 的字段初始化）对其他 CPU 可见。

五、演进层：从 JDK 7 分段锁到 JDK 8 无锁读的设计跃迁

graph LR
  A[JDK 7: Segment 数组] -->|每个 Segment 是独立 ReentrantLock| B[读需获取 segment 锁]
  C[JDK 8: Node 数组 + TreeBin] -->|CAS + volatile| D[读完全无锁]
  B -->|锁粒度粗，争用高| E[吞吐瓶颈明显]
  D -->|细粒度发布语义+不可变节点| F[读吞吐线性扩展至 CPU 核数]
  E --> G[驱动重构为基于 Unsafe 的无锁范式]
  F --> H[成为云原生高并发场景默认 Map 实现]

六、实践层：开发者必须警惕的“安全幻觉”

• 误以为 get() 安全 ⇒ 就可随意组合多个读操作：须改用 computeIfAbsent 或外部同步处理复合逻辑。
• 忽略扩容期间的特殊状态：ForwardingNode 作为占位符，其 find() 方法会主动跳转到新表，该过程仍依赖 volatile 读与 CAS 协同，但要求调用方不缓存旧 table 引用。
• 将弱一致性迭代器用于强一致性校验场景：应改用 mappingCount() + forEach 或显式加锁保护临界区。

```