Java中 expectedModCount 与 modCount 不一致触发 ConcurrentModificationException 的源码分析-java教程-PHP中文网

concurrentmodificationexception 的核心是 modcount 与 expectedmodcount 不一致；modcount 记录集合结构性修改次数，expectedmodcount 是迭代器初始化时复制的快照值，遍历时校验不一致即抛异常，单线程误操作（如遍历中调用集合 remove）也会触发。

java中 expectedmodcount 与 modcount 不一致触发 concurrentmodificationexception 的源码分析

Java 中 ConcurrentModificationException（CME）的抛出，核心在于迭代器内部维护的 expectedModCount 与集合实际的 modCount 值不一致。这不是线程安全问题的专属标志，单线程下误操作同样会触发。

modCount 是什么？

modCount（modification count）是大多数集合类（如 ArrayList、HashMap、LinkedList）定义的结构性修改计数器，类型为 int，初始值为 0。只要发生增删元素等改变集合大小或内部结构的操作（如 add()、remove()、clear()），它就会自增。

注意：set()（替换已有位置元素）、get() 等非结构性操作不会修改 modCount。

expectedModCount 是怎么来的？

当调用集合的 iterator() 方法时，会创建一个迭代器实例（如 ArrayList.Itr）。该迭代器在构造时，会将当前集合的 modCount 值拷贝一份到自己的 expectedModCount 字段中：

expectedModCount = modCount;

这个“快照”代表了迭代器创建那一刻集合的结构状态。后续每次调用 next() 或 hasNext() 前，迭代器都会校验：
if (modCount != expectedModCount) → 立即抛出 ConcurrentModificationException。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

为什么单线程也会触发？

常见错误场景是：在使用增强 for 循环或显式迭代器遍历集合时，**直接调用集合自身的修改方法**（而非迭代器的 remove()）：

for (String s : list) { if (s.equals("bad")) list.remove(s); }
Iterator<string> it = list.iterator(); while(it.hasNext()) { String s = it.next(); if (s.equals("bad")) list.remove(s); }</string>

此时，集合的 remove() 修改了 modCount，但迭代器的 expectedModCount 未同步更新，下次 next() 检查就失败。

正确做法是使用迭代器自己的 remove() 方法 —— 它会在删除后同步更新 expectedModCount，保持一致性。

fail-fast 机制的本质

这种检查不是为了保证并发安全，而是提供快速失败（fail-fast）** 的调试支持。它无法防止并发修改，也不能替代真正的线程安全方案（如 CopyOnWriteArrayList、ConcurrentHashMap 或外部同步）。它的价值在于：第一时间暴露逻辑错误，避免因结构不一致导致更隐蔽的数据错乱或无限循环。

某些集合（如 java.util.concurrent 包下的类）压根不使用 modCount，它们的迭代器是弱一致性（weakly consistent）的，不会抛 CME，但也不承诺反映实时结构。