ConcurrentHashMap 高效读操作源于无锁设计与可见性保障，读方法不加锁，依赖 volatile 和 final 语义确保内存可见性，结合扰动函数、2的幂长度数组及红黑树优化查找性能。
ConcurrentHashMap 的高效读操作，核心在于“无锁”和“可见性保障”，不是靠加锁排队，而是靠内存模型与数据结构协同设计实现的。
读操作全程不加锁
这是它比 Hashtable 和 synchronizedMap 快得多的根本原因。所有 get、containsKey、keySet() 遍历等读方法，都不获取任何锁。线程直接通过哈希计算定位到桶（bin），然后顺着链表或红黑树查找——整个过程是纯内存访问。
- Java 8+ 中，每个桶的头节点用 volatile 修饰，保证其他线程写入后，读线程能立即看到最新引用
- 节点内部的 next、value 字段也通过 volatile 或 final 语义确保可见性，避免读到“半初始化”的对象
- 即使某个桶正在被其他线程扩容或树化，get 仍可安全读取旧结构中的数据（弱一致性）
哈希寻址快，且冲突少
高效读的前提是能快速、准确地找到目标桶，这依赖于两个关键设计：
- 扰动函数 h ^ (h >>> 16)：对 key.hashCode() 做二次散列，显著降低低位重复导致的哈希碰撞
- 数组长度恒为 2 的幂，用 (n - 1) & hash 替代取模运算，位运算是 CPU 级别最快的操作之一
- 当链表长度 ≥8 且数组长度 ≥64 时自动转为红黑树，把 O(n) 查找降到 O(log n)，尤其在哈希分布不均时保底读性能
弱一致性迭代器不阻塞写入
entrySet()、values() 返回的集合视图，其迭代器不会抛 ConcurrentModificationException，也不要求遍历时禁止修改。它采用的是“快照式”遍历逻辑：
立即学习“Java免费学习笔记（深入）”；
- 遍历开始时记录当前数组引用，后续只在这个快照上走，不感知中途新增的桶
- 对已遍历过的桶，可能读不到最新写入；对未遍历桶，可能读到新写入的数据
- 这种设计让读操作完全脱离写线程干扰，吞吐量几乎随 CPU 核数线性增长
实际使用中要注意的边界
高效读不是绝对的，某些误用会悄悄拖慢它：
- key 的 hashCode() 返回常量（如始终 return 1），所有数据挤进同一个桶 → 锁争用+链表过长 → 读退化成遍历
- 在 get() 后立刻调用 computeIfAbsent() 做“查缺补漏”，把本该只读的路径变成写操作 → 触发头节点锁，破坏读并发性
- 频繁调用 size() 想判断是否为空 —— 它需遍历所有段求和，开销大且结果瞬时过期；改用 isEmpty() 更轻量
