system.arraycopy是jvm内置本地方法，绕过java层循环与边界检查，比for循环快2–5倍；但其耗时受数组大小、内存带宽、gc等硬件与运行时因素制约，1gb数组复制通常需20–80ms，无法保证毫秒级完成。
system.arraycopy 本身不保证毫秒级完成，能否在毫秒内完成取决于数组大小、jvm状态、内存带宽和gc行为——它只是高效复制的工具，不是性能魔法。
理解 arraycopy 的真实能力
System.arraycopy 是 JVM 内置的本地方法，绕过 Java 层循环和边界检查，比手动 for 循环快 2–5 倍。但它仍是内存拷贝操作：复制 1GB 数组（约 2.5 亿个 int）在主流服务器上通常需 20–80ms，受 CPU 缓存行填充、内存通道带宽限制，不可能“毫秒级”（
常见误判来源：
• 小数组（如
• 没关掉 GC 日志或忽略 STW（Stop-The-World）暂停，把 GC 时间算进复制耗时；
• 在 JMH 测量时未预热、未隔离 JIT 编译干扰。
让大数组迁移真正变快的关键操作
单纯调用 arraycopy 不够，需配合底层协同：
- 避免复制：优先用引用传递或内存映射——若源数组后续不再修改，直接传引用；若数据来自文件，改用 MappedByteBuffer，零拷贝加载；
- 分块 + 并行复制（谨慎使用）——对 >100MB 数组，可按 1–4MB 分块，用 ForkJoinPool 提交任务，但要注意：多线程写同一堆内存可能引发缓存争用，实测提升有限甚至更慢；
- 确保堆外内存对齐与连续性——用 Unsafe 或 DirectByteBuffer 分配对齐内存，减少 TLB miss；arraycopy 对非对齐地址无加速；
- 禁用冗余 GC 干扰——设置 -XX:+UseG1GC -XX:MaxGCPauseMillis=10，并预分配足够堆空间（-Xms = -Xmx），避免复制中触发 Young GC。
正确测量 arraycopy 耗时的方法
微基准测试必须排除噪声：
- 用 JMH（非 System.nanoTime() 简单打点），启用 @Fork(3)、@Warmup(iterations = 5)、@Measurement(iterations = 10)；
- 每次测试前用 Arrays.fill() 预热数组内容，防止 OS 延迟分配物理页；
- 监控 -XX:+PrintGCDetails，确认测试段无 GC 发生；
- 对比 baseline：同样大小数组，用 for 循环复制耗时，验证 arraycopy 加速比是否达预期（通常 2.5–3.5x）。
替代方案：什么情况下不该用 arraycopy
当目标是“迁移”而非“复制”，以下方式更高效：
- 对象数组迁移 → 改用 ArrayList 或 ArrayDeque，利用其内部扩容策略延迟复制；
- 跨进程/网络传输 → 用 Netty 的 CompositeByteBuf 或零拷贝 socket（sendfile/transmitFile）；
- 实时流式处理 → 用 RingBuffer 或 Chronicle Queue，避免全量数组存在内存中；
- 只读场景 → 用 Collections.unmodifiableList 包装原数组，完全免复制。
不复杂但容易忽略：arraycopy 是利器，但它的极限由硬件决定。追求毫秒级响应，重点不在怎么调用它，而在于——能不能不复制。
