fail-fast机制通过modCount与expectedModCount比对，在遍历中检测结构修改并抛出ConcurrentModificationException以暴露bug；它非线程安全保证，单/多线程下均可能触发，但不可用于并发控制。
Java中的fail-fast机制是一种在遍历集合过程中检测非法修改的错误监测手段，核心目标不是“保证线程安全”，而是“尽早暴露bug”——一旦发现集合结构被意外修改，就立刻抛出ConcurrentModificationException，中断遍历。
fail-fast触发的关键条件
它只对“结构修改”敏感，比如add、remove、clear等改变集合大小或内部数组引用的操作；单纯修改元素内容（如list.set(0, "new")）通常不会触发。
- 单线程下也会触发：例如用增强for循环遍历时直接调用
list.remove() - 多线程下更常见：线程A用Iterator遍历，线程B同时增删元素
- 本质是“版本比对”：集合维护
modCount，迭代器创建时记下expectedModCount，每次调用next()或hasNext()前校验二者是否一致
为什么不能靠它做并发控制
fail-fast不是同步保障机制，而是一种调试辅助设计：
- 它不保证100%捕获所有并发修改（极端情况下
modCount绕回或被巧合重置，异常可能不抛） - 异常抛出时机不确定——可能在修改后几轮迭代才检查，不是实时响应
- 它的存在意义是提醒开发者：“这里存在未受保护的并发访问”，而不是代替锁或线程安全容器
常见集合的fail-fast行为
java.util包下的主流集合（ArrayList、HashMap、HashSet、LinkedList等）都实现了fail-fast，但注意：
-
ConcurrentHashMap不抛这个异常——它采用分段锁/CAS，属于“弱一致性”设计，不依赖modCount校验 -
CopyOnWriteArrayList也不触发——它走的是fail-safe路线，遍历时操作副本 -
Vector和Stack虽线程安全，但其Iterato
r仍含fail-fast逻辑（因内部也维护modCount）
如何安全地边遍历边修改
真需要修改，有几种明确可行的方式：
- 用迭代器自己的
remove()方法（它会同步更新expectedModCount） - 改用
CopyOnWriteArrayList——适合读多写少场景 - 加显式同步：遍历和修改都包裹在同一个
synchronized块中（注意锁对象要一致） - 收集待删元素，遍历结束后统一调用
removeAll()
