Java遍历集合时为何不能修改ConcurrentModification原因解析

大家好，今天本人给大家带来文章《Java遍历集合时为何不能修改ConcurrentModification解析》，文中内容主要涉及到，如果你对文章方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

ConcurrentModificationException的根本原因是fail-fast机制检测到结构性修改，而非并发问题；集合通过modCount与expectedModCount比对实现该机制，仅Iterator.remove()等特定操作被允许。

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，而是弱一致性迭代

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