system.arraycopy 通常比 for 循环快，因其绕开字节码执行路径，一次性参数校验后直接调用底层内存搬运指令（如 memmove 或 simd 汇编），对基本类型逼近 memcpy 极限；但小数组（≤16）、类型不兼容、目标容量不足或跨堆拷贝时会失效甚至更慢。
System.arraycopy 的速度优势来自 JVM 层面的深度优化，但它不是万能加速器——快有前提，慢有原因。
为什么它通常比 for 循环快
它绕开了 Java 字节码执行路径：不解释循环、不重复做索引越界检查、不逐元素校验类型。JVM 在入口一次性完成全部参数合法性验证后，直接调用底层内存搬运指令（如 memmove 或 SIMD 优化汇编），把整块内存当“黑盒”平移。对 int[]、byte[] 等基本类型数组，常逼近硬件 memcpy 带宽极限；对对象数组，也只复制引用地址，不触发构造、finalize 或写屏障开销。
真正决定快慢的关键限制
- 数组长度太小（≤16）时，JNI 调用和安全校验开销可能超过简单赋值，反而更慢
- 源与目标类型必须兼容：int[] 不能拷到 long[]，String[] 拷到 Integer[] 运行时报 ArrayStoreException
- 目标数组必须已存在且容量足够：dest.length ≥ destPos + length，否则立即抛 ArrayIndexOutOfBoundsException
- 跨堆区域（如老年代→新生代）拷贝仍受 GC 写屏障约束，无法跳过
- 多线程并发写同一 dest 数组区域，无内置同步机制，会导致数据撕裂
它做不到的几件事
它不自动扩容，不支持跨类型转换（比如 int[] → double[]），不做深拷贝，也不保证线程安全。所谓“原子性”仅指单次调用内部不可中断，不代表操作对外可见性或并发安全。若需零拷贝加载文件，应改用 MappedByteBuffer；若需类型转换，得走 Stream 或专用工具类——硬套 arraycopy 只会抛异常或得到错误结果。
什么时候该换别的方案
- 只复制子区间且目标数组已存在 → 用 System.arraycopy（最轻量）
- 要扩容+拷贝 → 优先用 Arrays.copyOf（语义清晰，底层仍是 arraycopy）
- 全量克隆且无需控制位置 → 可用 clone()，但注意多维数组只克隆第一层
- 数据来自磁盘或网络 → 考虑 DirectByteBuffer + 内存映射，避免拷贝
- 超大数组（>100MB）且 CPU 核心充足 → 可分块并行，但实测提升有限，需实测验证
