fail-fast是一种检测到结构性修改时立即抛concurrentmodificationexception的设计策略，核心是modcount与expectedmodcount校验；arraylist遍历时调用remove()会触发该异常，因modcount变更而expectedmodcount未同步。
Fail-Fast 是什么，为什么 ArrayList 迭代时删元素会抛 ConcurrentModificationException
Fail-Fast 不是 Java 关键字，而是一种设计策略：容器在检测到**结构被意外修改**（比如遍历时调用 remove()）时，立刻抛出异常中止操作，不掩盖问题。核心在于维护一个 modCount 计数器——每次结构性修改（增/删/清空）都会递增它；迭代器初始化时记录该值为 expectedModCount，后续每次 next() 都校验二者是否一致。
常见错误现象：
- 用
for-each遍历ArrayList，循环体内调用list.remove()→ 立刻抛ConcurrentModificationException - 多线程下，一个线程遍历，另一个线程修改集合 → 同样抛该异常（但不是线程安全问题的“解决”，只是暴露）
实操建议：
- 单线程删除：改用
Iterator.remove()，它会同步更新expectedModCount - 需要条件删除：用
removeIf()（Java 8+），内部已做 Fail-Fast 兼容处理 - 别手动 catch
ConcurrentModificationException来“绕过”——这说明逻辑本身有竞态或状态不一致
Fail-Safe 怎么做到不抛异常？CopyOnWriteArrayList 和 ConcurrentHashMap 的代价在哪
Fail-Safe 容器不依赖原集合的实时状态，而是**基于快照（snapshot）迭代**。典型代表是 CopyOnWriteArrayList：每次写操作（add/remove）都复制整个数组，迭代器持有的是创建时的数组副本，因此永远看不到“中间态”修改，自然不会抛异常。
立即学习“Java免费学习笔记（深入）”；
使用场景：
- 读多写少，且迭代期间允许读到“旧数据”（比如监听器列表、配置缓存）
- 不能容忍迭代中断，又无法重构为单线程安全删除逻辑
性能与兼容性影响：
-
CopyOnWriteArrayList写操作 O(n) 时间 + 大量内存拷贝，频繁写会导致 GC 压力剧增 -
ConcurrentHashMap迭代器是弱一致性（weakly consistent）：可能跳过刚插入的元素，也可能重复看到刚删除的元素，但绝不会抛ConcurrentModificationException - 它们都不是“线程安全的万能解”——比如
size()在并发写时可能不准，containsAll()等批量操作仍需额外同步
什么时候该选 Fail-Fast，什么时候必须用 Fail-Safe
关键判断点不在“要不要异常”，而在**数据一致性要求和操作模式**。
选 Fail-Fast（默认选择）：
- 单线程场景，且删除逻辑可明确控制（如用
Iterator.remove()或removeIf()） - 需要及时发现逻辑错误：比如误在 foreach 中修改集合，Fail-Fast 能立刻暴露 bug，而不是让程序带着脏数据继续跑
- 对内存敏感、写操作频繁（如高频更新的实时数据缓冲区）
选 Fail-Safe（谨慎选用）：
- 明确需要“迭代不中断”，且业务接受读到滞后数据（如 UI 刷新监听器列表）
- 写操作极少，但读+迭代极其频繁（如全局配置项的只读访问）
- 已经存在多线程并发修改+遍历，且无法统一加锁或重构流程
注意：Vector 和 Hashtable 是 synchronized 的 Fail-Fast 容器——它们加了锁，但迭代时仍检查 modCount，不是 Fail-Safe。
容易被忽略的陷阱：Fail-Safe 不等于线程安全，Fail-Fast 也不等于线程不安全
这是最常混淆的点。Fail-Fast/Fail-Safe 描述的是**迭代行为对结构性修改的响应方式**，和“线程安全”是正交概念。
-
ArrayList是 Fail-Fast，但非线程安全；CopyOnWriteArrayList是 Fail-Safe，且是线程安全的 -
ConcurrentHashMap是 Fail-Safe（迭代不抛异常），也是线程安全的；但它的computeIfAbsent()等方法仍需注意重入和副作用 - 即使用了 Fail-Safe 容器，如果多个线程共享某个对象并修改其内部状态（比如 list 里存的是可变对象），依然要自己保证该对象的线程安全
真正复杂的地方在于：业务逻辑常常混合了“结构修改”“元素状态变更”“跨容器协作”。这时候光换容器没用，得看清楚哪一层在变、谁在读、谁在写、延迟是否可接受——Fail-Fast 和 Fail-Safe 只是工具，不是替代思考的捷径。
