System.arraycopy的硬件加速依赖JVM（HotSpot C2）在满足参数稳定、类型明确、内存对齐、禁用解释执行等条件后，将其内联为CPU原生指令（如x86的rep movsq/AVX-512、AArch64的ldp/stp/SVE），而非由JNI调用本身驱动。
System.arraycopy 的硬件加速不是“开关一开就来”，而是 JVM（特别是 HotSpot C2 编译器）在满足一系列软硬件约束后，主动将其替换为 CPU 原生指令的过程。它不依赖 JNI 调用本身，而依赖 JIT 编译时的内联与指令选择能力。
哪些 CPU 指令会被实际生成
具体指令取决于架构、数组类型、长度和内存对齐情况，JVM 会自动选最优路径：
-
x86-64：小数组常用
rep movsb/movsw/movsd/movsq；中大数组启用 SSE2（movdqu）、AVX2（vmoVDQA）、甚至 AVX-512（单次搬 64 字节） -
AArch64：倾向成对加载/存储指令（
ldp/stp），SVE 启用时可向量化处理 128–2048 位宽数据块 -
所有平台：若检测到连续对齐内存（如 64 字节边界），会插入硬件预取（
prefetchnta或prfm）提升缓存命中率
触发硬件加速的硬性条件
缺一不可，否则回落至通用 stub（仍比 for 循环快，但未达峰值带宽）：
-
参数稳定可推导：length 建议为编译期常量（如
1024）或热路径中高度稳定的变量；避免泛型包装、桥接方法、反射调用 -
类型明确且兼容：
byte[] → byte[]、int[] → int[]最优；String[] → Object[]可行但需运行时类型检查，略慢一档；int[] → long[]直接失败 -
内存自然对齐：常规
new分配的数组默认按 8/16 字节对齐；若用Unsafe.allocateMemory手动分配，偏移非整数倍对齐会禁用 SIMD -
禁用解释执行：确保关键拷贝逻辑出现在被 JIT 编译的热方法中（可通过
-XX:+PrintCompilation观察）；避免-Xint或-XX:TieredStopAtLevel=1
如何验证是否真正启用硬件加速
不能只看耗时，要确认底层指令是否落地：
- 加 JVM 参数
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis 插件），搜索生成汇编中的rep movsq、vpmovzxbd、ldp等关键词 - 用
jstack -m抓取线程栈，若看到JVM_ArrayCopy或memcpy符号，说明已走 native stub；若看到大量循环展开汇编，则可能未触发 intrinsic - 性能计数器辅助：Linux 下用
perf stat -e instructions,mem_inst_retired.all_stores对比 arraycopy 与 for 循环的 IPC 和访存指令比，高 IPC + 低 store 指令数是硬件加速标志
硬件加速失效的典型陷阱
看似调用了 arraycopy，实则没跑在高速通道上：
- 跨 GC 区域拷贝：G1 Humongous 区→老年代、ZGC 映射页跨域等场景，部分 GC 实现强制降级为逐元素复制（带 write barrier）
- 小数组滥用：长度 ≤ 16 时，JNI 入口开销 + 安全校验 > 向量化收益；此时 JVM 可能用精简汇编而非 SIMD
- 锁内长拷贝：虽指令快，但同步阻塞导致线程停顿；大体积搬运应拆分批次或提前释放锁
-
动态 length + 泛型封装：例如
<t> void copy(T[] a, T[] b)</t>会引入桥接方法，破坏 JIT 内联机会
