深浅拷贝详解：序列化与克隆对比

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《集合序列化与克隆：深浅拷贝对比详解》，聊聊，我们一起来看看吧！

Java中ArrayList.clone()只做浅拷贝，新列表与原列表共享元素引用，修改副本中的自定义对象会影响原列表；修复需手动深拷贝或序列化方案。

Java里用clone()克隆ArrayList，为什么改副本还影响原列表？

因为ArrayList.clone()只做浅拷贝——它新建了一个ArrayList容器，但里面存的元素引用没变。如果元素是自定义对象（比如User），两个列表里的User实例还是同一个对象。

• 现象：修改list2.get(0).setName("Alice")，list1.get(0)的名字也变了
• 原因：clone()没递归复制元素，只复制了数组引用本身
• 修复方式：不能只靠clone()，得手动遍历+深拷贝每个元素，或换序列化方案
• 注意：Arrays.asList(...).clone()甚至不工作——返回的是不可变视图，clone()抛UnsupportedOperationException

Python中copy.copy()和copy.deepcopy()对嵌套列表的行为差异

copy.copy()只复制外层容器，子列表仍是原引用；copy.deepcopy()才真正断开所有层级的引用链。

• 常见错误：用ys = copy.copy(xs)处理xs = [[1,2], [3,4]]，然后ys[0].append(99)会导致xs[0]也多出99
• 性能代价：deepcopy要递归遍历整个对象图，遇到循环引用会报RecursionError，大数据量时明显变慢
• 替代思路：若结构固定（如全是字典/列表），可用json.loads(json.dumps(obj))快速“伪深拷贝”，但不支持函数、datetime、自定义类等非JSON类型

Spring项目里DTO传参总被意外修改？别只依赖MapStruct的@Mapping

MapStruct默认生成的映射方法是浅拷贝逻辑——源对象字段是引用类型时，目标对象拿到的仍是同一份引用。这在Service层并发调用或事务回滚场景下极易引发数据污染。

• 典型症状：A线程修改了DTO里的order.getItems()，B线程读到的也是改后的集合
• 解决路径：在@Mapper接口上加uses = {CollectionMapper.class}，并自定义CollectionMapper对List做new ArrayList(source)或逐项clone()
• 更稳妥做法：DTO类自身实现Serializable，配合工具类SerializationUtils.clone(dto)（来自Spring Core），确保彻底隔离
• 坑点：SerializationUtils.clone()要求所有嵌套对象都可序列化，否则抛NotSerializableException，需逐级检查

为什么序列化反序列化是“最老实”的深拷贝方案？

它绕过了所有引用共享的可能性——把对象写成字节流再重读，等于强制重建整个对象树，天然切断所有内存地址关联。

• 优势：不依赖对象是否实现Cloneable，也不关心字段是否private或final，只要可序列化就生效
• 代价：性能开销大（IO+反射）、无法序列化Thread/Socket等JVM资源类、静态字段和transient字段丢失
• 实用技巧：生产环境慎用ObjectOutputStream直接序列化，优先选Kryo或FST等高性能替代库，避免java.io的GC压力
• 关键提醒：序列化深拷贝 ≠ 安全深拷贝——若类里有final字段指向可变对象（如final List tags），反序列化后仍可能被外部修改

深拷贝从来不是一锤定音的操作，而是根据容器结构、嵌套深度、运行环境反复权衡的结果。最容易被忽略的，是那些看似“不可变”实则内部可变的字段——它们让深拷贝在最后一层失效。

本篇关于《深浅拷贝详解：序列化与克隆对比》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！