System.arraycopy更快，因其绕过Java运行时冗余检查：一次性参数校验后直接内存块搬运，获JIT内联与SIMD优化；而for循环需重复边界检查、类型校验及字节码开销。

System.arraycopy 通常比手动 for 循环快得多，但这个“快”不是玄学，而是 JVM 在底层做了大量针对性优化的结果。它不是靠“写得更底层”，而是靠“绕开 Java 运行时的冗余检查”。关键在于：什么时候快、快多少、为什么快、以及怎么用才不白费这波优化。

为什么 System.arraycopy 更快？核心在三处剥离

手动 for 循环拷贝每一步都要走完整 Java 层语义：

• 每次 a[i] 都隐式触发一次数组边界检查（源数组长度校验 + 索引比对）
• 每次 b[i] = x 又要再做一次目标数组边界检查 + 类型兼容性校验（比如往 String[] 里塞 Integer 就会失败）
• 循环本身带来跳转、计数、栈帧维护等字节码开销，JIT 难以完全向量化

而 System.arraycopy 的路径完全不同：

• 参数一次性校验：源/目标非空、起始索引合法、长度非负、类型兼容——全在进入 native 前完成
• 之后直接调用类似 memmove 的内存块搬运函数，不经过任何 Java 字节码
• JIT 编译器把它当“白名单原子操作”，可内联、可启用 SIMD 指令（如一次搬 16 字节）、能配合 GC 卡表做写屏障优化

性能差距到底有多大？看数组长度说话

差距不是固定倍数，而是随规模非线性扩大：

• 数组长度 ≤ 4：for 循环可能更快——JVM 启动 arraycopy 的 JNI 开销 > 拷贝收益；小数组还容易被 JIT 栈上分配优化
• 长度 20–1000：arraycopy 开始稳定胜出，优势随长度增长加速明显
• 长度 ≥ 10⁵（十万级）：实测差距常达 3–5 倍；对 byte[] 或 int[]，甚至逼近硬件 memcpy 极限带宽

例如 JDK 17 下拷贝 100 万个 int 元素：

• System.arraycopy：约 0.03–0.05 ms
• 手动 for 循环（已缓存数组引用）：约 0.12–0.18 ms
• 增强 for 循环（for-each）：约 0.25–0.40 ms（额外迭代器开销）

怎么用才真正发挥 arraycopy 的优势？

写错参数或误用场景，反而会让性能反降：

• 目标数组必须预先创建且长度足够，否则抛 IndexOutOfBoundsException 或 ArrayStoreException
• 源与目标类型必须兼容：不能把 String[] 拷到 Integer[]，但可以拷到 Object[]
• 避免“为省事”在循环里反复调用 arraycopy 拷 1 个元素——JNI 调用开销会被放大
• 若 src == dest（自拷贝），arraycopy 自动处理重叠逻辑（类似 memmove），无需手动判断方向
• 不要包装成泛型方法再调用——泛型擦除可能引入桥接方法，破坏 JIT 内联机会

替代方案怎么选？Arrays.copyOf 和 clone()

日常开发中，多数时候不该裸调 System.arraycopy：

• Arrays.copyOf(src, newLength)：底层就是封装了 arraycopy，自动分配新数组，适合扩容+拷贝场景
• arr.clone()：对一维数组也调用 arraycopy，语法最简洁，但仅支持一维，且返回类型是 Object，需强制转型
• 别和 BeanUtils.copyProperties 比——那是对象属性拷贝，和数组内存拷贝不在一个维度