Java遍历集合报错ConcurrentModificationException的原因分析与解决方法
作者：网罗开发
问题背景：遍历时修改集合
在项目中，我们经常需要对列表进行“边遍历边删除”的操作，比如清理不符合条件的数据：
List<String> users = new ArrayList<>();
users.add("Tom");
users.add("Jerry");
users.add("Spike");
// 删除名字长度小于4的用户
for (String name : users) {
if (name.length() < 4) {
users.remove(name); // 报错！
}
}
运行结果如下：
Exception in thread "main" java.util.ConcurrentModificationException
很多初学者会以为是多线程并发的问题，其实不是——这段代码只有一个线程。真正的原因在于：我们在使用增强 for 循环（底层是 Iterator）遍历时修改了集合结构。
异常原理：fail-fast 机制
Java 的集合类（如 ArrayList、HashMap）在遍历时会维护一个“结构修改计数器（modCount）”。每次调用 add() 或 remove() 时，modCount 都会递增。
而在使用 Iterator 遍历时，迭代器内部也保存了一个 expectedModCount，表示它期望的修改次数。每次 next() 时都会检查：
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
所以，当你在遍历过程中直接操作原集合（而不是通过迭代器），modCount 会变化，而迭代器的 expectedModCount 没更新，于是触发了“fail-fast”保护机制。
解决方案 1：使用 Iterator.remove()
最正统、最安全的方式就是用 Iterator 自带的 remove() 方法。它会在删除元素的同时同步更新 expectedModCount，从而避免异常。
List<String> users = new ArrayList<>();
users.add("Tom");
users.add("Jerry");
users.add("Spike");
Iterator<String> iterator = users.iterator();
while (iterator.hasNext()) {
String name = iterator.next();
if (name.length() < 4) {
iterator.remove(); // 正确做法
}
}
System.out.println(users);
输出结果：
[Jerry, Spike]
没有报错，功能正常。
优点：
- 不会触发
ConcurrentModificationException； - 无需复制集合；
- 对性能影响小。
缺点：
- 写法略繁琐；
- 只能在单线程环境中安全使用。
解决方案 2：使用 CopyOnWriteArrayList（线程安全版）
如果你的场景是多线程修改集合，比如在 Web 请求或任务调度中共享数据，可以使用 CopyOnWriteArrayList。
这个类在写操作时会复制底层数组，从而保证读操作不会受写操作影响。
import java.util.concurrent.CopyOnWriteArrayList;
public class Demo {
public static void main(String[] args) {
CopyOnWriteArrayList<String> users = new CopyOnWriteArrayList<>();
users.add("Tom");
users.add("Jerry");
users.add("Spike");
for (String name : users) {
if (name.length() < 4) {
users.remove(name); // 不会抛异常
}
}
System.out.println(users);
}
}
输出：
[Jerry, Spike]
优点：
- 支持多线程安全修改；
- 不会触发并发修改异常；
- 读操作几乎无锁，非常快。
缺点：
- 写操作开销较大（每次写都会复制整个数组）；
- 不适合频繁写入的场景。
解决方案 3：Stream 流式重建集合（推荐现代写法）
在 Java 8 之后，其实最推荐的做法是使用 Stream 进行过滤或重建集合。这种写法既优雅又安全，不会破坏原集合。
List<String> users = new ArrayList<>();
users.add("Tom");
users.add("Jerry");
users.add("Spike");
// 使用 Stream 过滤重建集合
users = users.stream()
.filter(name -> name.length() >= 4)
.toList(); // 重新生成一个新列表
System.out.println(users);
输出：
[Jerry, Spike]
优点：
- 不会抛异常；
- 可读性好；
- 更符合函数式编程风格；
- 支持并行流提升性能。
缺点：
会生成新的集合对象（有一定内存开销）。
实际开发场景案例
在一个电商系统中，我们有一个用户购物车 List<CartItem>，每次请求结算时，需要过滤掉失效的商品。
开发者最开始写了这样一段代码：
for (CartItem item : cartItems) {
if (!item.isValid()) {
cartItems.remove(item); // 报 ConcurrentModificationException
}
}
上线后偶发异常。
后来改成：
Iterator<CartItem> iterator = cartItems.iterator();
while (iterator.hasNext()) {
if (!iterator.next().isValid()) {
iterator.remove(); // 安全删除
}
}
或者更现代一点：
cartItems = cartItems.stream()
.filter(CartItem::isValid)
.toList(); // 优雅且安全
这样既避免了异常，也让逻辑更清晰。
小结
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Iterator.remove() | 原地删除、安全可靠 | 单线程遍历 |
| CopyOnWriteArrayList | 线程安全、读写分离 | 多线程读取多、写入少 |
| Stream 过滤重建 | 优雅简洁、不可变式编程 | 推荐现代开发风格 |
结语
ConcurrentModificationException 本质上是 Java 集合为我们提供的一种保护机制，防止在遍历过程中意外修改数据导致不可预期结果。只要理解了它的底层原理——“fail-fast 校验 modCount”，你就能轻松避开这类问题。
简单记一句话：
遍历时不要直接改集合，要么用迭代器，要么重建集合。
到此这篇关于Java遍历集合报错ConcurrentModificationException的原因分析与解决方法的文章就介绍到这了,更多相关Java ConcurrentModificationException异常内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！