如何理解 Java 集合遍历时的删除陷阱：为什么不能在 foreach 中直接 remove

如何理解 Ja va 集合遍历时的删除陷阱：为什么不能在 foreach 中直接 remove

在 Ja va 开发中，一个经典的“坑”就是试图在 foreach 循环里直接调用 list.remove()。很多人第一反应是并发问题，但其实不然。根本原因在于 Ja va 集合框架内置的快速失败（fail-fast）机制。这个机制的核心目的，就是检测集合在遍历过程中是否被意外修改，一旦发现，哪怕是在单线程环境下，也会毫不犹豫地抛出异常。

底层靠 modCount 计数器校验一致性

要理解这个机制，得先看看集合内部是怎么“记账”的。像 ArrayList、HashMap 这些常见的集合类，内部都维护着一个叫 modCount 的修改计数器。每次进行结构性操作，比如添加（add）或删除（remove），这个计数器就会自动加一。

而 foreach 循环，底层其实是迭代器（Iterator）的语法糖。当迭代器被创建时，它会“拍个快照”，把集合当前的 modCount 值记录下来，存为自己的 expectedModCount。此后，每次调用 next() 或 hasNext() 方法，它都会做一次对账检查：

• 如果 modCount == expectedModCount，说明集合没被“外人”动过，遍历继续。
• 如果两者不相等了（比如你手动调用了 list.remove()，导致集合的 modCount 变了，但迭代器自己的 expectedModCount 还是老样子），对不起，ConcurrentModificationException 异常立刻抛出。

所以说，问题不在于删除操作本身，而在于“谁”在遍历期间动了集合。

foreach 本质是迭代器语法糖，不是“普通循环”

我们来看看这段典型的错误代码：

for (String s : list) {
    if (s.equals("test")) list.remove(s);
}

它编译之后，实际上等价于下面这段使用迭代器的代码：

Iterator it = list.iterator();
while (it.hasNext()) {
    String s = it.next(); // 注意！就是在这里检查 modCount！
    if (s.equals("test")) list.remove(s); // 这里修改了集合的 modCount
}

关键点在于，it.next() 方法内部会执行一致性检查。当你在循环体内直接用 list.remove(s) 删除了一个元素，集合的 modCount 就增加了。等到下一次循环，迭代器再次调用 next() 时，一比对发现账对不上，异常就发生了。这破坏了迭代器对集合状态连续性的预期。

为什么 Iterator.remove() 就可以？

那么，为什么用迭代器自己的 remove() 方法就安全呢？道理很简单：这是“内部人”的操作。迭代器提供的 remove() 方法，在删除元素之后，会主动更新自己的 expectedModCount，让它与集合最新的 modCount 保持一致。相当于自己动手，自己把账本补平。

这里简单总结一下几种写法的安全性：

• 安全写法：使用 iterator.remove()。
• 安全写法：使用 Ja va 8 引入的 list.removeIf(x -> x.equals("test"))，其内部实现已经处理了并发修改问题。
• 不安全写法：在 foreach/迭代器遍历期间，调用集合本身的 list.remove(x)、list.add(x) 或 list.clear() 等任何结构性修改方法。

别误用 CopyOnWriteArrayList 当“万能解”

谈到遍历时删除，有人可能会想到 CopyOnWriteArrayList。没错，用它确实不会抛出 ConcurrentModificationException。但它的工作原理是“写时复制”：每次修改操作（如 add、remove）都会在底层创建一个全新的数组副本。这意味着它的迭代器遍历的其实是一个创建时的“快照”。

这种设计带来了不同的语义：你在遍历时删除元素，这个删除操作对当前正在进行的这次遍历是不可见的。它不会影响你正循环着的那个数据快照。这并非解决了遍历删除的并发修改异常，而是换了一种行为模式——你删了，但本次循环假装没看见。

因此，CopyOnWriteArrayList 更适合读操作远多于写操作的场景（比如事件监听器列表）。在日常业务逻辑中，如果需要边遍历边筛选元素，更推荐使用 removeIf() 方法，或者利用 Stream API 进行过滤并生成新列表。这样不仅意图更清晰，性能表现也更具可预测性。