避坑指南：为什么你的ConcurrentModificationException只在特定情况下出现？

深度解析ConcurrentModificationException的边界条件与实战应对

在Java开发中，ArrayList作为最常用的集合类之一，其迭代过程中的ConcurrentModificationException（并发修改异常）堪称"经典陷阱"。这个看似简单的异常背后，隐藏着modCount与expectedModCount的微妙博弈，以及特定场景下的边界条件判断。本文将带你深入异常触发机制的核心，揭示那些教科书上未曾详述的特殊场景。

1. 异常触发机制的底层原理

要理解ConcurrentModificationException的触发条件，必须深入到ArrayList迭代器的实现细节。每个ArrayList实例都维护着一个关键计数器——modCount，它记录了集合结构性修改的次数（如add、remove操作）。当我们调用iterator()方法时，迭代器会将当前的modCount值保存为expectedModCount，作为后续一致性检查的基准。

核心检查逻辑体现在checkForComodification()方法中：

final void checkForComodification() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
}

这个看似简单的比较，在实际运行时会产生令人困惑的行为差异。关键在于理解modCount和expectedModCount的生命周期：