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，但它属于集合的结构性修改操作：
Alibabacloud Sdk Client Initialization For 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 没有这三者的任意一环，所以安全、静默、高效——它只是搬砖的工人，不管工地有没有在施工。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
