BeanUtil.copyProperties真的很慢吗？

叁歲伎倆 2024-05-23 22:20 45阅读 0赞

## BeanUtil.copyProperties真的很慢吗？ ##

### BeanUtil.copyProperties性能探究 ###

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

### 源码探究 ###

*  通过copyProperties（）方法作为入口进行源码阅读
 *  ![在这里插入图片描述][05f7eef71c594df7b5c11fb3bb239df1.png]
 *  ![在这里插入图片描述][ffb5493b2f954c8ab5f797cc5bfd871d.png]
 *  ![在这里插入图片描述][a138c7d9cb3f44f29e272608393ae782.png]
 *  ![在这里插入图片描述][b12ab17ad8484a289ad18e44c53967db.png]
 *  ![在这里插入图片描述][44ebb63d18884155b10615b14b4f7dfd.png]
 *  ![在这里插入图片描述][8a55f87c093a47259963c4e5e51af2f4.png]
 *  ![在这里插入图片描述][0affe67a0dcc490dba814311d11670d2.png]

#### 简要总结 ####

*  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设值
 *  ![在这里插入图片描述][b8e13f3278f74dc5ad9a7655cc07e36a.png]

#### 测试说明 ####

*  其中测试对象只有2个属性，测试的这几种设值方式，都是通过对象B复制对象A属性值进行，详细每种方式的实现代码附在本文最后。
 *  从源码可知，第一次调用时会有缓存等初始化操作，所以猜测第一次调用会比较耗时，但后续调用耗时会大大缩短，下图测试证明：
 *  ![在这里插入图片描述][c4c4b0f84a3c4c0ab3ead0ccd32be103.png]
 *  由于spring项目在启动时，会将Bean的方法反射获得进行缓存，也就是做了上诉第二点的初始化，所以实际项目中可忽略初始化的耗时，因此在此次测试中，将手动调用一次进行初始化，避免初始化的耗时对测试结果产生影响，如下图：
 *  ![在这里插入图片描述][195e9f81d52c4119a68327801e291f8b.png]

#### 测试结果 ####

*  ![在这里插入图片描述][2ad902b6680b41b69f642317093492c4.png]
 *  通过上诉测试数据可以发现，
    
     *  直接通过实例设置在各次数下，速度都是最快的。
     *  而通过缓存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进行返回，但上万次的并发在实际生产中已经相当高了，此时多数会通过扩容，限流等其他手段进行优化，性能瓶颈不在反射。当然，实际生产过程中影响因素可能较多，需要进行测试分析性能瓶颈，有针对性地进行优化。

[05f7eef71c594df7b5c11fb3bb239df1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/9ca38194534c46829005e475aa8e3a88.png
[ffb5493b2f954c8ab5f797cc5bfd871d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/630b23e2c72449d5ad695846fd44e522.png
[a138c7d9cb3f44f29e272608393ae782.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/7ba4b53901bf4b82804cbc78cdace89d.png
[b12ab17ad8484a289ad18e44c53967db.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/e261208ddb7a4f3aadcf168734ebcc8e.png
[44ebb63d18884155b10615b14b4f7dfd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/6f6a6e6c07e745f39843366fa8cf1082.png
[8a55f87c093a47259963c4e5e51af2f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/c4c7d6c5783d4e8ea3ed707981987122.png
[0affe67a0dcc490dba814311d11670d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/e101455b9f0846c59b369e5e182870f5.png
[b8e13f3278f74dc5ad9a7655cc07e36a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/6d17b73860654aeaab1562f4107ac2fd.png
[c4c4b0f84a3c4c0ab3ead0ccd32be103.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/66f1fb0d0fd34146b27cba761dfccfcb.png
[195e9f81d52c4119a68327801e291f8b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/fcdbbdb171d64118ae807c78e5646667.png
[2ad902b6680b41b69f642317093492c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/23/665c062f51f3481791496046e89449ad.png