经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » Java相关 » Java » 查看文章
都说了别用BeanUtils.copyProperties，这不翻车了吧
来源：cnblogs　　作者：程序员老猫　　时间：2024/2/28 9:13:16　　对本文有异议

分享是最有效的学习方式。

博客：https://blog.ktdaddy.com/

故事

新年新气象，小猫也是踏上了新年新征程，自从小猫按照老猫给的建议【系统梳理大法】完完整整地梳理完毕系统之后，小猫对整个系统的把控可谓又是上到可一个新的高度。开工一周，事情还不是很多，寥寥几个需求，小猫分分钟搞定。

类似于开放平台的老六接到客户的需求，需要在查询订单新增一个下单时间的返回值，然后这就需要提供底层服务的小猫在接口层给出这个字段，然后老六通过包装之后给客户。由于需求比较简单，所以加完字段之后，老六和小猫也就直接上线了。

上线之后事儿来了，对面客户研发一直询问为什么还是没有下单时间，总是空的。老六于是直接找到了小猫，可是小猫经过了一些列的自测发现返回值都是有的，后来排查到在老六封装之后值不见了。经过仔细排查，终于找到了问题，虽然没有造成太大的影响，但是总归给客户研发的心里留下了一个不好的印象。

虽然下单时间老六和小猫定义的都是orderTime这样一个字段，但是字段类型小猫用的是Date类型而老六用的是LocalDate,恰巧老六在进行对象赋值的时候偷了个懒直接用了spring的BeanUtils.copyProperties工具类，于是导致日期类型的值并没有被赋值过去，踩坑了。

老六这才回想起前段时间架构师在群里@ALL的一段话，“大家用BeanUtils拷贝对象的时候注意点，有坑啊，大家尽量用get,set方法啊”。当时的老六不以为意，想着，“切，这得多麻烦，一个个set不花时间啊，有工具类不用”。现在想来看来是真踩到BeanUtils的坑了。

老六一边改着代码一边叨叨：“这也没说坑在哪里啊......”

盘点BeanUtils.copyProperties坑点

相信很多小伙伴在日常开发的过程中都用过BeanUtils.copyProperties。因为我们日常开发中，经常涉及到DO、DTO、VO对象属性拷贝赋值。很多开发为了省去繁琐而又无聊的set方法往往都会用到这样的工具类进行值拷贝，但是看似简单的拷贝程序，其实往往暗藏坑点，这不上面的老六就踩雷了么。

下面咱们一起来盘点一下这个拷贝存在哪些坑点吧。见下图。

盘点

目标赋值对象属性非预期

这里主要说的是从老对象进行属性拷贝到新对象之后，新对象的属性值不是所期待的。这里分为两种。

  1. 两对象属性命名一致，但是类型不一致(即老六遇到的坑点)。
  2. 由于开发编写没有核对好，两个对象属性值不一致，却采用了拷贝，导致异常。
  3. loombook+Boolean类型数据+is属性开头的坑。
  4. 不同内部类，相同属性，目标对象赋值有问题。

类型不匹配

我们来重放一下老六和小猫遇到坑。代码如下：

  1. /**
  2.  * 公众号：程序员老猫 
  3.  **/
  4. public class BeanCopyHelper {
  5.     public static void main(String[] args) {
  6.         Origin a = new Origin();
  7.         a.setOrderTime(new Date());
  9.         Target b = new Target();
  10.         BeanUtils.copyProperties(a,b);
  11.         System.out.println(a.getOrderTime());
  12.         System.out.println(b.getOrderTime());
  13.     }
  14. }
  15. @Data
  16. class Origin {
  17.     private Date orderTime;
  18. }
  19. @Data
  20. class Target {
  21.     private LocalDate orderTime;
  22. }

输出结果：

  1. Sun Feb 25 21:52:22 CST 2024
  2. null

我看看到两个对象的命名虽然是一致的，但是一个是Date另外一个是LocaDate，这样导致值并没有被赋值过去。

两对象属性命名差异导致赋值不成功

这种拷贝不成功的原因很多时候是由于研发人员粗心，没有校对好导致的。例如下面两个类：

  1. @Data
  2. class Origin {
  3.     private Date ordertime;
  4. }
  5. @Data
  6. class Target {
  7.     private Date orderTime;
  8. }

这种显而易见是无法赋值成功的，因为仔细看来两个属性名称不一致。当然不会赋值成功了。

loombook+Boolean类型数据+is属性开头的坑

这种情况是比较极端的，在用loombook和不用loombook的情况下是不一样的。我们看一下下面例子。
当我们不用loombook的时候，如下代码：

  1. public class BeanCopyHelper {
  2.     public static void main(String[] args) {
  3.         Origin origin = new Origin();
  4.         origin.setOrderTime(true);
  5.         Target target = new Target();
  6.         BeanUtils.copyProperties(origin,target);
  7.         System.out.println(origin.getOrderTime());
  8.         System.out.println(target.isOrderTime());
  9.     }
  10. }
  12. class Origin {
  13.     private Boolean isOrderTime;
  14.     public Boolean getOrderTime() {
  15.         return isOrderTime;
  16.     }
  17.     public void setOrderTime(Boolean orderTime) {
  18.         isOrderTime = orderTime;
  19.     }
  20. }
  21. class Target {
  22.     private boolean isOrderTime;
  23.     public boolean isOrderTime() {
  24.         return isOrderTime;
  25.     }
  26.     public void setOrderTime(boolean orderTime) {
  27.         isOrderTime = orderTime;
  28.     }
  29. }

上面的代码中，我们看到基础属性的类型分别是包装类还有一个是非包装类，属性的命名都是一致的。其最终的输出结果，我们看到两者是一致的：

  1. true
  2. true

当如果我们使用loombook的时候，问题就来了，我们看一下loombook改造之后的代码：

  1. public class BeanCopyHelper {
  2.     public static void main(String[] args) {
  3.         Origin origin = new Origin();
  4.         origin.setIsOrderTime(true);
  5.         Target target = new Target();
  6.         BeanUtils.copyProperties(origin,target);
  7.         System.out.println(origin.getIsOrderTime());
  8.         System.out.println(target.isOrderTime());
  9.     }
  10. }
  12. @Data
  13. class Origin {
  14.     private Boolean isOrderTime;
  15. }
  16. @Data
  17. class Target {
  18.     private boolean isOrderTime;
  19. }

最后的输出结果为：

  1. true
  2. false

那么这是为什么呢？老猫在这里简单分享一下，BeanUtils.copyProperties用户在两个对象之间进行属性的复制，底层基于JavaBean的内省机制，通过内省得到拷贝源对象和目的对象属性的读方法和写方法，然后调用对应的方法进行属性的复制。

所以在进行拷贝时，如果手动生成get和set那么方法分别为:getOrderTime()以及setOrderTime()。我们再来看一下如果采用LoomBook的时候，那么对应的get和set的方法分别为：getIsOrderTime()以及setOrderTime()，抛开set和get本身关键字不看，那么后面的肯定是对应不起来了。

这里我们再发散一下，如果说对应的两个类其属性压根连get和set方法都没有设置，那么两个对象能够被拷贝成功吗？答案是显而易见的，无法被拷贝成功。所以这里也是用这个拷贝方法的时候的一个坑点。

不同内部类，相同属性，目标对象赋值有问题。

看标题还是比较抽象的，我们一起来看一下下面的代码实现：

  1. public class BeanCopyHelper {
  2.     public static void main(String[] args) {
  3.         Origin test1 = new Origin();
  4.         test1.outerName = "程序员老猫";
  5.         Origin.InnerClass innerClass = new Origin.InnerClass();
  6.         innerClass.InnerName = "程序员老猫 内部类";
  7.         test1.innerClass = innerClass;
  8.         System.out.println(test1);
  9.         Target test2 = new Target();
  10.         BeanUtils.copyProperties(test1, test2);
  11.         System.out.println(test2);
  12.     }
  13. }
  14. @Data
  15. class Origin {
  16.     public String outerName;
  17.     public Origin.InnerClass innerClass;
  19.     @Data
  20.     public static class InnerClass {
  21.         public String InnerName;
  22.     }
  23. }
  24. @Data
  25. class Target {
  26.     public String outerName;
  27.     public Target.InnerClass innerClass;
  29.     @Data
  30.     public static class InnerClass {
  31.         public String InnerName;
  32.     }
  33. }

输出最终结果如下：

  1. Origin(outerName=程序员老猫, innerClass=Origin.InnerClass(InnerName=程序员老猫 内部类))
  2. Target(outerName=程序员老猫, innerClass=null)

最终我们发现其内部内的属性并没有被赋值过去。

引包冲突导致问题

BeanUtils.copyProperties其实同命名的方法存在于两个不同的包中，一个是spring的另外一个是apache的，如果不注意的话，很容易就会有问题。如下代码：

  1. //org.springframework.beans.BeanUtils(源对象在左边，目标对象在右边)
  2. public static void copyProperties(Object source, Object target) throws BeansException 
  3. //org.apache.commons.beanutils.BeanUtils（源对象在右边，目标对象在左边）
  4. public static void copyProperties(Object dest, Object orig) throws IllegalAccessException, InvocationTargetException

位于org.springframework.beans包下。
其copyProperties方法实现原理和Apache BeanUtils.copyProperties原理类似，默认实现浅拷贝
区别在于对PropertyDescriptor（内省机制相关）的处理结果做了缓存来提升性能。这里大家有兴趣可以自行去查阅一下源代码。

查找字段引用困难

当我们在排查问题的时候，或者在熟悉业务的过程中，常常会想要看一个整个属性值的调用链路，从而来跟踪其设值源头。如果我想看当前的这个属性是什么时候被设值值的时候，老猫的做法通常是找到当前的那个属性的set方法，然后使用idea中的“Find Usages”或者快捷键ALT+F7。得到需要属性值被设置的地方。如下图，就能清晰看到在哪里设值了。

调用链路

但是，如果用了工具类进行拷贝的话，那么在代码复杂的情况下，我们就很难定位其在什么时候被调用的了。

BeanUtils.copyProperties是浅拷贝

在这里，咱们要回忆一下什么时候浅拷贝，什么是深拷贝。
浅拷贝：浅拷贝是指创建一个新对象，然后将原始对象的内容逐个复制到新对象中。在浅拷贝中，只有最外层对象被复制，而内部的嵌套对象只是引用而已，没有被递归复制。这意味着原始对象和浅拷贝对象之间共享内部对象，修改其中一个对象的内部对象会影响到另一个对象。如下示意图：

浅拷贝

深拷贝：深拷贝是指在进行复制操作时，创建一个完全独立的新对象，并递归地复制原始对象及其所有子对象。换句话说，深拷贝会复制对象的所有层级，包括对象的属性、嵌套对象、引用等。因此，原始对象和复制对象是完全独立的，修改其中一个对象不会影响另一个对象。

深拷贝

根据上面的描述，我们通过代码来重现一下坑点，具体如下：

  1. public class Address {
  2.     private String city;
  3.     ...
  4. }
  5. public class Person {
  6.     private String name;
  7.     private Address address;
  8.     ...
  9. }
  10. public class TestMain {
  11.     public static void main(String[] args) {
  12.         Person sourcePerson = new Person();
  13.         sourcePerson.setName("老六");
  14.         Address address = new Address();
  15.         address.setCity("上海 徐汇");
  16.         sourcePerson.setAddress(address);
  17.         Person targetPerson = new Person();
  18.         BeanUtils.copyProperties(sourcePerson, targetPerson);
  19.         System.out.println(targetPerson.getAddress().getCity());
  20.         sourcePerson.getAddress().setCity("上海 黄埔");
  21.         System.out.println(targetPerson.getAddress().getCity());
  22.     }
  23. }

输出结果为：

  1. 上海 徐汇
  2. 上海 黄埔

我们很明显地看到操作原始属性的地址，直接影响到了新对象的属性的地址。所以这个坑大家也要当心。当然由于浅拷贝的原因导致拷贝出现问题还涉及集合类进行拷贝。例如我们需要对List或者Map进行拷贝的时候也不能直接去拷贝list以及map。

性能问题

由于BeanUtils.copyProperties其实底层是通过反射实现的，所以其程序执行的效率还是比较低的。我们看一下下面的对比代码：

  1. public class BeanCopyHelper {
  2.     public static void main(String[] args) {
  3.         Origin test1 = new Origin();
  4.         test1.outerName = "公众号:程序员老猫";
  5.         Target test2 = new Target();
  6.         long beginTime = System.currentTimeMillis();
  7.         for (int i = 0; i < 100000; i++) {  //循环10万次
  8.             test2.setOuterName(test1.getOuterName());
  9.         }
  10.         System.out.println(test2);
  11.         System.out.println("common setter time:" + (System.currentTimeMillis() - beginTime));
  12.         long beginTime2 = System.currentTimeMillis();
  13.         for (int i = 0; i < 100000; i++) {  //循环10万次
  14.             BeanUtils.copyProperties(test1, test2);
  15.         }
  16.         System.out.println(test2);
  17.         System.out.println("common setter time:" + (System.currentTimeMillis() - beginTime2));
  18.     }
  19. }
  21. @Data
  22. class Origin {
  23.     public String outerName;
  24. }
  25. @Data
  26. class Target {
  27.     public String outerName;
  28. }

输出结果如下：

  1. Target(outerName=公众号:程序员老猫)
  2. common setter time:14
  3. Target(outerName=公众号:程序员老猫)
  4. common setter time:291

上述结果，很好地证明了这个结论。有小伙伴肯定会说，这种场景应该比较少吧，太极端了。那么极端吗？大家回忆一下上面老猫提到了，如果用这个工具复制List或者Map这种集合的时候，其实如果把List和Map当做整个对象来复制往往是失败的。相信如果不是小白的话一般都会知道这个坑点，为了解决这个问题，很多小伙伴可能会选择在List或者Map等集合内部进行循环一一遍历去进行单个对象的拷贝赋值，那么这样的场景下，性能是不是就受到了影响呢？

替换方案

既然说了bean拷贝工具类这么多的坏话，那么我们如何去替换这种写法呢？
第一种：当然是直接采用原始的get以及set方法了。这种方式好像除了代码长了一些之外好像也没有什么缺点了。有小伙伴可能会跳出来说，这不撸起来麻烦么。不着急，idea这款强大的工具不是已经给我们提供插件了么。如下图：

插件示意图

第二种：使用映射工具库，如MapStruct、ModelMapper等，它们可以自动生成属性映射的代码。这些工具库可以减少手动编写setter方法的工作量，并提供更好的性能。
如下使用代码：

  1.     /**
  2.      * 公众号：程序员老猫
  3.      **/
  4.     @Mapper  
  5.     public interface SourceTargetMapper {  
  6.     SourceTargetMapper INSTANCE = Mappers.getMapper(SourceTargetMapper.class);  
  8.     @Mapping(source = "name", target = "name")  
  9.     @Mapping(source = "age", target = "age")  
  10.     Target mapToTarget(Source source);  
  11.     }  
  13.     //使用
  14.     Target target = SourceTargetMapper.INSTANCE.mapToTarget(source);

上述这两种替换方案，说真的作为开发者而言，老猫更喜欢第一种，简单方便，而且不需要依赖第三方maven依赖。第二种个人感觉用起来反而比较繁琐，上述当然纯属个人偏好。

总结

上述小猫和老六的案例中，其实存在的问题需要我们思考的。

即使再小再简单的需求，作为研发开发完毕之后，我们可以直接上线么？其实很多时候事故往往就是由于“不以为意”发生的。事故的发生往往也遵循“墨菲定律”，这就要求我们更要敬畏线上，再小的需求点都需要经过严格的测试验证才能上线。

说了那么多BeanUtils.copyProperties的坏话，那么这种拷贝方式是不是真的就一无是处呢？其实不是的，所谓存在即合理。很多时候使用的时候踩坑说白了我们没有理解好这个拷贝工具的特性。很多时候大家在使用使用一个技术的时候都是囫囵吞枣，为了使用而去使用，压根就没有深入了解这个技术的特性以及使用注意点。所以在我们使用第三方工具的时候，我们需要更好地了解其特性，知其所以然才能更好更正确的使用。小伙伴们你们觉得呢？

如果还有需要补充的点，也欢迎小伙伴们留言。

原文链接：https://www.cnblogs.com/kdaddy/p/18035763

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Java热门文章

  • 【IDEA】Application context not configured for this file
  • [IDEA] chapter_reader - idea看小说插件 idea阅读插件 idea摸鱼插件
  • thrift常见异常及原因分析
  • Java 调用 PaddleDetection 模型
  • JVM 详解，大白话带你认识 JVM
  • spring-boot-2.0.3不一样系列之番外篇 - @Configuration、Condition与@Conditional
  • Java Comparator.comparing比较导致空指针异常的解决
  • Java使用EasyExcel进行单元格合并的问题详解
  • 死磕 java集合之ArrayBlockingQueue源码分析
  • Java基础之集合Set详解

    • Java推荐文章

  • 面试场景题：一次关于线程池使用场景的讨论。
  • 前端黑科技：使用 JavaScript 实现网页扫码功能
  • 聊一聊 Netty 数据搬运工 ByteBuf 体系的设计与实现
  • 简单设计一个JAVA并行处理工具类
  • 【杂谈】JPA乐观锁改悲观锁遇到的一些问题与思考
  • 认识netty的基本组件
  • Jenkins如何使用CrumbIssuer防御CSRF攻击
  • 如何平稳地从nacos迁移到r-nacos？
  • 线程池遇到父子任务，有大坑，要注意！
  • Java JVM——12. 垃圾回收理论概述

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号