核心区别在于校验机制：fail-fast通过modCount实时校验集合修改，不一致则抛ConcurrentModificationException；fail-safe（如CopyOnWriteArrayList）基于快照隔离读写，不校验、不抛异常；ConcurrentHashMap属弱一致性，非严格fail-safe。
核心区别不在“会不会抛异常”，而在“它凭什么决定抛不抛”。fail-fast靠实时校验集合状态来预警，fail-safe压根不看原集合——它只操作自己的快照。
fail-fast：用 modCount 做运行时哨兵
ArrayList、HashMap 等集合内部维护一个 modCount（修改计数器），每次 add/remove 结构性操作都会自增。迭代器创建时，把当前 modCount 复制为 expectedModCount；之后每次调用 next() 或 remove() 前，都检查两者是否一致：
- 不一致 → 立即抛 ConcurrentModificationException
- 一致 → 继续遍历
这个机制不是同步锁，也不保证 100% 捕获所有并发修改——比如多线程同时改 modCount 可能发生竞态丢失，或某些修改恰好没触发校验点。它的正经用途，是帮你快速发现“遍历时误调集合方法”这类 bug。
fail-safe：用数据副本隔离读写
CopyOnWriteArrayList 是典型代表。它的迭代器在创建时，就复制当前数组的引用（注意：是引用复制，不是深拷贝整个对象），后续所有 next() 都在这个副本上进行：
立即学习“Java免费学习笔记（深入）”；
- 原集合增删改 → 新建数组、更新引用，不影响已有迭代器
- 迭代器看不到新修改 → 它看到的是“创建那一刻”的快照
- 无校验逻辑 → 根本不读 modCount，自然不会抛 ConcurrentModificationException
代价是内存开销大、写操作慢（每次写都要复制数组），但读操作完全无锁、线程安全。
ConcurrentHashMap 是个特例：弱一致性，不是严格 fail-safe
它的迭代器既不校验 modCount，也不复制整个哈希表。它按桶（bin）或段（segment）逐步访问，允许看到部分已更新、部分未更新的数据：
- 遍历时插入的新 key-value → 可能被看到，也可能被忽略
- 不抛异常 → 但也不承诺“某一时刻的完整快照”
- JavaDoc 明确称其为 weakly consistent，而非 fail-safe
真正符合 fail-safe 定义的，只有 CopyOnWriteArrayList 这类基于不可变快照的实现。
单线程也会触发 fail-fast？完全可能
这不是多线程专属问题，而是结构修改与迭代生命周期冲突的必然结果：
- for-each 遍历 ArrayList 时调用 list.remove() → 触发异常
- Iterator.hasNext() 和 next() 之间，其他代码调用 map.put() → 触发异常
- 关键在于：只要不是通过 iterator.remove() 修改，就可能踩中校验失败
所以，即使没有多线程，只要遍历和修改混用，fail-fast 就会起作用。
