arrays.copyof 是对 system.arraycopy 的封装，先分配新数组再调用 native 拷贝，支持默认值填充；二者底层共享 jvm 优化，小数组可能展开为赋值指令，基本类型常优化为 cpu 块拷贝，均只做浅拷贝且不处理泛型擦除。
Arrays.copyOf 内部依赖 System.arraycopy
Arrays.copyOf 不是独立实现的拷贝逻辑，它在源码层面明确调用 System.arraycopy。以 JDK 中 int[] 的重载为例，其核心逻辑是：
- 先 new 一个指定长度的新数组
- 再用 System.arraycopy 将原数组从索引 0 开始、最多复制 min(original.length, newLength) 个元素过去
- 若 newLength 大于原数组长度，剩余位置自动填充默认值（如 0、null、false）
这说明 Arrays.copyOf 是对 System.arraycopy 的一层封装，不是替代，而是“自动分配 + arraycopy”的组合操作。
两者共享同一底层优化机制
System.arraycopy 是 native 方法，由 JVM 直接映射到高效内存操作（如 memmove 或 SIMD 指令）。而 Arrays.copyOf 虽在 Java 层调用它，但 JIT 编译器在高频使用时会进一步内联并优化整条路径——最终生成的机器码与直接写 System.arraycopy 几乎一致。
- 小数组（如长度 ≤ 4）可能被展开为独立赋值指令，跳过调用开销
- 基本类型数组常被优化为 CPU 级别块拷贝
- 对象数组仍为逐引用复制，不触发深拷贝
行为等效性可实证验证
尽管调用方式不同，二者在多数场景下表现一致：
- 吞吐量测试中，Arrays.copyOf 与手动 System.arraycopy 的拷贝速度基本无差异
- 开启 -XX:+PrintAssembly 可观察到 JIT 编译后汇编指令高度重合
- 在 System.arraycopy 上设断点，再调 Arrays.copyOf，经常能命中——证明 JIT 已将其替换为该 native 入口
都只做浅拷贝，且不处理泛型类型擦除
它们复制的只是数组容器中的值：对基本类型是数值本身，对引用类型是地址副本。这意味着：
- 修改新数组里的对象字段，会影响原数组对应位置的对象
- Arrays.copyOf(T[], int) 返回的是 Object[]，必须显式传入 Class 参数（如 String[].class）才能得到正确子类型数组
- System.arraycopy 对类型兼容性仅在运行时检查（ArrayStoreException），编译期不校验
