Java中System::arraycopy为何性能不及自定义实现？

场景回顾 #

开发者在实现Java数组深拷贝时，发现自定义的dumbCopy方法比System::arraycopy性能高出1.8倍；随后又实现了完全模仿System::arraycopy行为与错误处理逻辑的MyArrayCopy类，经JMH基准测试得出结论：

• 数组规模越小，两者性能差异越大
• 数组规模越大，差异越小，大数组场景下性能基本接近

核心疑问 #

作为标注了@IntrinsicCandidate的手写汇编实现，System.arraycopy为什么没有显著优于高级Java代码实现？

关键原因分析 #

1. 内在方法的调用边界开销 #

System.arraycopy虽然是内在方法，但从Java代码调用它时存在固定的开销：

• 需要完成Java栈与本地栈的上下文切换
• 内置的参数合法性校验（数组类型匹配、索引越界等）在小数组场景下，占比远高于拷贝操作本身
• 这种固定开销在小数据量时会被放大，导致整体性能不如纯Java实现

2. JIT编译器的极致优化 #

现代JVM的JIT（如HotSpot C2）对纯Java代码的优化能力极强：

• 针对数组拷贝循环，会自动做循环展开、SIMD向量化优化（利用CPU指令一次拷贝多个元素）
• 简单的自定义拷贝方法会被JIT直接内联到调用处，消除方法调用开销
• 相比之下，System.arraycopy作为内在方法，JVM可优化的空间有限，小数据量下无法抵消调用带来的额外成本

3. 规范级错误处理的额外成本 #

System.arraycopy严格遵循Java规范的错误处理逻辑：

• 必须检查源数组与目标数组的类型兼容性
• 必须校验起始索引、拷贝长度的合法性，抛出对应异常
• 自定义实现如果是针对特定场景编写（比如已知数组类型匹配、索引合法），可以省略或提前处理这些检查，减少分支判断开销

4. 大数组场景的性能收敛 #

当数组规模足够大时，拷贝操作的CPU时间占比会远超过调用和校验开销：

• 此时System.arraycopy的手写汇编实现优势开始体现，能充分利用CPU内存带宽与缓存特性
• JIT优化后的Java循环也能通过向量化达到接近的效率，两者的差异被核心拷贝操作稀释，最终性能趋于接近

内容的提问来源于stack exchange，提问作者Munya Murape