最近在给一个老项目做参数快照功能需求很简单把一个订单对象复制一份后面的操作随便改不能影响原始数据。我下意识写了Order copy original;结果测试一跑原始订单的价格也被改了。当时第一反应是“这怎么可能”后来才意识到我一直没把Java里的clone这件事真正搞清楚。标题里那个“sallow copy”拼写其实是错的正确是“shallow copy”不过不影响理解。很多人写博客或者笔记都这么记说明大家一开始都是懵的。Java的拷贝不是“赋值”也不是“复制一下”这么简单浅拷贝和深拷贝的区别说小了是API调用姿势问题说大了能直接影响线上数据安全。这篇就把clone、浅拷贝、深拷贝从原理到实战完整拆一遍适合刚学Java SE、或者写了两三年代码但一直没认真研究过对象拷贝的同行。1. 先分清三件事赋值、拷贝、克隆1.1 直接赋值真的只是“多了一个名字”Java里的对象变量保存的是引用reference或者说指针。Order copy original;这一行执行完后栈上多了一个变量copy但它指向的堆内存还是同一个Order对象。打个比方你有一套房房产证上写了你名字然后又给这张证复印了一份复印件放桌上。复印件只是证明“这套房是你的”它不代表你又多了一套房。你拿复印件去改装修改动的是原来的房子不是某个新房。这就是为什么要专门学习拷贝只要你在做对象传递、缓存、快照、事务回滚这类场景赋值操作几乎是必然踩坑的点。很多时候线上问题查了半天最终定位到“某个下游服务把一个共享对象给改了”根源就是前面有人用了赋值而不是克隆。1.2 为什么Object.clone()是protected的如果你写过implements Cloneable一定遇到过这个报错clone() has protected access in Object很多新手在这里就直接卡住了。甚至有人因此觉得“Java的clone就是个废柴API”其实不是废柴是故意设计的。Object类是所有类的父类如果clone()是public那么世界上任何一个对象都能被无条件克隆。这会造成什么后果你的类里可能持有数据库连接、文件句柄、线程池等“不能被随随便便复制”的资源如果克隆是公开的、霸王硬上弓式的这些资源会被复制成两份重复释放、重复提交整个系统直接乱套。所以Java的设计哲学是类自己决定是否允许克隆。Cloneable接口本身是个标记接口marker interface里面没有任何方法它的作用就是告诉JVM和开发者“这个类允许被克隆”。真正做克隆动作的clone()方法继承自Object被protected修饰意味着只有本类和子类能调用。你首先要implements Cloneable然后在自己的类里重写clone()并且在重写方法里调用super.clone()外部才能通过你的公开方法拿到克隆体。我早年刚学的时候一直没搞懂为什么implements Cloneable这么空的一个接口就能让super.clone()魔法般地生成一个对象后来查了JDK源码才明白Object.clone()是一个native方法由JVM底层直接实现它做的事情是为当前对象分配一块同样大小的内存然后把这块内存中的所有二进制位逐位复制到新内存中。对于基本类型字段值直接复制对于引用类型字段复制的只是引用地址。这个“逐位复制”的过程决定了浅拷贝的一切行为。1.3 一切拷贝的起点一个最简单的克隆例子在讲浅拷贝和深拷贝之前先写一个最基础的克隆代码public class Student implements Cloneable { private String name; private int age; public Student(String name, int age) { this.name name; this.age age; } Override protected Object clone() throws CloneNotSupportedException { return super.clone(); } // getter/setter 省略 }调用端Student s1 new Student(小明, 18); Student s2 (Student) s1.clone(); System.out.println(s1 s2); // false说明确实创建了新对象 System.out.println(s1.equals(s2)); // false默认equals比较的是引用 System.out.println(s1.getName() s2.getName()); // trueString引用被复制了比较为false说明克隆确实产生了一个新对象堆内存地址不同。但是两个对象的name字段指向同一个String对象——这里就是浅拷贝的典型特征对象本身是新的对象内部的引用字段依然是共享的。注意String是不可变类所以即便两个对象共享同一个String引用也不会出现“改了一个、另一个跟着变”的问题。这会给初学者造成一种错觉觉得浅拷贝也没啥问题。等到字段变成List、Map、自定义对象时问题就来了。2. 浅拷贝一份新外壳里面还是同一批东西2.1 Object.clone()的执行细节比你想的更有意思很多人以为super.clone()是通过“构造一个新对象再逐个字段赋值”来实现的这是最大的误解。如果是通过构造器实现的那么克隆一个对象就必须执行构造器可能触发大量业务逻辑比如幂等号生成、时间戳更新、统计计数这显然不是克隆该有的语义。Object.clone()不走构造函数它是内存级拷贝。JVM先判断当前对象所属的类是否实现了Cloneable没实现直接抛CloneNotSupportedException。然后按对象占用内存大小分配新的内存区域再用底层指令把旧对象内存的二进制数据整体搬过去。这意味着基本类型字段int、long、boolean、double等被完整复制属于新对象自己的值。引用类型字段只复制了引用地址新旧对象的引用字段仍然指向堆上的同一个对象。构造函数不会执行初始化块不会执行前后两个对象的状态完全一致除了内存地址。因为没有走构造器如果你的类在构造器里做过防御性操作比如把传入的List包装成不可变集合克隆出来的对象会绕过这些防御直接裸奔。来看一段验证代码public class Address { private String city; public Address(String city) { this.city city; } public String getCity() { return city; } public void setCity(String city) { this.city city; } }public class Person implements Cloneable { private String name; private int age; private Address address; public Person(String name, int age, Address address) { this.name name; this.age age; this.address address; } Override protected Person clone() throws CloneNotSupportedException { return (Person) super.clone(); } // getter/setter 省略 }测试Address addr new Address(上海); Person p1 new Person(张三, 30, addr); Person p2 p1.clone(); System.out.println(p1 p2); // false System.out.println(p1.getAddress() p2.getAddress()); // true地址引用相同 p2.getAddress().setCity(北京); System.out.println(p1.getAddress().getCity()); // 输出北京。p1的城市也跟着变了这个例子已经能说明问题的严重性你以为克隆了一份完整数据结果只换了外壳内部的家当还是同一份。修改克隆体的地址原对象立刻被污染。2.2 引用类型和基本类型在浅拷贝里的不同命运很多人分不清“引用被复制”和“对象被复制”的区别我习惯用一个仓库类比浅拷贝相当于给仓库配了一把相同钥匙新仓库门牌号变了但仓库里的货物一动不动。你通过新钥匙进仓库搬走一箱货原来的仓库主人去清点货时发现货也少了。具体到Java对象就是字段类型浅拷贝后的行为示例基本类型值完全复制互不影响int age改克隆体不影响原对象String引用复制但不可变改不了内容String name相对安全数组数组对象引用复制元素共享int[] arr克隆体和原对象的arr是同一个数组容器List/Map/Set容器对象引用复制容器内元素共享ListStudent两个对象持有同一个List自定义引用类型引用地址复制指向同一个堆对象Address改动会互相影响2.3 实用取向浅拷贝在什么时候够用很多人一听到浅拷贝的问题就风声鹤唳觉得浅拷贝是万恶之源。其实不是浅拷贝在很多场景下是完全正确的选择强行深拷贝反而会造成性能浪费和结构性麻烦。什么时候可以使用浅拷贝对象只有基本类型字段。比如一个纯数值计算的对象int、long、double一堆浅拷贝后所有数据都是独立的。引用字段是不可变对象。String、Integer、BigDecimal、LocalDate这类不可变类共享引用不会出问题因为没有人能“修改”它们。唯一需要小心的是不要“重新赋值”指向别处。明确需要共享内部状态。比如多个视图对象共享同一个配置中心的数据改动一处、处处生效这种设计上就需要引用共享。要注意的是“默认可以被接受”和“安全”是两回事我在项目里定的规矩是除非你能明确说出“这里共享引用为什么没问题”否则一律用深拷贝。因为浅拷贝的坑往往不是当下暴露的而是在代码被改了几轮之后才炸的。3. 深拷贝连内部对象一起搬进新家3.1 方式一手动递归克隆最原教旨主义也最可控既然浅拷贝的问题是引用字段共享那思路就很直接引用字段也逐个克隆。Developer有意识地在clone()方法里把每个引用字段都调用一次clone()就得到了深拷贝。public class Person implements Cloneable { private String name; private int age; private Address address; private ListOrder orders; Override protected Person clone() throws CloneNotSupportedException { Person clone (Person) super.clone(); // 引用类型字段逐个克隆 clone.address this.address.clone(); // 容器类特殊处理新容器 内部元素逐个克隆 clone.orders new ArrayList(this.orders.size()); for (Order order : this.orders) { clone.orders.add(order.clone()); } return clone; } }这种方式的优点无可替代代码写出来行为就是所见即所得。每一层需要克隆哪些字段、哪些字段保持共享完全由开发者自己控制。但缺点也很明显你必须在类的内部实现Cloneable和clone()并且类层级越深代码越啰嗦。一旦对象图里有循环引用A引BB又引A手动写递归逻辑容易写出死循环或栈溢出。每个新类都要写一遍套路化代码改字段时容易漏。实际项目里手动递归克隆通常用在“结构稳定、字段不多、性能要求高”的核心实体上。每次改字段review代码时都会专门去看克隆逻辑有没有漏新字段。3.2 方式二利用序列化实现深拷贝省心但要付代价Java对象只要实现了Serializable接口就可以通过“先序列化成字节流再反序列化成新对象”的方式实现深拷贝。public class Person implements Serializable { private static final long serialVersionUID 1L; // 字段... } public static T T deepCopyViaSerialization(T obj) throws Exception { ByteArrayOutputStream bos new ByteArrayOutputStream(); ObjectOutputStream oos new ObjectOutputStream(bos); oos.writeObject(obj); oos.flush(); ObjectInputStream ois new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray())); SuppressWarnings(unchecked) T copy (T) ois.readObject(); return copy; }这段代码的原理是ObjectOutputStream把对象树完整写入字节流ObjectInputStream再从字节流重建整个对象图。因为对象树里的每一个对象都被完整写入反序列化时自然会重新创建全部内部对象所以达到深拷贝效果。我在项目中实测下来这个方式的“坑”主要是这几条对象的每一个成员字段所属的类都必须实现Serializable。只要对象图里有一个类没实现运行时就抛NotSerializableException。那种“明明序列化成功了clone的功能页面却跑到一半炸掉”的情况多半是某个内部类没实现接口。transient字段不会被序列化反序列化后是默认值。如果你有一个临时缓存字段是transient深拷贝之后它就丢了要小心。static字段不进对象序列化反序列化后仍然指向当前类的静态变量。serialVersionUID不一致会导致反序列化失败。同一个类的不同版本之间如果这个ID没写好拷贝时会抛InvalidClassException。序列化的性能比浅拷贝慢一两个数量级因为它涉及IO流的读写、类型检查、反射等操作。但如果对象结构复杂、嵌套层级深写出来的代码量远远小于手动递归可维护性好很多。遇到那些“字段特别多、嵌套特别深、又改来改去”的老项目我现在的习惯就是序列化深拷贝因为它不用每次加字段都去改克隆逻辑加字段只要实现Serializable就完事了。3.3 方式三通过JSON序列化做深拷贝最无脑的兜底方案还有一种经常被拿来救急的思路先把对象转成JSON字符串再从JSON字符串解析回一个全新的对象。String json userService.serializeToJson(person); Person copy jsonService.parseFromJson(json, Person.class);这套方案的好处不要求原类实现Serializable或Cloneable只要求它有合适的无参构造器和getter/setter或者能通过反射处理。对“外部依赖的对象”特别好用比如某个库返回的对象没有实现任何克隆相关接口你想拷贝一份手动复制又太麻烦转一次JSON就拿到了新对象。代码几乎不需要维护加字段、减字段都不影响。但受限也很明显JSON序列化不会保留对象里的循环引用结构。一旦两个对象互相引用转JSON会直接抛异常或把结构折平。transient字段、静态字段、非公开字段、没有默认构造器的类都可能被JSON库忽略。效率比Java原生序列化更低一次深拷贝要经历对象到字符串、字符串到新对象两次完整的序列化解析。强依赖第三方库的序列化配置碰到字段名改动、日期格式配置坑也很多。所以在我的团队里JSON深拷贝只作为“应急兜底”使用不给它常驻主链路。它的定位是当别的深拷贝手段都因为约束太多搞不定时用它是复杂度最低的解法。3.4 三种深拷贝方式对比选型不必过度纠结对比维度手动递归克隆Java序列化JSON序列化是否需要改类定义必须实现Cloneable必须实现Serializable一般不需要靠配置性能高纯内存复制 手动赋值中IO流 反射低字符串转换代码维护量高加字段时要同步改低加字段自动生效低循环引用支持需要专门处理原生支持通常不支持对字段的约束只处理明确代码的字段transient/static会丢失依赖序列化库配置适配外部类对象难难容易我的建议很简单对象字段少、层级浅想有完全控制权用手动递归。对象是内部系统自己的实体字段多、层级深用序列化。有第三方类没法改或者突然急用一次用JSON。不用在一个场景里强行追求“最优解”能解决问题、代码可维护、性能可接受就是好方案。4. 深拷贝实战中撞过的坑一次完整的排查复盘4.1 场景复现备份数据莫名被篡改某次在做一个“价格备份”功能时需求是从数据库读出一个价格配置对象备份一份用于比较后续运行过程中可能会修改原对象但备份对象必须保持不动。我的第一版代码PriceConfig backup (PriceConfig) config.clone();模拟测试的时候业务逻辑把config系列里的某个地区价格改了然后去比较backup发现backup也变了。那一刻我意识到clone()是浅拷贝但真正让我头疼的不是浅拷贝本身而是这个PriceConfig有几层嵌套public class PriceConfig implements Cloneable { private String configName; // String private BigDecimal basePrice; // BigDecimal private ListAreaPrice areaPrices; // 自定义类型集合 private MapString, Rule rules; // 自定义类型MAP }几个字段里configName是StringbasePrice是BigDecimal都不可变浅拷贝不会出问题。问题就出在areaPrices和rules上它们是容器容器本身引用被复制且容器里的自定义对象也是共享的。所以我改了原对象的某个AreaPrice备份对象里看到的也是同一个改过的对象。4.2 排查过程从猜想到逐层验证我先写了个最小复现测试确认areaPrices这个容器在clone后是不是同一个引用System.out.println(backup.getAreaPrices() config.getAreaPrices()); // true输出是true果然连容器本身都是同一份。然后我改成“容器也复制一份”在clone()里写this.areaPrices new ArrayList(this.areaPrices);以为这就算深拷贝了。结果测试一跑发现backup.getAreaPrices().get(0)和config.getAreaPrices().get(0)还是同一个对象。因为new ArrayList(collection)只是把集合的引用都放进一个新容器容器是新容器但里面的元素还是原来那一批。这一步暴露了新手在深拷贝时会犯的第二个经典错误只复制了容器没有复制容器里的元素。4.3 正确的深拷贝写法集合也逐层处理最后我把PriceConfig的clone改成了这样Override protected PriceConfig clone() throws CloneNotSupportedException { PriceConfig clone (PriceConfig) super.clone(); clone.basePrice this.basePrice; // BigDecimal不可变引用共享是安全的 // List新容器 元素逐个克隆 if (this.areaPrices ! null) { clone.areaPrices new ArrayList(this.areaPrices.size()); for (AreaPrice areaPrice : this.areaPrices) { clone.areaPrices.add(areaPrice.clone()); } } // Map新Map key/value逐个处理 if (this.rules ! null) { clone.rules new HashMap(); for (Map.EntryString, Rule entry : this.rules.entrySet()) { clone.rules.put(entry.getKey(), entry.getValue().clone()); } } return clone; }这里每个元素都需要支持clone()所以AreaPrice和Rule也都实现了Cloneable接口并重写了自己的clone()。如果这两个类内部还有嵌套引用类型它们的clone()也要继续深拷贝。4.4 排查看似解决了但同类型问题往往换个地方再犯修完之后复盘发现这件小事牵涉出一个更大的教训排查深拷贝问题时不要只看最外层类有没有重写clone()要从根上梳理整个对象图。我后来把“对象图里有哪些引用类型字段”做成了一张表圈出每一层需要处理的位置层级类名引用类型字段处理方式1PriceConfigListAreaPrice新建List 元素clone1PriceConfigMapString, Rule新建Map value clone2AreaPriceListString regionNames新建ListString不可变元素不深拷2RuleCategory category继续调用categor的clone用了表格之后每个字段“需要深层克隆还是可以直接共享”一目了然漏字段的概率低了很多。5. 序列化深拷贝里的另外几个关键约束5.1 transient字段静默丢失的一等公民序列化深拷贝常用但有一个容易被忽略的字段修饰符transient。标记为transient的字段不会参与序列化反序列化后会被设成JVM默认值引用类型为null基本类型为0或false。我踩过一次实打实的坑某个对象有一个transient ListString extraInfo是在构造函数里被初始化的正常情况下永远不为空。用序列化方式做深拷贝后extraInfo直接变成null后续代码执行copy.getExtraInfo().size()就空指针了。排查了很久才发现元凶是transient。所以如果你的对象里有transient字段并且这个字段对业务逻辑有意义用序列化做深拷贝之前必须想清楚这个字段要不要拷贝如果也要拷贝就得单独处理不能依赖序列化自动完成。5.2 serialVersionUID版本不一致直接失效Java序列化要求类有稳定的serialVersionUID。如果类没有显式声明JVM会根据类的结构自动计算一个。这里的问题是只要类的字段、方法签名有任何变化自动计算出的serialVersionUID就会变。当你把一个对象序列化后存起来后来类加了字段再用旧字节流反序列化时就会报InvalidClassException因为序列化时的类版本和当前类版本不一致。这个问题在做深拷贝时没那么明显——因为序列化和反序列化通常在同一进程、使用同一个类定义——但如果你的系统里存在跨服务、跨进程、跨JVM的拷贝需求serialVersionUID的坑就非常现实。最佳实践是每个实现了Serializable的类都显式声明这个ID并固定在某个值private static final long serialVersionUID 1L;这样无论类内部怎么加字段新旧版本之间也能保持兼容新字段会被赋予默认值序列化操作不会轻易失效。5.3 枚举和单例对象在序列化面前的自毁行为枚举类型在Java里有一套特殊处理反序列化时不会通过构造器创建新对象而是通过枚举名直接查找现有的枚举常量。所以枚举在序列化深拷贝里是安全的——序列化前后的枚举是同一个对象不会复制出第二个实例。单例类就不一样了。如果你用序列化方式去深拷贝一个单例对象反序列化时会创建一个全新的实例单例的约束被绕过系统中出现两个“单例”状态还可能分叉。这是深拷贝在特殊设计模式面前需要格外小心的点。还有一类对象千万别深拷贝持有文件句柄、数据库连接、Socket等的对象。这些资源无法被真正“复制”强行序列化或克隆会造成连接泄漏和资源回收混乱。碰到这类对象要么让克隆保持引用共享要么封死克隆路径。5.4 循环引用手写深拷贝时的栈溢出危机对象图里存在循环引用A引用BB引用A时手动递归深拷贝如果不做“已访问对象”的标记递归就会无限进行下去最终抛出StackOverflowError。序列化方案因为内部有对象图记录机制能正确处理循环引用这也是它在复杂对象图面前更省心的原因之一。JSON方案则通常不支持循环引用转换时会直接抛异常或丢失一边的引用关系。如果项目里循环引用比较常见手动深拷贝时要用一个IdentityHashMap记录已经克隆过的对象private MapObject, Object cloneCache new IdentityHashMap(); public Object deepClone(Object obj) { if (cloneCache.containsKey(obj)) { return cloneCache.get(obj); } // 创建克隆体并放缓存再去克隆引用字段 }这个技巧在复杂对象图里很管用能避免重复克隆同一个对象也能斩断循环引用的死结。6. 到底什么场景需要clone从设计层面看拷贝的动机6.1 原型模式当构造一个对象比克隆一个对象更贵Java的clone()最早是为“原型模式”Prototype Pattern设计的。原型模式的核心思想如果一个对象创建成本很高查询数据库、远程调用、复杂计算与其重新走一遍完整流程不如先创建一个原型对象之后通过克隆快速得到“初始状态相同的新对象”。最典型的例子是大量重复的配置初始化。比如一个系统有上千个产品配置每个配置初始状态基本相同但后续需要各自独立修改。你可以先构建一个“默认配置”原型然后每次需要新配置时直接clone()一份再修改差异部分。如果不克隆要么重新执行完整初始化逻辑成本高要么共享同一个对象互相污染。6.2 防御性拷贝外部传入的数据不能信写API或者公共方法时经常遇到一个需求方法接收一个List、Map或自定义对象作为参数这个参数可能来自外部调用方调用方可能在方法执行期间修改它。正确的做法是在方法内部做一份防御性拷贝用完拷贝体不直接操作外部引用。经典案例就是构造函数里public Order(Order original) { this.items new ArrayList(original.getItems()); // 如果需要更深层的隔离每个item也要clone }这是JDK里java.util包一直用的套路很多集合类都通过“copy构造函数”或者“新容器容纳旧元素”的方式避免外部引用直接进入内部结构。6.3 函数式编程里的不可变性诉求在并发场景里不可变对象是天然的线程安全方案。但业务数据往往是可变的一个折中做法就是每次修改前先深拷贝一份在副本上操作操作完再整体替换。这种方式能有效避免并发读写的竞态问题。不过这也很费内存我只建议在“并发冲突概率低、错误容忍度低”的场景使用。比如配置中心里的配置对象读写频繁用“不可替换式”的深拷贝每次更新配置都生成新对象消费者读到的永远是完整一致的状态。6.4 什么时候不该用clone资源和锁的持有者话说到这必须给“理解clone”加一道安全阀持有线程池、数据库连接池、网络IO资源的对象不要克隆。持有锁对象Lock、synchronized的对象头标记的对象不要克隆。单例对象不要克隆。内部引用关系复杂且变化频繁的对象不要手动深拷贝优先序列化方案。拷贝不等于复制资源它是一个“对象状态”的复制动作。资源型字段应当在克隆后保持共享或者显式重新初始化而不是被盲目复制。7. 一道综合练习题一个多层订单系统的完整拷贝方案光讲原理不够我给一个模拟项目里经常出现的“订单对象”做一份完整的深拷贝实现覆盖前面提过的所有点。public class OrderDetail implements Cloneable { private Long detailId; private String productName; // String不可变引用共享安全 private BigDecimal price; // BigDecimal不可变 private ListString tags; // String列表需要新容器元素可共享 Override protected OrderDetail clone() throws CloneNotSupportedException { OrderDetail clone (OrderDetail) super.clone(); if (this.tags ! null) { clone.tags new ArrayList(this.tags); } return clone; } } public class Order implements Cloneable { private String orderNo; private Long userId; private ListOrderDetail details; private MapString, String extInfo; Override protected Order clone() throws CloneNotSupportedException { Order clone (Order) super.clone(); clone.orderNo this.orderNo; // 不可变字段 clone.userId this.userId; // 基本类型字段 if (this.details ! null) { clone.details new ArrayList(this.details.size()); for (OrderDetail detail : this.details) { clone.details.add(detail.clone()); } } if (this.extInfo ! null) { clone.extInfo new HashMap(this.extInfo); // MapString, String中String不可变 } return clone; } }几个关键决策点OrderDetail.tags是ListStringString不可变所以新容器 共享元素就足够了。Order.extInfo是MapString, Stringkey和value都是不可变Stringnew HashMap(...)即可不需要对内部元素clone。如果OrderDetail里有一个Address address这样的自定义引用类型那么OrderDetail.clone()里必须再调用address.clone()否则还是会共享。整个链条里每个自定义类都实现了Cloneable每个clone()都从super.clone()开始这是标准姿势。如果直接把实现方式换成序列化深拷贝代码量会大幅减少public static T extends Serializable T deepCopy(T obj) { try (ByteArrayOutputStream bos new ByteArrayOutputStream(); ObjectOutputStream oos new ObjectOutputStream(bos)) { oos.writeObject(obj); try (ByteArrayInputStream bis new ByteArrayInputStream(bos.toByteArray()); ObjectInputStream ois new ObjectInputStream(bis)) { return (T) ois.readObject(); } } catch (Exception e) { throw new RuntimeException(深拷贝失败, e); } }代价是Order、OrderDetail及它们引用的所有自定义类都要实现Serializable并且要接受性能上的让步。具体怎么选还是回到第3节讲的原则。8. 关于浅拷贝和深拷贝我最后的几句实在话在Java里写出能跑的代码很容易但写出“经得起别人改”的代码很难。clone这件事就是典型的测试你在一个项目里接手老代码时看到某个对象被赋值给另一个变量大概率这里以后要出事。我自己在实际项目里的习惯是所有对外暴露的对象方法默认先问一句“这个对象会被外部改吗”然后决定是浅拷贝、手动深拷贝还是序列化方案。不要总寄希望于“大家都遵守约定、不改共享对象”在并发、分布式、多人协作的工程环境里防御性拷贝永远比口头约定可靠。另外还有个容易被忽略的小点Arrays.copyOf()、System.arraycopy()、List.copyOf()这些API名字里带“copy”但复制的是数组或集合的引用结构元素本身依然是共享的。把它们当成深拷贝来用同样会翻车。学习clone的时候顺便把这些“带copy字样的坑”一并记住。最后再说一个偏门但实用的技巧如果对象要支持深拷贝最好的设计是让所有内部引用字段也是可克隆的并且在每一层的clone()里都调用下一层的clone()。这样无论嵌套多少层规则都很统一也不容易被某个懒人直接super.clone()蒙混过关。代码review时我只要看到某层clone方法里“什么都没做”就知道有人在该用深拷贝的地方偷偷用了浅拷贝。深浅拷贝听起来像是个小知识点但它牵扯到对象模型、内存分配、序列化机制、设计模式这些Java最核心的关节。把这篇文章里代码跑一遍、表格抄下来、坑记下来以后再遇到“对象复制一份”这种需求就不会像我开头那样被一个最简单的赋值操作打得措手不及。 
长河君 · 2026/10/20 7:59:55 · 阅读 1.2k Java对象拷贝全解析：从浅拷贝到深拷贝的原理与实战避坑
最近在给一个老项目做参数快照功能需求很简单把一个订单对象复制一份后面的操作随便改不能影响原始数据。我下意识写了Order copy original;结果测试一跑原始订单的价格也被改了。当时第一反应是“这怎么可能”后来才意识到我一直没把Java里的clone这件事真正搞清楚。标题里那个“sallow copy”拼写其实是错的正确是“shallow copy”不过不影响理解。很多人写博客或者笔记都这么记说明大家一开始都是懵的。Java的拷贝不是“赋值”也不是“复制一下”这么简单浅拷贝和深拷贝的区别说小了是API调用姿势问题说大了能直接影响线上数据安全。这篇就把clone、浅拷贝、深拷贝从原理到实战完整拆一遍适合刚学Java SE、或者写了两三年代码但一直没认真研究过对象拷贝的同行。1. 先分清三件事赋值、拷贝、克隆1.1 直接赋值真的只是“多了一个名字”Java里的对象变量保存的是引用reference或者说指针。Order copy original;这一行执行完后栈上多了一个变量copy但它指向的堆内存还是同一个Order对象。打个比方你有一套房房产证上写了你名字然后又给这张证复印了一份复印件放桌上。复印件只是证明“这套房是你的”它不代表你又多了一套房。你拿复印件去改装修改动的是原来的房子不是某个新房。这就是为什么要专门学习拷贝只要你在做对象传递、缓存、快照、事务回滚这类场景赋值操作几乎是必然踩坑的点。很多时候线上问题查了半天最终定位到“某个下游服务把一个共享对象给改了”根源就是前面有人用了赋值而不是克隆。1.2 为什么Object.clone()是protected的如果你写过implements Cloneable一定遇到过这个报错clone() has protected access in Object很多新手在这里就直接卡住了。甚至有人因此觉得“Java的clone就是个废柴API”其实不是废柴是故意设计的。Object类是所有类的父类如果clone()是public那么世界上任何一个对象都能被无条件克隆。这会造成什么后果你的类里可能持有数据库连接、文件句柄、线程池等“不能被随随便便复制”的资源如果克隆是公开的、霸王硬上弓式的这些资源会被复制成两份重复释放、重复提交整个系统直接乱套。所以Java的设计哲学是类自己决定是否允许克隆。Cloneable接口本身是个标记接口marker interface里面没有任何方法它的作用就是告诉JVM和开发者“这个类允许被克隆”。真正做克隆动作的clone()方法继承自Object被protected修饰意味着只有本类和子类能调用。你首先要implements Cloneable然后在自己的类里重写clone()并且在重写方法里调用super.clone()外部才能通过你的公开方法拿到克隆体。我早年刚学的时候一直没搞懂为什么implements Cloneable这么空的一个接口就能让super.clone()魔法般地生成一个对象后来查了JDK源码才明白Object.clone()是一个native方法由JVM底层直接实现它做的事情是为当前对象分配一块同样大小的内存然后把这块内存中的所有二进制位逐位复制到新内存中。对于基本类型字段值直接复制对于引用类型字段复制的只是引用地址。这个“逐位复制”的过程决定了浅拷贝的一切行为。1.3 一切拷贝的起点一个最简单的克隆例子在讲浅拷贝和深拷贝之前先写一个最基础的克隆代码public class Student implements Cloneable { private String name; private int age; public Student(String name, int age) { this.name name; this.age age; } Override protected Object clone() throws CloneNotSupportedException { return super.clone(); } // getter/setter 省略 }调用端Student s1 new Student(小明, 18); Student s2 (Student) s1.clone(); System.out.println(s1 s2); // false说明确实创建了新对象 System.out.println(s1.equals(s2)); // false默认equals比较的是引用 System.out.println(s1.getName() s2.getName()); // trueString引用被复制了比较为false说明克隆确实产生了一个新对象堆内存地址不同。但是两个对象的name字段指向同一个String对象——这里就是浅拷贝的典型特征对象本身是新的对象内部的引用字段依然是共享的。注意String是不可变类所以即便两个对象共享同一个String引用也不会出现“改了一个、另一个跟着变”的问题。这会给初学者造成一种错觉觉得浅拷贝也没啥问题。等到字段变成List、Map、自定义对象时问题就来了。2. 浅拷贝一份新外壳里面还是同一批东西2.1 Object.clone()的执行细节比你想的更有意思很多人以为super.clone()是通过“构造一个新对象再逐个字段赋值”来实现的这是最大的误解。如果是通过构造器实现的那么克隆一个对象就必须执行构造器可能触发大量业务逻辑比如幂等号生成、时间戳更新、统计计数这显然不是克隆该有的语义。Object.clone()不走构造函数它是内存级拷贝。JVM先判断当前对象所属的类是否实现了Cloneable没实现直接抛CloneNotSupportedException。然后按对象占用内存大小分配新的内存区域再用底层指令把旧对象内存的二进制数据整体搬过去。这意味着基本类型字段int、long、boolean、double等被完整复制属于新对象自己的值。引用类型字段只复制了引用地址新旧对象的引用字段仍然指向堆上的同一个对象。构造函数不会执行初始化块不会执行前后两个对象的状态完全一致除了内存地址。因为没有走构造器如果你的类在构造器里做过防御性操作比如把传入的List包装成不可变集合克隆出来的对象会绕过这些防御直接裸奔。来看一段验证代码public class Address { private String city; public Address(String city) { this.city city; } public String getCity() { return city; } public void setCity(String city) { this.city city; } }public class Person implements Cloneable { private String name; private int age; private Address address; public Person(String name, int age, Address address) { this.name name; this.age age; this.address address; } Override protected Person clone() throws CloneNotSupportedException { return (Person) super.clone(); } // getter/setter 省略 }测试Address addr new Address(上海); Person p1 new Person(张三, 30, addr); Person p2 p1.clone(); System.out.println(p1 p2); // false System.out.println(p1.getAddress() p2.getAddress()); // true地址引用相同 p2.getAddress().setCity(北京); System.out.println(p1.getAddress().getCity()); // 输出北京。p1的城市也跟着变了这个例子已经能说明问题的严重性你以为克隆了一份完整数据结果只换了外壳内部的家当还是同一份。修改克隆体的地址原对象立刻被污染。2.2 引用类型和基本类型在浅拷贝里的不同命运很多人分不清“引用被复制”和“对象被复制”的区别我习惯用一个仓库类比浅拷贝相当于给仓库配了一把相同钥匙新仓库门牌号变了但仓库里的货物一动不动。你通过新钥匙进仓库搬走一箱货原来的仓库主人去清点货时发现货也少了。具体到Java对象就是字段类型浅拷贝后的行为示例基本类型值完全复制互不影响int age改克隆体不影响原对象String引用复制但不可变改不了内容String name相对安全数组数组对象引用复制元素共享int[] arr克隆体和原对象的arr是同一个数组容器List/Map/Set容器对象引用复制容器内元素共享ListStudent两个对象持有同一个List自定义引用类型引用地址复制指向同一个堆对象Address改动会互相影响2.3 实用取向浅拷贝在什么时候够用很多人一听到浅拷贝的问题就风声鹤唳觉得浅拷贝是万恶之源。其实不是浅拷贝在很多场景下是完全正确的选择强行深拷贝反而会造成性能浪费和结构性麻烦。什么时候可以使用浅拷贝对象只有基本类型字段。比如一个纯数值计算的对象int、long、double一堆浅拷贝后所有数据都是独立的。引用字段是不可变对象。String、Integer、BigDecimal、LocalDate这类不可变类共享引用不会出问题因为没有人能“修改”它们。唯一需要小心的是不要“重新赋值”指向别处。明确需要共享内部状态。比如多个视图对象共享同一个配置中心的数据改动一处、处处生效这种设计上就需要引用共享。要注意的是“默认可以被接受”和“安全”是两回事我在项目里定的规矩是除非你能明确说出“这里共享引用为什么没问题”否则一律用深拷贝。因为浅拷贝的坑往往不是当下暴露的而是在代码被改了几轮之后才炸的。3. 深拷贝连内部对象一起搬进新家3.1 方式一手动递归克隆最原教旨主义也最可控既然浅拷贝的问题是引用字段共享那思路就很直接引用字段也逐个克隆。Developer有意识地在clone()方法里把每个引用字段都调用一次clone()就得到了深拷贝。public class Person implements Cloneable { private String name; private int age; private Address address; private ListOrder orders; Override protected Person clone() throws CloneNotSupportedException { Person clone (Person) super.clone(); // 引用类型字段逐个克隆 clone.address this.address.clone(); // 容器类特殊处理新容器 内部元素逐个克隆 clone.orders new ArrayList(this.orders.size()); for (Order order : this.orders) { clone.orders.add(order.clone()); } return clone; } }这种方式的优点无可替代代码写出来行为就是所见即所得。每一层需要克隆哪些字段、哪些字段保持共享完全由开发者自己控制。但缺点也很明显你必须在类的内部实现Cloneable和clone()并且类层级越深代码越啰嗦。一旦对象图里有循环引用A引BB又引A手动写递归逻辑容易写出死循环或栈溢出。每个新类都要写一遍套路化代码改字段时容易漏。实际项目里手动递归克隆通常用在“结构稳定、字段不多、性能要求高”的核心实体上。每次改字段review代码时都会专门去看克隆逻辑有没有漏新字段。3.2 方式二利用序列化实现深拷贝省心但要付代价Java对象只要实现了Serializable接口就可以通过“先序列化成字节流再反序列化成新对象”的方式实现深拷贝。public class Person implements Serializable { private static final long serialVersionUID 1L; // 字段... } public static T T deepCopyViaSerialization(T obj) throws Exception { ByteArrayOutputStream bos new ByteArrayOutputStream(); ObjectOutputStream oos new ObjectOutputStream(bos); oos.writeObject(obj); oos.flush(); ObjectInputStream ois new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray())); SuppressWarnings(unchecked) T copy (T) ois.readObject(); return copy; }这段代码的原理是ObjectOutputStream把对象树完整写入字节流ObjectInputStream再从字节流重建整个对象图。因为对象树里的每一个对象都被完整写入反序列化时自然会重新创建全部内部对象所以达到深拷贝效果。我在项目中实测下来这个方式的“坑”主要是这几条对象的每一个成员字段所属的类都必须实现Serializable。只要对象图里有一个类没实现运行时就抛NotSerializableException。那种“明明序列化成功了clone的功能页面却跑到一半炸掉”的情况多半是某个内部类没实现接口。transient字段不会被序列化反序列化后是默认值。如果你有一个临时缓存字段是transient深拷贝之后它就丢了要小心。static字段不进对象序列化反序列化后仍然指向当前类的静态变量。serialVersionUID不一致会导致反序列化失败。同一个类的不同版本之间如果这个ID没写好拷贝时会抛InvalidClassException。序列化的性能比浅拷贝慢一两个数量级因为它涉及IO流的读写、类型检查、反射等操作。但如果对象结构复杂、嵌套层级深写出来的代码量远远小于手动递归可维护性好很多。遇到那些“字段特别多、嵌套特别深、又改来改去”的老项目我现在的习惯就是序列化深拷贝因为它不用每次加字段都去改克隆逻辑加字段只要实现Serializable就完事了。3.3 方式三通过JSON序列化做深拷贝最无脑的兜底方案还有一种经常被拿来救急的思路先把对象转成JSON字符串再从JSON字符串解析回一个全新的对象。String json userService.serializeToJson(person); Person copy jsonService.parseFromJson(json, Person.class);这套方案的好处不要求原类实现Serializable或Cloneable只要求它有合适的无参构造器和getter/setter或者能通过反射处理。对“外部依赖的对象”特别好用比如某个库返回的对象没有实现任何克隆相关接口你想拷贝一份手动复制又太麻烦转一次JSON就拿到了新对象。代码几乎不需要维护加字段、减字段都不影响。但受限也很明显JSON序列化不会保留对象里的循环引用结构。一旦两个对象互相引用转JSON会直接抛异常或把结构折平。transient字段、静态字段、非公开字段、没有默认构造器的类都可能被JSON库忽略。效率比Java原生序列化更低一次深拷贝要经历对象到字符串、字符串到新对象两次完整的序列化解析。强依赖第三方库的序列化配置碰到字段名改动、日期格式配置坑也很多。所以在我的团队里JSON深拷贝只作为“应急兜底”使用不给它常驻主链路。它的定位是当别的深拷贝手段都因为约束太多搞不定时用它是复杂度最低的解法。3.4 三种深拷贝方式对比选型不必过度纠结对比维度手动递归克隆Java序列化JSON序列化是否需要改类定义必须实现Cloneable必须实现Serializable一般不需要靠配置性能高纯内存复制 手动赋值中IO流 反射低字符串转换代码维护量高加字段时要同步改低加字段自动生效低循环引用支持需要专门处理原生支持通常不支持对字段的约束只处理明确代码的字段transient/static会丢失依赖序列化库配置适配外部类对象难难容易我的建议很简单对象字段少、层级浅想有完全控制权用手动递归。对象是内部系统自己的实体字段多、层级深用序列化。有第三方类没法改或者突然急用一次用JSON。不用在一个场景里强行追求“最优解”能解决问题、代码可维护、性能可接受就是好方案。4. 深拷贝实战中撞过的坑一次完整的排查复盘4.1 场景复现备份数据莫名被篡改某次在做一个“价格备份”功能时需求是从数据库读出一个价格配置对象备份一份用于比较后续运行过程中可能会修改原对象但备份对象必须保持不动。我的第一版代码PriceConfig backup (PriceConfig) config.clone();模拟测试的时候业务逻辑把config系列里的某个地区价格改了然后去比较backup发现backup也变了。那一刻我意识到clone()是浅拷贝但真正让我头疼的不是浅拷贝本身而是这个PriceConfig有几层嵌套public class PriceConfig implements Cloneable { private String configName; // String private BigDecimal basePrice; // BigDecimal private ListAreaPrice areaPrices; // 自定义类型集合 private MapString, Rule rules; // 自定义类型MAP }几个字段里configName是StringbasePrice是BigDecimal都不可变浅拷贝不会出问题。问题就出在areaPrices和rules上它们是容器容器本身引用被复制且容器里的自定义对象也是共享的。所以我改了原对象的某个AreaPrice备份对象里看到的也是同一个改过的对象。4.2 排查过程从猜想到逐层验证我先写了个最小复现测试确认areaPrices这个容器在clone后是不是同一个引用System.out.println(backup.getAreaPrices() config.getAreaPrices()); // true输出是true果然连容器本身都是同一份。然后我改成“容器也复制一份”在clone()里写this.areaPrices new ArrayList(this.areaPrices);以为这就算深拷贝了。结果测试一跑发现backup.getAreaPrices().get(0)和config.getAreaPrices().get(0)还是同一个对象。因为new ArrayList(collection)只是把集合的引用都放进一个新容器容器是新容器但里面的元素还是原来那一批。这一步暴露了新手在深拷贝时会犯的第二个经典错误只复制了容器没有复制容器里的元素。4.3 正确的深拷贝写法集合也逐层处理最后我把PriceConfig的clone改成了这样Override protected PriceConfig clone() throws CloneNotSupportedException { PriceConfig clone (PriceConfig) super.clone(); clone.basePrice this.basePrice; // BigDecimal不可变引用共享是安全的 // List新容器 元素逐个克隆 if (this.areaPrices ! null) { clone.areaPrices new ArrayList(this.areaPrices.size()); for (AreaPrice areaPrice : this.areaPrices) { clone.areaPrices.add(areaPrice.clone()); } } // Map新Map key/value逐个处理 if (this.rules ! null) { clone.rules new HashMap(); for (Map.EntryString, Rule entry : this.rules.entrySet()) { clone.rules.put(entry.getKey(), entry.getValue().clone()); } } return clone; }这里每个元素都需要支持clone()所以AreaPrice和Rule也都实现了Cloneable接口并重写了自己的clone()。如果这两个类内部还有嵌套引用类型它们的clone()也要继续深拷贝。4.4 排查看似解决了但同类型问题往往换个地方再犯修完之后复盘发现这件小事牵涉出一个更大的教训排查深拷贝问题时不要只看最外层类有没有重写clone()要从根上梳理整个对象图。我后来把“对象图里有哪些引用类型字段”做成了一张表圈出每一层需要处理的位置层级类名引用类型字段处理方式1PriceConfigListAreaPrice新建List 元素clone1PriceConfigMapString, Rule新建Map value clone2AreaPriceListString regionNames新建ListString不可变元素不深拷2RuleCategory category继续调用categor的clone用了表格之后每个字段“需要深层克隆还是可以直接共享”一目了然漏字段的概率低了很多。5. 序列化深拷贝里的另外几个关键约束5.1 transient字段静默丢失的一等公民序列化深拷贝常用但有一个容易被忽略的字段修饰符transient。标记为transient的字段不会参与序列化反序列化后会被设成JVM默认值引用类型为null基本类型为0或false。我踩过一次实打实的坑某个对象有一个transient ListString extraInfo是在构造函数里被初始化的正常情况下永远不为空。用序列化方式做深拷贝后extraInfo直接变成null后续代码执行copy.getExtraInfo().size()就空指针了。排查了很久才发现元凶是transient。所以如果你的对象里有transient字段并且这个字段对业务逻辑有意义用序列化做深拷贝之前必须想清楚这个字段要不要拷贝如果也要拷贝就得单独处理不能依赖序列化自动完成。5.2 serialVersionUID版本不一致直接失效Java序列化要求类有稳定的serialVersionUID。如果类没有显式声明JVM会根据类的结构自动计算一个。这里的问题是只要类的字段、方法签名有任何变化自动计算出的serialVersionUID就会变。当你把一个对象序列化后存起来后来类加了字段再用旧字节流反序列化时就会报InvalidClassException因为序列化时的类版本和当前类版本不一致。这个问题在做深拷贝时没那么明显——因为序列化和反序列化通常在同一进程、使用同一个类定义——但如果你的系统里存在跨服务、跨进程、跨JVM的拷贝需求serialVersionUID的坑就非常现实。最佳实践是每个实现了Serializable的类都显式声明这个ID并固定在某个值private static final long serialVersionUID 1L;这样无论类内部怎么加字段新旧版本之间也能保持兼容新字段会被赋予默认值序列化操作不会轻易失效。5.3 枚举和单例对象在序列化面前的自毁行为枚举类型在Java里有一套特殊处理反序列化时不会通过构造器创建新对象而是通过枚举名直接查找现有的枚举常量。所以枚举在序列化深拷贝里是安全的——序列化前后的枚举是同一个对象不会复制出第二个实例。单例类就不一样了。如果你用序列化方式去深拷贝一个单例对象反序列化时会创建一个全新的实例单例的约束被绕过系统中出现两个“单例”状态还可能分叉。这是深拷贝在特殊设计模式面前需要格外小心的点。还有一类对象千万别深拷贝持有文件句柄、数据库连接、Socket等的对象。这些资源无法被真正“复制”强行序列化或克隆会造成连接泄漏和资源回收混乱。碰到这类对象要么让克隆保持引用共享要么封死克隆路径。5.4 循环引用手写深拷贝时的栈溢出危机对象图里存在循环引用A引用BB引用A时手动递归深拷贝如果不做“已访问对象”的标记递归就会无限进行下去最终抛出StackOverflowError。序列化方案因为内部有对象图记录机制能正确处理循环引用这也是它在复杂对象图面前更省心的原因之一。JSON方案则通常不支持循环引用转换时会直接抛异常或丢失一边的引用关系。如果项目里循环引用比较常见手动深拷贝时要用一个IdentityHashMap记录已经克隆过的对象private MapObject, Object cloneCache new IdentityHashMap(); public Object deepClone(Object obj) { if (cloneCache.containsKey(obj)) { return cloneCache.get(obj); } // 创建克隆体并放缓存再去克隆引用字段 }这个技巧在复杂对象图里很管用能避免重复克隆同一个对象也能斩断循环引用的死结。6. 到底什么场景需要clone从设计层面看拷贝的动机6.1 原型模式当构造一个对象比克隆一个对象更贵Java的clone()最早是为“原型模式”Prototype Pattern设计的。原型模式的核心思想如果一个对象创建成本很高查询数据库、远程调用、复杂计算与其重新走一遍完整流程不如先创建一个原型对象之后通过克隆快速得到“初始状态相同的新对象”。最典型的例子是大量重复的配置初始化。比如一个系统有上千个产品配置每个配置初始状态基本相同但后续需要各自独立修改。你可以先构建一个“默认配置”原型然后每次需要新配置时直接clone()一份再修改差异部分。如果不克隆要么重新执行完整初始化逻辑成本高要么共享同一个对象互相污染。6.2 防御性拷贝外部传入的数据不能信写API或者公共方法时经常遇到一个需求方法接收一个List、Map或自定义对象作为参数这个参数可能来自外部调用方调用方可能在方法执行期间修改它。正确的做法是在方法内部做一份防御性拷贝用完拷贝体不直接操作外部引用。经典案例就是构造函数里public Order(Order original) { this.items new ArrayList(original.getItems()); // 如果需要更深层的隔离每个item也要clone }这是JDK里java.util包一直用的套路很多集合类都通过“copy构造函数”或者“新容器容纳旧元素”的方式避免外部引用直接进入内部结构。6.3 函数式编程里的不可变性诉求在并发场景里不可变对象是天然的线程安全方案。但业务数据往往是可变的一个折中做法就是每次修改前先深拷贝一份在副本上操作操作完再整体替换。这种方式能有效避免并发读写的竞态问题。不过这也很费内存我只建议在“并发冲突概率低、错误容忍度低”的场景使用。比如配置中心里的配置对象读写频繁用“不可替换式”的深拷贝每次更新配置都生成新对象消费者读到的永远是完整一致的状态。6.4 什么时候不该用clone资源和锁的持有者话说到这必须给“理解clone”加一道安全阀持有线程池、数据库连接池、网络IO资源的对象不要克隆。持有锁对象Lock、synchronized的对象头标记的对象不要克隆。单例对象不要克隆。内部引用关系复杂且变化频繁的对象不要手动深拷贝优先序列化方案。拷贝不等于复制资源它是一个“对象状态”的复制动作。资源型字段应当在克隆后保持共享或者显式重新初始化而不是被盲目复制。7. 一道综合练习题一个多层订单系统的完整拷贝方案光讲原理不够我给一个模拟项目里经常出现的“订单对象”做一份完整的深拷贝实现覆盖前面提过的所有点。public class OrderDetail implements Cloneable { private Long detailId; private String productName; // String不可变引用共享安全 private BigDecimal price; // BigDecimal不可变 private ListString tags; // String列表需要新容器元素可共享 Override protected OrderDetail clone() throws CloneNotSupportedException { OrderDetail clone (OrderDetail) super.clone(); if (this.tags ! null) { clone.tags new ArrayList(this.tags); } return clone; } } public class Order implements Cloneable { private String orderNo; private Long userId; private ListOrderDetail details; private MapString, String extInfo; Override protected Order clone() throws CloneNotSupportedException { Order clone (Order) super.clone(); clone.orderNo this.orderNo; // 不可变字段 clone.userId this.userId; // 基本类型字段 if (this.details ! null) { clone.details new ArrayList(this.details.size()); for (OrderDetail detail : this.details) { clone.details.add(detail.clone()); } } if (this.extInfo ! null) { clone.extInfo new HashMap(this.extInfo); // MapString, String中String不可变 } return clone; } }几个关键决策点OrderDetail.tags是ListStringString不可变所以新容器 共享元素就足够了。Order.extInfo是MapString, Stringkey和value都是不可变Stringnew HashMap(...)即可不需要对内部元素clone。如果OrderDetail里有一个Address address这样的自定义引用类型那么OrderDetail.clone()里必须再调用address.clone()否则还是会共享。整个链条里每个自定义类都实现了Cloneable每个clone()都从super.clone()开始这是标准姿势。如果直接把实现方式换成序列化深拷贝代码量会大幅减少public static T extends Serializable T deepCopy(T obj) { try (ByteArrayOutputStream bos new ByteArrayOutputStream(); ObjectOutputStream oos new ObjectOutputStream(bos)) { oos.writeObject(obj); try (ByteArrayInputStream bis new ByteArrayInputStream(bos.toByteArray()); ObjectInputStream ois new ObjectInputStream(bis)) { return (T) ois.readObject(); } } catch (Exception e) { throw new RuntimeException(深拷贝失败, e); } }代价是Order、OrderDetail及它们引用的所有自定义类都要实现Serializable并且要接受性能上的让步。具体怎么选还是回到第3节讲的原则。8. 关于浅拷贝和深拷贝我最后的几句实在话在Java里写出能跑的代码很容易但写出“经得起别人改”的代码很难。clone这件事就是典型的测试你在一个项目里接手老代码时看到某个对象被赋值给另一个变量大概率这里以后要出事。我自己在实际项目里的习惯是所有对外暴露的对象方法默认先问一句“这个对象会被外部改吗”然后决定是浅拷贝、手动深拷贝还是序列化方案。不要总寄希望于“大家都遵守约定、不改共享对象”在并发、分布式、多人协作的工程环境里防御性拷贝永远比口头约定可靠。另外还有个容易被忽略的小点Arrays.copyOf()、System.arraycopy()、List.copyOf()这些API名字里带“copy”但复制的是数组或集合的引用结构元素本身依然是共享的。把它们当成深拷贝来用同样会翻车。学习clone的时候顺便把这些“带copy字样的坑”一并记住。最后再说一个偏门但实用的技巧如果对象要支持深拷贝最好的设计是让所有内部引用字段也是可克隆的并且在每一层的clone()里都调用下一层的clone()。这样无论嵌套多少层规则都很统一也不容易被某个懒人直接super.clone()蒙混过关。代码review时我只要看到某层clone方法里“什么都没做”就知道有人在该用深拷贝的地方偷偷用了浅拷贝。深浅拷贝听起来像是个小知识点但它牵扯到对象模型、内存分配、序列化机制、设计模式这些Java最核心的关节。把这篇文章里代码跑一遍、表格抄下来、坑记下来以后再遇到“对象复制一份”这种需求就不会像我开头那样被一个最简单的赋值操作打得措手不及。