java数组本身不支持真正的深拷贝，clone()和system.arraycopy均只做浅拷贝；基本类型数组浅拷贝等效深拷贝，对象数组则共享引用，修改元素会影响原数组，深拷贝需手动重建每个对象实例。
Java 数组本身不支持真正的深拷贝，clone() 和 System.arraycopy 都只做浅拷贝。对基本类型数组（如 int[]、byte[]），浅拷贝效果等同于深拷贝；但对对象数组（如 String[]、Person[]），它们复制的是引用，不是对象实例——改 cloned[0].name，original[0].name 也会变。
对象数组的“深拷贝”本质是重建对象图
所谓“数组深拷贝”，真正要解决的不是数组容器本身，而是数组中每个元素所指向的对象是否独立。JVM 层面没有一键深拷贝数组的原生机制，必须额外处理元素层级：
- 若元素是不可变对象（如 String、LocalDateTime），直接用 clone() 或 Arrays.copyOf 就足够安全
- 若元素是可变对象（如 Person、ArrayList），需为每个元素单独创建新实例，并递归处理其内部引用字段
- 数组长度越大、元素越复杂，深拷贝开销越显著，GC 压力同步上升
Clone 机制：简洁但有隐藏陷阱
数组调用 clone() 是 JVM 优化过的内存块复制，速度快、语法干净，但它对对象数组仅复制引用地址：
- 语义上看似“复制了一份”，实则两个数组共享同一组对象实例
- 无需实现 Cloneable 接口，也不抛 CloneNotSupportedException，比普通对象 clone() 更可靠
- 性能约为 System.arraycopy 的 90%，但远高于 for 循环（尤其在大数组场景）
手动复制：可控但需权衡粒度
手动循环本身不等于深拷贝，它只是提供了插入逻辑的入口。是否深、怎么深，全由你控制：
- 小数组（≤4 元素）时，for 循环可能比 clone() 还快，且便于边复制边转换（如过滤 null、类型适配）
- 配合 new Person(src[i].getName(), src[i].getAge()) 可实现逐元素构造，避免共享
- 若元素含嵌套结构（如 Person.address.city），需在循环内继续展开处理，否则仍是浅层隔离
真正可行的深拷贝路径
当确实需要完整隔离对象数组时，应跳出“数组复制”思维，聚焦“对象实例重建”：
- 优先用不可变设计：把 Person 改为 record 或 final 字段 + 构造初始化，复制时只需 new 即可
- 序列化反序列化：Apache Commons Lang 的 SerializationUtils.clone() 能自动穿透整棵树，但要求所有类实现 Serializable，且性能较弱
- 第三方高效库：Kryo、FST 等可绕过反射和 IO 流，速度接近手动，但引入依赖
- 避免过度深拷贝：多数业务场景只需隔离顶层容器，内部对象通过防御性拷贝或只读包装即可满足需求
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
