system.arraycopy本身不参与内存分配或回收，只做已有数组间地址级数据搬运；目标数组必须预先存在且容量≥destpos+length，类型须字节级兼容（如int[]→int[]）才能触发memmove或simd指令，大数组（≥256）才显性能优势，原地迁移自动保序但不保证线程安全。
System.arraycopy 本身不参与内存分配或回收，它只做已有数组间的地址级数据搬运——理解这点，是把内存管理策略真正落地的关键。
目标数组必须预先存在且容量刚够
arraycopy 不创建新对象，也不扩容。迁移前必须手动确保 dest 数组长度 ≥ destPos + length。少一个元素就抛 ArrayIndexOutOfBoundsException，没有容错余地。常见做法是复用缓冲区：比如网络收包后，把 packet[headerLen..end] 整块搬进预分配的 byte[65536] 起始位置，避免每次 new 触发 GC。
类型匹配决定是否触发底层 memmove
只有源和目标类型字节级兼容时（如 int[] → int[]、byte[] → byte[]），JVM 才可能跳过 Java 层逻辑，直接调用 memmove 或 SIMD 指令。String[] → Object[] 可行但慢一档；int[] → long[] 会立即报 ArrayStoreException——JVM 不做任何转换，这是硬性语义约束，不是性能调优点。
大数组才释放真实性能优势
- 长度 ≤ 16 时，JNI 调用开销常高于简单 for 循环
- 256 是更稳妥的启用阈值；实测中 ≥ 1024 元素时，向量化效果明显
- length 尽量用编译期可判定常量（如 1024），JIT 更易内联或展开为高效指令
原地迁移自动保序，但不解决并发写冲突
当 src == dest 且区间重叠时（如 RingBuffer 前移未读数据），JVM 自动按 memmove 语义选择正向或倒序搬运，结果安全。但它不提供线程保护：多个线程往同一 dest 数组不同区域写，仍可能因缓存未同步导致撕裂。推荐每个线程操作独立 buffer，最后用一次 arraycopy 合并；或用新数组 + AtomicReference.lazySet 替换引用。
