Java集合遍历修改元素的正确方法

Java集合遍历中直接调用集合自身的remove()方法会触发ConcurrentModificationException，这并非多线程问题，而是因ArrayList等集合采用fail-fast机制——迭代器通过modCount校验确保遍历与修改由同一源头（即迭代器自身）完成；正确解法是统一使用Iterator.remove()实现安全删除，或借助JDK 8+的removeIf()批量过滤，既简洁又本质等价；若确需并发读写，则应选用CopyOnWriteArrayList或ConcurrentHashMap等线程安全替代方案，而非错误地加锁或混用操作方式——核心原则是：遍历和修改必须出自同一个“契约主体”，才能避开这个高频却常被误解的陷阱。

遍历 ArrayList 时调用 remove() 为什么会抛 ConcurrentModificationException

因为 ArrayList 的迭代器是「快速失败」（fail-fast）的：内部维护一个 modCount 计数器，每次调用 add()、remove() 等结构性修改方法都会更新它；而迭代器在 next() 前会校验当前 modCount 是否与创建时一致。直接在 for-each 或普通 Iterator 遍历中调用集合自身的 remove()，必然触发校验失败。

这不是线程安全问题，单线程下也会发生——只要「遍历」和「结构修改」不是通过迭代器自身完成，就踩坑。

• 错误写法：

  for (String s : list) { if (s.isEmpty()) list.remove(s); }

• 正确方向：必须用迭代器自己的 remove() 方法，或改用支持并发修改的集合
• Iterator.remove() 是唯一被允许的「边遍历边删」操作，它会同步更新 expectedModCount

用 Iterator.remove() 安全删除元素的写法

这是最轻量、最通用的解法，适用于所有实现了 Collection 接口的非并发集合（ArrayList、LinkedList、HashSet 等）。

• 必须显式获取 Iterator，不能用 for-each（它隐藏了迭代器）
• 每次调用 iterator.remove() 前，必须已成功执行过一次 iterator.next()
• 不能连续调用两次 remove()，否则抛 IllegalStateException

示例：

Iterator<string> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    if (s == null || s.trim().isEmpty()) {
        it.remove(); // ✅ 正确：通过迭代器删
    }
}</string>

想批量过滤，用 removeIf() 更简洁

JDK 8+ 的 Collection.removeIf(Predicate) 内部就是用迭代器安全实现的，语义清晰且一行解决。

• 底层仍走 Iterator.remove()，行为等价但封装得更干净
• 不支持中途 break，适合「全量扫描+条件删除」场景
• 对 ArrayList 性能略优于手写循环（避免重复数组拷贝）
• 注意：传入的 Predicate 不能修改集合本身，否则行为未定义

示例：

list.removeIf(s -> s == null || s.trim().isEmpty()); // ✅ 简洁安全

需要并发读写？换 CopyOnWriteArrayList 或 ConcurrentHashMap

如果真有多个线程同时读写，或者遍历期间其他逻辑可能修改集合，Iterator.remove() 和 removeIf() 都不够用——它们只解决单线程下的结构性冲突。

• CopyOnWriteArrayList：遍历时用快照，写操作新建数组。适合「读多写少」，但内存开销大、迭代器看不到最新写入
• ConcurrentHashMap：若你实际在操作键值对，它提供 computeIfPresent()、remove(key, value) 等原子操作，比手动同步更可靠
• 别用 synchronized(list) 包裹遍历——锁粒度太大，且无法防止外部代码绕过锁直接调用 list.remove()

示例（仅当多线程真实存在时才考虑）：

List<string> safeList = new CopyOnWriteArrayList(original);
// 这个迭代器不会抛 ConcurrentModificationException，但删的是旧快照里的元素</string>

真正容易被忽略的是：这个异常从不表示「有别的线程在改」，而是在提醒你「你正用两种不兼容的方式操作同一个集合」。只要把「谁删的」和「谁在遍历」统一到同一个迭代器实例上，90% 的情况就稳了。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java集合遍历修改元素的正确方法》文章吧，也可关注golang学习网公众号了解相关技术文章。