concurrenthashmap迭代器是弱一致性而非强一致性，它基于创建时刻的状态快照遍历，允许并发修改且不抛concurrentmodificationexception，但可能遗漏新增元素或反映部分修改。
因为 fail-safe 迭代器不保证看到所有修改，只保证“不崩溃、不抛异常”，它对并发修改的反映是部分的、延迟的、非实时的——这种行为在分布式和并发系统中就叫 Weak Consistency（弱一致性）。
它不承诺实时同步
弱一致性不是“错误”或“缺陷”，而是一种明确的设计取舍：用一致性换可用性。迭代器创建时拿到的是某个时间点的数据视图（比如 CopyOnWriteArrayList 的数组快照，或 ConcurrentHashMap 内部 segment/Node 的当前状态），后续写操作发生在新副本或新结构上，旧视图保持不变。因此：
- 已存在的元素修改或删除，大概率能被迭代器感知到（尤其在 CopyOnWriteArrayList 中，删除后原数组还在；ConcurrentHashMap 中某些节点变更会立即可见）
- 新增的元素，不一定出现在当前迭代中 —— 因为迭代器不扫描新分配的内存区域或新插入的哈希桶
- 迭代过程中发生的多次修改，可能只反映其中一部分，顺序也不一定与实际发生顺序一致
它依赖底层实现机制
不同 fail-safe 集合的“弱程度”不同：
- CopyOnWriteArrayList：迭代器基于创建时刻的完整数组副本，期间所有 add/remove 都不影响该副本 → 绝对看不到新增，也看不到删除（除非删的是副本里没有的元素）→ 弱一致性表现得更“静态”
- ConcurrentHashMap：迭代器是“弱一致”的官方定义来源之一。它不锁整个 map，而是按段或桶遍历，允许并发更新；可能跳过刚插入的节点，也可能看到尚未完成 rehash 的中间状态 → 修改有一定概率被观察到，但不保证
它和强一致性有本质区别
强一致性要求：任意读操作都能看到之前所有已提交的写操作。而 weakly consistent 迭代器不满足这点：
- 没有全局时间戳或版本号协调
- 不阻塞写线程，也不等待写操作完成后再开始读
- 不要求“读-写”之间存在 happens-before 关系
所以它不叫 “eventually consistent（最终一致性）”，也不是 “linearizable（线性一致性）”，而是更轻量、更低开销的弱一致性模型。
Java 文档明确使用这个术语
ConcurrentHashMap 的 Javadoc 直接写明：“The iterators returned by ConcurrentHashMap are weakly consistent.” 这不是随意命名，而是对标并发理论中的标准概念——强调其行为可预测（不会出错）、但不精确（不强一致）。这也是为什么不能用它做需要严格数据新鲜度的业务逻辑，比如实时余额校验或事务回滚判断。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
