ConcurrentHashMap迭代器是弱一致性而非fail-fast或fail-safe：它不抛ConcurrentModificationException，也不做全量复制，而是基于快照视图遍历，可能跳过或重复访问元素，官方明确定义为“weakly consistent”。
ConcurrentHashMap 的迭代器既不是典型的 fail-fast，也不是严格意义上的 fail-safe，而是提供弱一致性（weakly consistent）——这是它最准确的定位。
为什么不是 fail-fast？
fail-fast 的核心表现是：一旦检测到集合结构被修改，就立即抛出 ConcurrentModificationException。而 ConcurrentHashMap 的迭代器从不抛这个异常，哪怕你在遍历过程中用 put、remove 并发修改了 map，迭代器仍能继续运行，不会中断。
- 它不依赖
modCount和expectedModCount的校验机制 - 底层采用分段锁 + CAS + 链表/红黑树迁移等并发控制，迭代过程读取的是某一时刻的“快照视图”或正在演进中的节点链
- 所以它绕过了 fail-fast 的触发条件
为什么不算标准的 fail-safe？
传统 fail-safe（如 CopyOnWriteArrayList）会在迭代开始时完整复制整个集合数据，后续所有遍历都基于副本，因此绝对看不到新修改，也绝不会受写操作影响。
- ConcurrentHashMap 不做全量拷贝，内存开销低，但代价是：你可能看到部分更新、也可能看不到——比如某个桶刚完成迁移，迭代器可能跳过或重复访问某些元素
- 官方文档明确称其为 “weakly consistent iterators”，强调“不保证反映迭代器创建后发生的全部修改”，也不承诺原子性快照
怎么快速判定一个集合的迭代器类型？
看三点：
立即学习“Java免费学习笔记（深入）”；
- 是否抛 ConcurrentModificationException：抛 → 很可能是 fail-fast（如 HashMap、ArrayList）
- 是否在迭代前复制全部数据：复制 → 典型 fail-safe（如 CopyOnWriteArrayList）
- 是否既不抛异常、也不复制，还能容忍并发修改且行为有明确定义：符合 → 弱一致性，属于并发集合的特殊设计（ConcurrentHashMap、ConcurrentLinkedQueue 等）
简单记：ConcurrentHashMap 迭代器不崩溃、不冻结、不保证全量可见——它务实、高效、有边界，但不是“安全失败”的教科书范例。
