BeanUtil.copyProperties真的很慢吗？

BeanUtil.copyProperties真的很慢吗？

BeanUtil.copyProperties性能探究

• BeanUtil.copyProperties用于对象属性的copy，而BeanUtil.copyProperties是通过java的反射进行实现的，我们都知道java反射会比对象实例直接通过set方法设值更耗时，那么BeanUtil.copyProperties是否也是如此呢？实际上通过源码可知，BeanUtil.copyProperties是做了缓存优化的，具体怎么优化的，对其性能提升有多大影响，我们一探究竟。本文以spring的BeanUtil.copyProperties作为研究对象。

源码探究

• 通过copyProperties（）方法作为入口进行源码阅读

• 

• 

• 

• 

• 

• 

• 

简要总结

• CopyProperties()方法，主要通过以下步骤将source对象中与target对象同名属性写入target对象：
• 获取目标对象类信息
  • 根据类信息从缓存中获取到该类的所有属性信息（内含readMethod和writeMethod）
  • 缓存中没有该类的信息则进行初始化
• 遍历目标对象属性
  • 通过目标对象属性名+源对象类获取源对象属性信息类（内含readMethod和writeMethod）
  • 源对象类中存在该属性，则通过源对象该属性的readMethod获取到值，并通过目标对象writeMethod将该值写入目标对象，完成该属性的copy
  • 源对象不存在该属性则跳过

分析

• 通过源码可以知道，BeanUtil.copyProperties主要通过反射进行对象copy，这里的反射可简要概括为以下三个步骤：

  • Object.getClass()获取类
  • 通过获取到的类class.getMethod()获取到get，set方法
  • 通过get，set方法获取到值，并设置到目标对象

• 其中步骤2中的Method，从源码可知是通过缓存获取，获取不到则进行初始化加入缓存。所以这里猜测步骤2也比较消耗性能，所以做了这样一个缓存优化，下面对步骤2在反射中的性能影响作测试验证。

反射耗时探究

• 通过以下几种方式对对象进行设置，观察耗时：
  1. 通过实例直接设值
  2. 通过反射设置
  3. 通过反射设置，但将Method方法缓存起来，通过缓存获取Method方法设值
  4. 通过BeanUtil.copyProperties设值
• 

测试说明

• 其中测试对象只有2个属性，测试的这几种设值方式，都是通过对象B复制对象A属性值进行，详细每种方式的实现代码附在本文最后。

• 从源码可知，第一次调用时会有缓存等初始化操作，所以猜测第一次调用会比较耗时，但后续调用耗时会大大缩短，下图测试证明：

• 

• 由于spring项目在启动时，会将Bean的方法反射获得进行缓存，也就是做了上诉第二点的初始化，所以实际项目中可忽略初始化的耗时，因此在此次测试中，将手动调用一次进行初始化，避免初始化的耗时对测试结果产生影响，如下图：

• 

测试结果

• 

• 通过上诉测试数据可以发现，

  • 直接通过实例设置在各次数下，速度都是最快的。
  • 而通过缓存Method的方式，是一个较大的优化，速度只有直接反射的1/5到1/10
  • 通过反射设置和通过copyProperties设置 耗时相差无几
  • Ps：按理说copyProperties做了Method缓存优化，应该会比直接反射快，但这里耗时差不多，应该是copyProperties为了健壮性，多做了各种校验逻辑导致的（未细究）。

结论

• 通过反射进行对象间属性值copy，确实会比直接set更耗时
• copyProperties通过反射进行copy，虽然做了Method缓存优化，但实际耗时跟直接反射设置耗时差不多。
• 但是并不是说在项目中就一定要尽量避免使用反射，上诉测试是上百万次的调用，从测试情况来看，执行次数1百万时，使用反射比直接设值，总共耗时多了3000多ms，此次只copy了2个字段，总共调用100万次，则相当于进行了200万次字段copy。现假设实际开发中copy的Bean属性平均在10个字段，假设进行了10次copy，则单次接口调用进行了100次字段copy。那么200万次字段copy相当于进行了2万次的接口调用，那么3000ms/2万=0.15ms，也就是说每个接口由于使用反射进行字段copy，比不使用反射进行字段copy多耗时0.15ms。上诉情况是在测试数据的基础上做的不严谨推测，实际情况与推测数据有出入，但是如果没有更多理论上的偏差，出入不会有数量级的差距。个人认为这个多消耗的时间在绝大多数情况下是微不足道的，当然这个没有考虑对并发情况的影响，如果是并发调用上万次接口情况下，极端情况可能导致某些接口最长多耗时3000ms进行返回，但上万次的并发在实际生产中已经相当高了，此时多数会通过扩容，限流等其他手段进行优化，性能瓶颈不在反射。当然，实际生产过程中影响因素可能较多，需要进行测试分析性能瓶颈，有针对性地进行优化。