Java 数组拷贝实战：System.arraycopy 参数使用与性能优化实战

System.arraycopy不是“写对就能快”的工具，其性能优势仅在数组≥256、基本类型、目标已预分配等条件匹配时释放；参数任一错误即抛异常，小数组（≤16）反不如for循环，且必须严格校验五参数边界。

说System.arraycopy性能好，是对它最大的误解之一。它的快，是有条件的——数组够大、类型对路、目标已分配，几样缺一不可。核心原理是跳过Ja va层的循环和边界检查，直接调用JVM底层的内存搬运指令。但参数只要错一个，运行时直接崩溃；数组太小，反而比普通for循环还慢；用错场景，甚至会拖累整体吞吐。

五参数必须全对齐，越界立刻抛异常

调用格式固定：System.arraycopy(src, srcPos, dest, destPos, length)。五个参数一个都不能少，全部在运行时严格校验：

• src 和 dest 都不能为 null，否则直接抛出 NullPointerException。
• srcPos ≥ 0 且 srcPos + length ≤ src.length，否则抛出 ArrayIndexOutOfBoundsException。
• destPos ≥ 0 且 destPos + length ≤ dest.length，越界同样崩溃。
• length 可为 0（合法且零开销，可用于边界预检）。
• 所有参数必须在调用前手动校验——尤其是当 from/to 来自用户输入或配置文件时，这一步不能省。

什么时候真快？看长度、类型和内存布局

快不是默认状态，是特定组合下的结果：

• 基本类型数组（int[]、byte[] 等）拷贝 ≥ 256 元素时优势明显：JVM 此时有机会启用 SIMD 指令批量搬运。
• 对象数组（String[]、MyBean[]）也快，但只复制引用：不触发 GC 写屏障，适合高吞吐场景。
• 长度 ≤ 16 的数组，for 循环通常更快：JNI 调用开销盖过了搬运收益。
• 目标数组必须已分配且容量充足：arraycopy 不负责 new，传入的 dest 必须是非 null、长度足够的数组。
• 避免跨 cache line 小块搬运：单次 length < 64 字节时 JIT 可能不向量化；小段数据尽量合并再拷。

原地重排不用手写方向判断，靠参数自动保安全

当 src == dest 时，arraycopy 自动按 memmove 语义处理重叠区域，无需 if 分支判断左右移：

• 左移（destPos < srcPos）：如 System.arraycopy(arr, 5, arr, 3, 5)，JVM 正向执行，不会覆盖未读数据。
• 右移（destPos > srcPos）：如 System.arraycopy(arr, 0, arr, 3, 5)，JVM 倒序搬运，先搬高地址再覆盖低地址。
• 边界贴线也安全：System.arraycopy(arr, 7, arr, 6, 3) 把 [7,8,9] 搬到 [6,7,8]，destPos + length == 9，不越界即可。
• 禁止 srcPos == destPos 且 length > 0：这是无效搬运，无意义且浪费。

高频场景必须复用缓冲区，别让 GC 成瓶颈

真正影响吞吐的往往不是拷贝本身，而是频繁分配与回收：

• 网络协议解析、RingBuffer、日志切片等场景，应预分配 byte[] 缓冲池，按 slot 划分，用 arraycopy 精准写入偏移位置。
• 避免循环中 new 小数组：例如每次解析 packet 都 new byte[2048]，会频繁触发 Young GC，停顿明显。
• 固定长度截取可复用 buffer：先 System.arraycopy(src, offset, buffer, 0, actualLen)，再 Arrays.copyOf(buffer, actualLen)。
• 扩容类操作（如 ArrayList）优先用 arraycopy 整块迁移：比逐个 add 或 Stream.collect 更轻量。
• 多线程写同一 dest 数组必须隔离：arraycopy 单次原子，但不保证缓存一致性；推荐各线程独立 buffer，最后合并。