System.arraycopy 不触发 fail-fast,因为它是 native 内存拷贝操作,不修改集合结构、不改变 modCount、不与迭代器交互;fail-fast 仅在迭代器校验时发现 modCount 与 expectedModCount 不匹配才抛出异常。

System.arraycopy 本身不触发 fail-fast,因为它根本不是集合操作,也不涉及迭代器或 modCount 校验。
fail-fast 的触发前提是使用迭代器遍历
fail-fast 是 Java 集合(如 ArrayList、HashMap)中 Iterator 的行为机制,核心逻辑是:
- 迭代器初始化时记录当前集合的 modCount 值为 expectedModCount;
- 每次调用
next()或hasNext()前,都会执行checkForComodification(); - 该方法比对
modCount == expectedModCount,不等则抛ConcurrentModificationException。
而 System.arraycopy 是一个底层 native 方法,只负责内存块拷贝,它既不修改集合结构(不增删元素),也不改变 modCount,更不与任何迭代器交互——所以它天然“隐身”于 fail-fast 检测之外。
ArrayList 中批量操作(如 addAll、removeRange)也用 arraycopy,但会主动更新 modCount
虽然 addAll 内部调用了 System.arraycopy,但它属于集合的结构性修改操作:
立即学习“Java免费学习笔记(深入)”;
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 执行前先调用
ensureCapacity,该方法会令modCount++; -
System.arraycopy完成数据复制后,size增加,整个操作被视作一次“合法修改”; - 此时若已有迭代器在运行,其
expectedModCount仍为旧值,下次next()就会因校验失败而抛异常。
换言之:arraycopy 是工具,是否触发 fail-fast 取决于它被谁调用、在什么上下文中调用。
直接操作数组底层数组(elementData)也不会触发 fail-fast
例如手动写:
list.elementData[5] = "new"; // 绕过 add(),不改 size,也不增 modCount
这种操作虽能“偷偷”改数据,但:
- 没调用集合公开方法 → 不触发
modCount++; - 迭代器校验只看
modCount,数值未变 → 不抛异常; - 但会导致数据不一致(比如
size=3却有第 6 个元素),属于未定义行为,应避免。
总结关键点
fail-fast 不是“一动就报错”,而是“迭代器 + 结构修改 + modCount 不匹配”三者同时满足才触发。System.arraycopy 没有这三者的任意一环,所以安全、静默、高效——它只是搬砖的工人,不管工地有没有在施工。

















