浅拷贝与深拷贝区别详解及克隆实例

本文深入剖析了Java中浅拷贝与深拷贝的本质区别与实战陷阱：Object.clone()默认仅执行浅拷贝，导致引用类型字段在原对象与克隆对象间共享内存地址，从而引发“改一个、另一个也变”的典型bug；而真正的深拷贝需手动递归调用各引用字段的clone()方法，或借助序列化/反序列化机制实现对象图的完全隔离。文章不仅厘清了Cloneable接口仅作标记、不提供逻辑的真相，还直击常见误用场景——如final字段、Lombok注解、框架代理对象及不可序列化类型带来的兼容性危机，揭示出“写clone容易，保全嵌套层级正确性极难”的核心痛点，为开发者提供兼具原理深度与落地可行性的克隆方案决策指南。

为什么 clone() 总是改一个，另一个也跟着变？

因为 Object.clone() 默认就是浅拷贝 —— 它只复制对象本身字段的值，对引用类型（比如 Teacher、Money、Address）只拷贝内存地址，不新建对象。所以原始对象和克隆对象共享同一份引用数据。

常见错误现象：
• 修改克隆对象里某个 teacher.name，原对象的 teacher.name 也变了
• person1.money.m = 13.6 后，person2.money.m 变成 13.6 而不是保持 99.99

• 基本类型（int、double 等）和 String 是安全的：改克隆体不影响原对象
• 所有自定义类、数组、集合、包装类以外的引用类型，默认都不安全
• 别指望 super.clone() 自动帮你深拷贝 —— 它连 Cloneable 都不检查，只靠你手动加接口才放行

怎么用 Cloneable 接口写出可用的浅拷贝？

Cloneable 不是工具，它只是一个“许可证”：告诉 JVM “我允许被克隆”，否则调用 clone() 就抛 CloneNotSupportedException。它没方法、不参与逻辑，纯标记接口。

• 必须实现 Cloneable，否则编译不报错但运行必炸
• clone() 方法在 Object 中是 protected，子类必须重写并设为 public
• 返回值要强制转型，因为 super.clone() 返回的是 Object

实操示例：

class Student implements Cloneable {
    private int id;
    private String name;
    private Teacher teacher;

    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone(); // 浅拷贝：teacher 字段仍指向同一实例
    }
}

怎样真正实现深拷贝？两种靠谱路径

深拷贝的本质是：让每个引用字段都指向“新造出来”的对象，而不是复用旧地址。没有银弹，只有两条主流路径，选哪条取决于你的约束条件。

• 手动递归克隆：每个引用字段对应的类也要实现 Cloneable，并在本类 clone() 中显式调用其 clone()
  → 适合结构稳定、可控的 DTO 或内部模型
  → 缺点：字段一多就容易漏写，嵌套深时代码冗长
• 序列化反序列化：把对象写成字节流再读回来，天然生成全新对象图
  → 要求所有涉及类都实现 Serializable
  → 注意：含 transient 字段、静态变量、不可序列化资源（如 Thread、Socket）会丢失或报错

手动深拷贝片段示意：

@Override
public Object clone() throws CloneNotSupportedException {
    Student copy = (Student) super.clone();
    if (this.teacher != null) {
        copy.teacher = (Teacher) this.teacher.clone(); // 假设 Teacher 也实现了 Cloneable
    }
    return copy;
}

哪些情况千万别用 clone()？

不是所有对象都适合走 Cloneable 这条路。有些场景下它反而引入隐蔽风险，甚至根本走不通。

• 类有 final 字段且依赖构造器赋值 → super.clone() 无法绕过 final 限制，会编译失败或字段为默认值
• 父类没实现 Cloneable 或没公开 clone() → 子类重写也白搭，super.clone() 仍抛异常
• 用了 Lombok 的 @Data 或 @AllArgsConstructor → 它不会自动帮你处理引用字段的深拷贝逻辑
• 框架管理的对象（如 Spring Bean、MyBatis 的代理对象）→ 可能被增强、代理，clone() 行为不可控，极易出错

真正麻烦的从来不是“怎么写 clone”，而是“谁来保证所有嵌套层级的 clone 都正确、及时、不漏”。一旦对象图里出现循环引用、第三方类没实现 Cloneable、或某字段是 java.time.LocalDateTime 这种不可变但未实现克隆的类 —— 就得立刻换方案。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~