如何避免并发修改集合时引发的 ConcurrentModificationException，通过变量快照分析解决？

本文共计939个文字，预计阅读时间需要4分钟。

在多线程环境下遍历集合时抛出`ConcurrentModificationException`，根本原因不是并发修改本身，而是因为迭代器内部维护的`modCount（修改计数）`快速照相机机制失效。它本质上是一个单线程安全检测机制，误用于多线程环境后，暴露了设计局限。

modCount 快照机制如何工作

ArrayList、HashMap 等非线程安全集合在结构变更（add/remove/resize）时会递增自身 modCount 字段；而每个迭代器（如 ArrayList.Itr）在创建时会复制该值为 expectedModCount。每次调用 next() 或 remove() 前，都会检查二者是否一致：

• 一致 → 继续迭代
• 不一致 → 抛出 ConcurrentModificationException

这个检查发生在单次迭代操作入口处，不涉及锁或内存屏障，纯粹是“事后校验”。它无法区分：是其他线程改了集合？还是本线程在迭代中途自己调用了 list.remove()？——都算“非法修改”。

为什么“变量快照”不能解决并发问题

有人尝试用局部变量保存集合引用再遍历，例如：

List<String> snapshot = new ArrayList<>(originalList); for (String s : snapshot) { ... }

这确实避免了 CME，但不是因为解决了并发，而是绕开了检测机制**：你遍历的是副本，原集合怎么改都不影响副本的 modCount。**但它带来新问题：

• 数据陈旧：副本生成后，原集合的新增/删除对本次遍历完全不可见
• 内存开销：大集合频繁拷贝浪费资源
• 逻辑错位：若遍历中需根据实时状态做决策（如跳过刚被标记删除的项），副本无法支撑

真正可靠的应对方式

应按场景选择语义正确的方案，而非依赖快照“蒙混过关”：

• 读多写少 + 接受短暂不一致：用 Collections.unmodifiableList() 包装，或直接使用 CopyOnWriteArrayList（写操作复制数组，读操作无锁且永远不抛 CME）
• 需要强一致性读写：改用线程安全集合（如 ConcurrentHashMap），注意其迭代器弱一致性——不抛 CME，但可能反映某次修改前/后的状态，不保证实时全量可见
• 必须精确控制临界区：对原集合加显式锁（如 synchronized(list)），并在同步块内完成全部遍历与修改操作——此时 modCount 校验仍有效，且线程安全由锁保障

调试时的关键识别点

看到 CME 不要条件反射加锁或切集合类型。先确认：异常是否发生在多线程环境？还是单线程中迭代时调用了集合自身的 remove()？

• 单线程：典型错误是 for-each 中调 list.remove()，应改用 Iterator.remove()
• 多线程：说明有未协调的并发访问，需按上一条选型，而非简单加个局部变量

堆栈里出现 java.util.ArrayList$Itr.checkForComodification 就是 modCount 校验失败的铁证，它只告诉你“检测到了不一致”，不告诉你谁改的、何时改的——日志或调试器跟踪实际修改点才是关键。