Java遍历集合时为何不能修改_ConcurrentModification解析

在Java中遍历集合时修改结构（如add/remove）会抛出ConcurrentModificationException，这并非源于多线程并发，而是单线程下fail-fast机制主动拦截的“逻辑错误”——集合通过modCount与迭代器的expectedModCount比对实时监控结构性变更，一旦不一致立即报错，旨在防止跳过元素、重复访问或无限循环等隐患；真正安全的做法是使用Iterator.remove()、倒序遍历、收集后批量处理，或选用CopyOnWriteArrayList等支持迭代中修改的并发集合，而非试图绕过这一设计精良的“安全护栏”。

Java中遍历集合时修改集合（如add、remove）会抛出ConcurrentModificationException，根本原因不是“并发”导致的，而是快速失败（fail-fast）机制主动检测到结构性修改——哪怕单线程下也会触发。

什么是modCount和expectedModCount

ArrayList、HashMap等集合内部维护一个modCount（修改计数器），每次调用add()、remove()、clear()等改变结构的方法时，该值自增。迭代器（如Iterator）在创建时会把当前modCount值复制给自己的expectedModCount。每次调用next()或hasNext()前，都会检查二者是否一致；不一致就立即抛出ConcurrentModificationException。

• 注意：只对“结构性修改”敏感（比如增删元素），修改已有元素的值（如list.set(i, x)）通常不会触发异常
• 注意：forEach循环、增强for循环（for (E e : list)）底层仍使用Iterator，同样受此限制

为什么设计成这样而不是允许修改

迭代过程依赖集合当前状态（如数组长度、链表指针位置）。如果边遍历边修改，可能跳过元素、重复访问、甚至进入无限循环或数组越界。Fail-fast不是为解决并发问题而生，而是及早暴露逻辑错误——大多数情况下，遍历时修改集合是程序设计缺陷，而非合理需求。

• 例如：遍历List删除所有null元素，若用for (String s : list)配合list.remove(s)，第二次迭代就可能抛异常或漏删
• 它不保证线程安全，只是单线程下的“安全护栏”

正确做法：需要边遍历边删改时怎么做

有明确替代方案，不依赖“绕过检测”：

• 用Iterator的remove()方法：这是唯一被允许的删除方式，它会同步更新expectedModCount，例如：it.remove()
• 收集待操作元素，遍历结束后统一处理：如先用new ArrayList()存要删的项，再调用removeAll()
• 使用支持并发修改的集合：如CopyOnWriteArrayList（适合读多写少）、ConcurrentHashMap（迭代时不抛CME，但不保证反映实时修改）
• 倒序for循环（仅适用于List）：用for (int i = list.size()-1; i >= 0; i--)删除，避免索引错位

哪些情况不会抛ConcurrentModificationException

不是所有修改都会触发：

• 使用Iterator.remove() —— 显式支持
• 使用ListIterator.add()或set() —— 部分实现支持（如ArrayList的ListIterator允许add/set）
• 遍历过程中只读操作，或仅修改元素内容（非结构）
• 使用java.util.concurrent包下的集合（如ConcurrentLinkedQueue），它们不采用fail-fast，而是弱一致性迭代

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。