「Java 进阶之路」系列 Day25写在前面“遍历集合的时候不能直接调用集合的remove方法”这条经验大家都知道但问一句为什么会报错、报的又是什么异常很多人只记得一个笼统的印象。这篇把Iterator和fail-fast机制背后的modCount计数器讲清楚顺便说说这套机制到底能不能完全依赖。一、是什么fail-fast 是一种尽早报错的检测机制ArrayList、HashMap这些集合内部都维护着一个modCount字段记录这个集合被结构性修改增加或删除元素单纯改值不算过多少次。Iterator在创建的那一刻会把当时的modCount记下来存成自己的expectedModCount之后每调用一次next()都会检查一下当前的modCount是不是还等于我当初记下来的那个值不相等就说明集合在遍历过程中被别的地方动过手脚直接抛出ConcurrentModificationException——这就是fail-fast快速失败的含义与其让程序继续在一个被意外修改过的集合上跑下去、产生更难排查的诡异结果不如第一时间报错让问题尽早暴露。二、为什么会报错一次典型的踩坑复现ListIntegerlistnewArrayList(List.of(1,2,3,4,5));for(Integeri:list){if(i3){list.remove(i);// 直接调用集合自身的remove方法}}// 抛出ConcurrentModificationException创建Iterator时记录expectedModCount等于当前modCount遍历过程中调用集合自身的remove方法集合内部modCount自增Iterator完全不知道modCount已经变了下一次调用next时检查modCount是否还等于expectedModCount不相等 抛出ConcurrentModificationException问题就出在list.remove(i)这一步for-each语法糖底层就是用Iterator实现的但list.remove(i)调用的是ArrayList自己的remove方法不是Iterator的remove方法。ArrayList的remove执行完之后modCount自增了但Iterator手里那份expectedModCount完全不知情、还停留在旧值——下一次Iterator调用next()推进遍历时一检查发现两者对不上立刻抛出异常。正确的做法是用Iterator自己的remove()方法IteratorIntegeritlist.iterator();while(it.hasNext()){Integeriit.next();if(i3){it.remove();// 用Iterator自己的remove方法}}Iterator.remove()内部在删除元素的同时会同步把expectedModCount也更新成最新的modCount两者始终保持一致自然不会触发检测。这也是为什么遍历删除要用Iterator的remove这条经验背后真正的原理——不是Iterator有什么特殊权限而是它顺手帮你把这两个计数器的值重新对齐了。三、怎么用两个容易被混淆的相关陷阱陷阱一用普通下标 for 循环删除元素不报错但结果不对ListIntegerlistnewArrayList(List.of(1,2,3,4,5));for(inti0;ilist.size();i){if(list.get(i)3){list.remove(i);// 不会抛异常但结果可能不符合预期}}这种写法不会抛ConcurrentModificationException因为压根没用Iterator但如果删除的元素后面还有连续需要删除的元素会因为删除后所有元素前移、下标却继续往后走而漏检查一个元素——这和fail-fast是两个完全不同的问题只是经常被放在一起讨论写代码时要分清楚用Iterator遍历删除报的是fail-fast异常用下标遍历删除出的是逻辑漏删的bug两者的成因完全不一样。陷阱二fail-fast 只是尽力检测不是100%保证JDK官方文档里对这套机制有一句关键说明modCount的检查本身不是同步的多线程场景下即使检测机制生效了也不能保证一定能捕获到并发修改反过来某些边界情况下即使真的发生了并发修改也可能因为时机凑巧而没有触发检测、蒙混过关。fail-fast只是一种尽最大努力去暴露问题的调试辅助手段不能把它当成一种可以依赖的并发控制机制去设计代码——真正需要多线程安全遍历的场景应该用Day08讲过的CopyOnWriteArrayList遍历用的是创建时的数组快照天生不会抛这个异常属于fail-safe设计或者ConcurrentHashMap这类专门为并发设计的容器。四、面试追问Q1什么是 fail-fast 机制它是怎么实现的fail-fast是集合类在遍历过程中检测到被意外结构性修改时第一时间抛出ConcurrentModificationException的一种保护机制。实现原理是集合内部维护一个modCount字段记录被修改的次数Iterator创建时记下当时的modCount作为expectedModCount之后每次调用next()都会比较两者是否相等不相等就说明遍历期间集合结构被改动过直接抛出异常。Q2为什么在 for-each 循环里直接调用集合的 remove 方法会抛异常用 Iterator 的 remove 方法就不会for-each底层是用Iterator实现遍历的但直接调用集合自身的remove方法只会让集合内部的modCount自增Iterator手里记录的expectedModCount并不知情两者变得不一致下次调用next()检测到不一致就会抛异常。Iterator自己的remove()方法在删除元素的同时会同步更新expectedModCount让两者始终保持一致所以不会触发这个检测。Q3用普通下标 for 循环遍历删除元素会抛 ConcurrentModificationException 吗不会因为这种写法完全没有用到Iteratorfail-fast检测机制根本没有介入。但这种写法有另一个问题删除元素后集合会整体前移而下标却继续往后走如果有连续多个需要删除的元素会因为下标错位漏掉其中一部分该删除的元素这是一个逻辑正确性问题和fail-fast异常是两回事。Q4fail-fast 机制能不能保证百分之百检测到并发修改不能。JDK官方文档明确说明modCount的检查本身不是同步的多线程环境下既可能因为时机原因没有检测到真实发生的并发修改也不能保证在所有场景下都表现一致。fail-fast只是一种尽力而为的调试辅助手段不能当作可靠的并发控制机制来设计代码逻辑。Q5如果需要在多线程环境下安全地遍历一个集合应该怎么做不应该依赖普通集合的fail-fast机制而应该使用专门为并发场景设计的容器比如CopyOnWriteArrayList——它的迭代器遍历的是创建时刻的数组快照遍历期间即使有其他线程在修改原集合也不会抛异常fail-safe设计或者使用ConcurrentHashMap这类内部有精细同步机制的并发容器具体选择取决于业务场景的读写比例和一致性要求。下一篇预告Day26 讲泛型的本质——类型擦除到底擦掉了什么为什么ListString和ListInteger在运行时其实是同一个Class对象这是模块三集合框架的收官篇。