system.arraycopy处理大数组性能非线性，受内存带宽、cpu缓存行对齐、gc卡表开销及jvm向量化能力四大硬约束限制；1gb byte[]复制通常需20–80ms，拐点在64kb、1mb–100mb、＞500mb三阶段，超200mb高频迁移应转向零拷贝方案。
System.arraycopy 处理大数组的性能不是线性增长，而是受硬件与 JVM 运行时状态共同制约——它快，但有明确的物理边界。
真正影响耗时的四大硬约束
复制 1GB byte[] 在主流服务器上通常需 20–80ms，这个区间背后是四个不可绕过的底层限制：
- 内存带宽瓶颈：DDR4-3200 理论带宽约 25 GB/s，但实际 memcpy 类操作常只能跑出 8–12 GB/s；arraycopy 接近该极限，再快就撞墙
- CPU 缓存行填充效率：每次搬运若未对齐（如起始地址 mod 64 ≠ 0），会触发额外 cache line 拆分与填充，实测非对齐拷贝比对齐慢 15–30%
- GC 卡表写屏障开销：目标数组在年轻代时，每个写入元素都触发卡表更新；若 dst 分配在老年代且已预热，则几乎无屏障成本
- JVM 内联与向量化能力：JDK 17+ 在满足条件（数组长度 ≥ 1024、类型为 byte/int/long、地址对齐）时自动启用 AVX-512 指令，单次搬 64 字节；否则回落至 SSE 或纯 movsq
何时开始“明显变慢”？看三个临界点
性能拐点不取决于绝对大小，而由运行环境决定：
- ≤ 64KB：L1/L2 缓存全容纳，耗时稳定在 0.01–0.03ms，JNI 调用开销占比高，小到一定程度反而不如直接赋值
- 1MB – 100MB：进入内存带宽主导区，耗时大致与长度成正比，每 10MB 增加约 0.3–0.6ms（依 CPU 通道数与 DDR 频率浮动）
- ＞500MB：TLB miss 显著上升，尤其在 4KB 页面粒度下频繁换页；若未启用大页（-XX:+UseLargePages），延迟跳升 2–3 倍
避免踩坑的关键控制项
很多“慢”不是 arraycopy 本身的问题，而是调用方式或环境配置失当：
- 目标数组必须提前分配且长度充足——动态扩容或 length 不足会导致异常或截断，重试成本远高于一次预分配
- 不要跨代复制：从老年代 src 拷到年轻代 dst 容易触发 Minor GC；建议 dst 也分配在老年代（如用 -XX:PretenureSizeThreshold 控制）
- 禁用 -Xint（解释执行模式），确保 JIT 编译器介入；C2 编译后 arraycopy 才具备向量化能力
- 避免在 CMS GC 下使用——其并发模式无法有效配合 arraycopy 的写屏障优化；G1 或 ZGC 更适配
替代思路：什么时候该放弃复制？
当数组持续大于 200MB 且迁移频次高时，复制本身就成了瓶颈。此时应转向语义等价但零拷贝的方案：
- 用 MappedByteBuffer 直接映射文件，数据加载即完成“逻辑迁移”，无需搬运
- 改用 DirectByteBuffer + Unsafe.copyMemory 绕过堆内存，但需自行管理生命周期与平台兼容性
- 设计为引用传递：若源数组后续只读，直接共享引用，用 volatile 或 final 保证可见性
