System.arraycopy是JVM高度特化的内存搬运原语，非万能函数；其毫秒级性能仅在满足目标数组预分配、类型字节级兼容、长度≥256、参数严格校验等条件下达成，否则可能比for循环更慢且易抛异常。
System.arraycopy 不是“万能拷贝函数”，而是 JVM 内部高度特化的内存搬运原语——它快，但只在你给足条件时才真正快。对超大数组（如百兆级以上 byte[] 或 int[]），它的优势明显；但若忽略生命周期、类型匹配或参数校验，反而比手写 for 循环更慢、更易出错。
目标数组必须提前配齐，且容量刚够
arraycopy 从不分配内存，也不扩容。复制前必须确保：
• dest 数组已存在，且 destPos + length ≤ dest.length；少一个元素就抛 ArrayIndexOutOfBoundsException
• 源数组同理：srcPos + length ≤ src.length
• 不建议用 Arrays.copyOf() 替代——它会额外 new 数组，触发 GC，对超大数组尤其危险
- 正确做法：网络收包后复用固定缓冲区，例如预分配 byte[65536]，每次用 arraycopy 将有效 payload 搬入起始位置
- 错误做法：在循环中反复 new byte[1024*1024] 再 arraycopy，导致频繁 Young GC
类型必须字节级兼容，不隐式转换
它不做任何类型推导或转换，只做内存块平移：
• int[] → int[] ✅
• byte[] → byte[] ✅
• String[] → Object[] ✅（协变允许）
• int[] → long[] ❌ 运行时报 ArrayStoreException
• Integer[] → int[] ❌ 装箱/拆箱不在此路径内，必须手动处理
- 基本类型数组最快：无 GC write barrier，纯内存路径
- 对象数组只拷引用：快，但后续修改对象内容会影响源数组——这是浅拷贝本质，不是 bug
- 避免泛型包装调用：Arrays.asList(...).toArray() 会擦除类型，破坏 JIT 内联机会
大数组才启用，小数据走分支判断
实测阈值明确：
• 长度 ≤ 16：JNI 调用开销常高于简单赋值，for 循环更稳
• 64 是性能拐点，256 是推荐启用下限
• length 最好是编译期常量（如 1024），JIT 更易向量化或启用 SIMD
- 推荐写法：
if (len < 64) { for(...) {...} } else { System.arraycopy(...) } - 避免把 packet.length 这类变量直接传入——JIT 难以优化，可能退化为通用路径
- 对固定结构协议（如头12字节+payload），偏移拷贝可直接写死：System.arraycopy(buf, 12, dst, 0, payloadLen)
原地重排要靠参数控制方向，JVM 自动保序
src == dest 时，是否安全不取决于代码写法，而取决于 srcPos 与 destPos 的大小关系：
• destPos > srcPos（右移）：JVM 自动倒序搬运，防覆盖
• destPos < srcPos（左移）：JVM 自动正向搬运，同样安全
• 例如 RingBuffer 清理头部空闲区：System.arraycopy(buf, readPos, buf, 0, unreadCount)
- 边界合法示例：想把 arr[7..9] 左移 1 位填入 arr[6..8]，写 System.arraycopy(arr, 7, arr, 6, 3) 是安全的（6 + 3 = 9，刚好不越界）
- 危险操作：System.arraycopy(arr, 0, arr, 1, 3) 可能覆盖中间值，除非你明确需要这种行为
- 不要试图用多线程并发写同一 dest 数组不同区域——缓存争用会抵消并行收益，甚至更慢
