system.arraycopy重叠拷贝天然安全，因其jvm在调用前完成全部校验并自动适配拷贝方向：destpos>srcpos时倒序、destpos
System.arraycopy 的内存安全性不靠“额外保护”，而靠 JVM 在调用前就完成全部校验，并在底层自动适配拷贝方向——它本身就是为重叠场景设计的，不是凑巧能用。
重叠拷贝天然安全，靠的是方向自适应
当 src 和 dest 是同一个数组、区间有交集时，JVM 不会报错，而是根据 srcPos 与 destPos 的大小关系 决定搬运顺序：
- destPos > srcPos（目标起始在源起始右边）→ 倒序拷贝（从高索引往低索引），避免未读数据被覆盖
- destPos
- destPos == srcPos → 直接跳过，或做零长度处理
这和 C 的 memmove 行为一致，不是模拟，是同等语义的原生实现。
真正会崩的，从来不是重叠，而是参数非法
所有崩溃都发生在拷贝开始前，JVM 一次性做完全部检查，不给错误数据写入的机会：
- src 或 dest 为 null → NullPointerException
- length 为负 → NegativeArraySizeException
- srcPos、destPos 越界，或 srcPos + length > src.length → ArrayIndexOutOfBoundsException
- 源数组类型无法赋值给目标数组（如 String[] 拷到 Integer[]）→ ArrayStoreException
不用临时数组，也不用手动拆分
有人担心重叠危险，于是先复制到临时数组再搬回——这反而引入两次拷贝+一次内存分配，拖慢性能且无必要：
- System.arraycopy 的重叠处理是 JVM 级保障，比手写循环更可靠
- 手写容易方向写反、边界算错，还失去向量化加速机会
- 只要参数合法，结果一定语义正确；出问题一定是参数错了，不是重叠本身的问题
多线程下唯一要注意的是写共享
单次 arraycopy 调用是原子的，但不提供线程安全保证：
- 多个线程往同一 dest 数组不同区域写，可能因 CPU 缓存不同步导致数据撕裂
- 推荐每个线程操作独立 buffer，最后用一次 arraycopy 合并
- 或采用“新数组 + AtomicReference.lazySet”方式替换引用，避免并发写冲突
