当前位置：首页 > 文章列表 > 文章 > java教程 > fail_fast机制在集合被并发修改时抛出异常的原理，主要依赖于迭代器的校验机制。当使用迭代器遍历集合时，集合内部会维护一个修改计数器（如 modCount），每次对集合进行结构性修改（如添加、删除元素）时，该计数器都会递增。而迭代器在初始化时会记录当前的 modCount 值。在遍历过程中，每次调用 next() 或 remove() 方法时，迭代器都会检查当前的 modCount 是否与初始

fail_fast机制在集合被并发修改时抛出异常的原理，主要依赖于迭代器的校验机制。当使用迭代器遍历集合时，集合内部会维护一个修改计数器（如 modCount），每次对集合进行结构性修改（如添加、删除元素）时，该计数器都会递增。而迭代器在初始化时会记录当前的 modCount 值。在遍历过程中，每次调用 next() 或 remove() 方法时，迭代器都会检查当前的 modCount 是否与初始

2026-04-08 11:36:28 0浏览收藏

fail-fast机制并非真正保障线程安全，而是一种轻量级的“调试提醒开关”：它通过对比集合的修改计数器（modCount）与迭代器创建时保存的快照（expectedModCount），在遍历过程中一旦发现二者不一致，就立即抛出ConcurrentModificationException，从而快速暴露结构性修改（无论来自多线程还是单线程误操作）带来的潜在风险；但它不依赖同步、不可靠于并发场景、可能漏判或误判，本质是为开发阶段及时发现问题而设计，而非生产环境的并发解决方案——真正需要线程安全时，应选用ConcurrentHashMap、CopyOnWriteArrayList等fail-safe集合或显式同步机制。

如何理解fail_fast机制在集合被并发修改时抛出异常原理

modCount 和 expectedModCount 是怎么配对的

fail-fast 的核心不是“检测并发”，而是“发现结构被意外修改”。ArrayList 在 AbstractList 中定义了 modCount 字段，每次调用 add()、remove()、clear() 等结构性修改方法时，它就自增 1。而迭代器（比如 Itr）在构造时会把当时的 modCount 值拷贝进自己的 expectedModCount 字段。

后续每次调用 next() 或 hasNext() 前，都会执行 checkForComodification() —— 就是简单比对这两个值。不等？立刻抛 ConcurrentModificationException。

这个机制不依赖线程同步或锁，纯靠数值快照比对，所以轻量但“不严谨”：它无法保证 100% 捕获所有并发修改，只保证“一旦被它看见，就马上失败”。

单线程里也会触发 ConcurrentModificationException 吗

会，而且很常见。只要在 for-each 或显式使用 iterator() 遍历时，直接调用集合自身的 remove() 或 add()，就会触发。

典型错误写法：

for (String s : list) {
    if ("bad".equals(s)) {
        list.remove(s); // ❌ 直接改集合，modCount 变了，但迭代器还拿着旧 expectedModCount
    }
}

正确做法（仅限单线程）：

用迭代器自己的 remove() 方法：it.remove()
改用 removeIf()：list.removeIf(s -> "bad".equals(s))
收集待删元素，遍历完再批量删

为什么 ConcurrentHashMap 和 CopyOnWriteArrayList 不抛这个异常

因为它们压根没实现 fail-fast 逻辑。它们的设计目标就是支持并发修改 + 安全遍历，策略完全不同：

ConcurrentHashMap 使用分段锁 + CAS + 迭代器基于快照（weakly consistent），遍历时允许修改，但不保证看到最新更新；CopyOnWriteArrayList 则是读操作完全无锁，写操作复制底层数组——迭代器持有的是创建时的数组副本，自然不会和原集合的 modCount 对不上。

换句话说：它们不是“不检测并发”，而是“不按 fail-fast 路子走”，属于 fail-safe 类型。别指望在它们身上看到 ConcurrentModificationException。