System.arraycopy 更快，因其绕过 Java 运行时约束，一次性参数校验后直接调用内存块操作函数，并获 JIT 专项优化；而手动循环需重复边界检查、类型校验与字节码解释，缓存效率低。
System.arraycopy 快，不是因为它“写了 C 代码”，而是它绕开了 Java 层的运行时约束机制——边界检查、字节码解释、循环控制开销全被剥离，直接交给 JVM 内核调度内存搬运。
底层调用路径完全不同
手动 for 循环拷贝在字节码层面是重复执行 aaload 和 aastore 指令，每次都要：
- 查源数组长度、比对索引是否越界
- 查目标数组长度、再比对一次索引
- 若为引用类型，还要做 null 检查和类型校验（如 Object[] → String[] 会失败）
- JVM 解释执行循环结构：条件判断、跳转、栈帧维护
而 System.arraycopy 是 JNI 入口，JVM 在进入 native 前一次性校验全部参数（源/目标非空、起始索引合法、长度非负、类型兼容），之后直接调用类似 memmove 的内存块操作函数，中间不经过任何 Java 字节码。
JIT 编译器对两者的优化待遇天差地别
for 循环是“通用模式”，JIT 难以确定其语义是否可向量化或内联；而 System.arraycopy 是 JVM “白名单”原子操作，HotSpot 对其做了专项优化：
- 自动内联为紧凑汇编序列（甚至省略函数调用开销）
- 识别连续内存区域后启用 SIMD 指令（如一次搬 16 字节的
movdqu） - 配合 GC 卡表更新策略，减少写屏障开销
- 在 G1/ZGC 下可做更细粒度的并发拷贝调度
内存访问模式决定缓存效率
for 循环中，每次读+写构成两个离散访存动作，容易造成 cache line 反复加载与驱逐；System.arraycopy 则按页对齐、顺序流式读写，完美匹配 CPU 多级缓存预取机制：
- L1 缓存命中率显著更高
- 避免伪共享（false sharing）风险
- 对 byte[] 等基础类型，常逼近硬件 memcpy 极限带宽
实际影响边界的几个关键事实
性能鸿沟不是线性的，取决于三个临界点：
- 数组长度 ：循环可能更快——JVM 启动成本 > 拷贝收益，且小数组易被 JIT 栈上分配优化
- 长度 20–1000：arraycopy 开始稳定胜出，优势随长度增长加速扩大
- 长度 > 10⁵：差距可达 3–5 倍，尤其在吞吐密集型服务中，毫秒级差异会放大为可观的 QPS 提升
不复杂但容易忽略：Arrays.copyOf 就是 arraycopy 的安全封装，带扩容逻辑，日常开发优先用它，而非裸调 arraycopy 或手写循环。
