怎么通过 for-each 循环在遍历过程中安全地识别但不能直接删除元素的逻辑缺陷

先说一个很多Ja va开发者都踩过的坑——在for-each循环里直接调用list.remove()删元素。表面上看，代码能编译能运行，有时候甚至不报错，但它的隐患是真实的。

问题的核心不是“语法不允许”，而是职责错配。for-each本质上是语法糖，编译器会把它翻译成基于Iterator的while循环。但当你在循环体里写了list.remove()，这个操作是由集合自身直接执行的，跟迭代器完全不在一个频道上。两组逻辑各自为政，最终必然导致关键变量失步。

modCount 与 expectedModCount：失步的真相

ArrayList内部维护了一个modCount字段，每次结构性修改（add、remove）都会让它+1。当Iterator创建时，它会记录下当时的modCount值，称为expectedModCount。此后每次调用next()之前，都会执行一个checkForComodification()检查，比较这两个数值是否一致。一旦发现不等，立刻抛出ConcurrentModificationException。

那删除行为会导致什么？分两种情况：

• 删除第一个元素：下一次调用next()时就触发检查，直接报错，问题暴露得很干脆。
• 删除倒数第二个元素：循环可能侥幸走到末尾才检查，或者压根没走到检查点。表面不报错，但最后一个元素被悄悄跳过——这才是最棘手的。

换句话说，异常不是一定会出现。是否报错，完全取决于删除位置和集合当前的迭代状态。

遍历指针“看不见”结构变化

再来看看底层逻辑。for-each背后的while循环依赖hasNext()来决定是否继续迭代，而hasNext()的判断条件很简单：当前cursor是否等于size。当你删除一个元素时，size减1，后续所有元素前移一位，但游标cursor的递增节奏不变。结果是什么？

• 下一个元素直接被“跨过去”，相当于被跳过了。
• 如果列表里有重复元素，比如多个"aaa"，几乎必然删不干净。
• 整个行为高度依赖删除位置和集合当前状态，不可预测，也不可复现。

这就好比一边走路一边拆路标，走路的节奏不变，但路本身在变——结果是迟早走岔。

这不是并发问题，是单线程下的确定性陷阱

很多人一看到ConcurrentModificationException，第一反应是“多线程并发导致的”。其实不然，哪怕只有主线程一个执行者，只要用迭代器遍历的同时通过集合方法修改数据，同样触发这个异常。这是Ja va集合框架有意为之的防御性设计——fail-fast机制：宁可中断执行，也不允许返回一个错误或残缺的结果。

从设计哲学上说，fail-fast不是bug，是feature。它直接暴露了代码里的逻辑矛盾：你在遍历时修改集合，本身就违背了“遍历过程应该稳定”这一前提。

更值得警惕的是那种“有时不报错”的情况。它掩盖了数据遗漏，上线后对账偏差、订单丢失、状态冲突都可能由此引发。调试时看不到异常，不代表代码没问题。

那么该怎么识别这个缺陷？判断标准很简单：看删除动作是否发生在for-each循环体内。只要看到list.remove(...)或set.remove(...)出现在for-each的花括号里，就已经踩中红线了——无关乎是否抛出异常，问题的本质在于职责混乱。