浅拷贝与深拷贝性能对比

​前言

       在日常开发中，对象的转换使用的很频繁，其中对象的转换大致可以分为浅拷贝和深拷贝两种，如果细分，对于深拷贝又可以细分为好几种。本文基于主流的几种深拷贝方式做了一系列测试，并探讨其中的原理和适用场景。

        欢迎读者进行探讨，如有错漏之处，敬请指导，由于公众号新注册用户没有留言功能，想探讨的同学直接在公众号回复即可。
 

一、浅拷贝和深拷贝

        浅拷贝：对基本数据类型进行值传递，对引用数据类型进行引用传递般的拷贝，此为浅拷贝

        深拷贝：对基本数据类型进行值传递，对引用数据类型，创建一个新的对象，并复制其内容，此为深拷贝。

        这里主要列出了以下几种方式:

        浅拷贝:

        1）使用Java 的clone方式，要求实现cloneable并且重写clone方法，原理是调用internalClone() 这个native方法，代码侵入性较大，但是性能优秀。

        2）Apache的BeanUtil方式，公认的性能差，已经抛弃，这里不再测试。

        3）Spring的BeanUtil方式，通过反射。

        4）Hutool的BeanUtil方式，这个也是浅拷贝，性能也不错。

        5）MapStruct方式，实际是生成get和set方法，性能优异，不过每次更新都需要deploy。

        6）Apache的BeanCopier方式，与Hutool的BeanCopier的类似，使用了CGLIB动态代理，比反射性能优异，这里选取Apache的BeanCopier。

      浅拷贝主要比较Java 的clone，Spring的BeanUtil，Hutool的BeanUtil，MapStruct，BeanCopier五种方案。

        深拷贝:

        1）用各种json工具进行序列化和反序列化，性能非常差，这里不再对比。

        2）Kryo方式

        3）Orika方式

        4）Java IO进行序列化和反序列化

        5）Protobuf方式，对复杂对象序列化和反序列化还存在问题，Hessian方式和Thrift方式也存在各种问题，这里不再对比。

        6）Dozer方式

        深拷贝主要比较Kryo，Orika，Java IO，Dozer四种方案。

二、具体场景

        浅拷贝：在项目的分层结构中，经常需要BO，VO，DTO之间的转换，这种场景数量巨大，字段较多，因此对性能要求巨大。

        深拷贝：在之前做过的一个进销库存项目中，

        1）某个逻辑需要对数据