引言 #
最近在业务代码中经常用到的BeanUtils.copyProperties，有的时候在想，这个东西在Java里面真方便，但是性能怎么样呢，然后找了一篇博文
https://www.cnblogs.com/kancy/p/12089126.html
大吃一斤，竟然要100多ms，我们接口压测性能也就40ms左右，调用这么个方法竟然耗时要这么多，本着不传谣不信谣的精神，开始下面的测试
步骤 #
首先我用Python生成两个大类A，B，两个字段数都为254（因为Java最大属性就是255），然后生成一个类C，其中有个静态方法，能将A的值全部都赋给B
最后我跑了一下结果
下面是结果
bean复制
热身🚀 1100次耗时: 264.00000毫秒 速度： 0.24000毫秒每次
正式🚀 1000000次耗时: 14383.00000毫秒 速度： 14.38300微秒每次
硬复制
热身🚀 1100次耗时: 12.00000毫秒 速度： 0.01091毫秒每次
正式🚀 1000000次耗时: 116.00000毫秒 速度： 0.11600微秒每次
因为JVM有热加载技术，所以我运行前都让它热个身，结果很哇塞，的确BeanUtils的速度要比硬copy要慢100倍左右，但是其实对于程序来说，14微妙也是非常快了，其实除非你在一次请求里面要用这个方法上百次，其实问题都不大
疑惑 #
但是我又有个疑惑了，为啥bean复制最开始的1100次要耗时那么那么长，到底发生了什么，接下来我把热身的时候，蜂刺数据提取出来（上一次执行耗时和这次执行差距1ms），结果如下
0 cost: 10
1 cost: 0
15 cost: 95
16 cost: 2
17 cost: 0
127 cost: 2
128 cost: 0
我执行了很多次，在第0次的时候，和第14、15、16这些的时候都会耗时巨长，第一次可能是因为建立反射缓存，但是第14、15、16为啥会耗时那么长呢
接下来我们深入源代码看看，为啥会这样
源码探索 #
源码在 org.springframework.beans.BeanUtils.copyProperties 中
private static void copyProperties(Object source, Object target, @Nullable Class<?> editable, @Nullable String... ignoreProperties) throws BeansException {
Assert.notNull(source, "Source must not be null");
Assert.notNull(target, "Target must not be null");
Class<?> actualEditable = target.getClass();
if (editable != null) {
if (!editable.isInstance(target)) {
throw new IllegalArgumentException("Target class [" + target.getClass().getName() + "] not assignable to Editable class [" + editable.getName() + "]");
}
actualEditable = editable;
}
PropertyDescriptor[] targetPds = getPropertyDescriptors(actualEditable);
List<String> ignoreList = ignoreProperties != null ? Arrays.asList(ignoreProperties) : null;
PropertyDescriptor[] var7 = targetPds;
int var8 = targetPds.length;
for(int var9 = 0; var9 < var8; ++var9) {
PropertyDescriptor targetPd = var7[var9];
Method writeMethod = targetPd.getWriteMethod();
if (writeMethod != null && (ignoreList == null || !ignoreList.contains(targetPd.getName()))) {
PropertyDescriptor sourcePd = getPropertyDescriptor(source.getClass(), targetPd.getName());
if (sourcePd != null) {
Method readMethod = sourcePd.getReadMethod();
if (readMethod != null && ClassUtils.isAssignable(writeMethod.getParameterTypes()[0], readMethod.getReturnType())) {
try {
if (!Modifier.isPublic(readMethod.getDeclaringClass().getModifiers())) {
readMethod.setAccessible(true);
}
Object value = readMethod.invoke(source);
if (!Modifier.isPublic(writeMethod.getDeclaringClass().getModifiers())) {
writeMethod.setAccessible(true);
}
writeMethod.invoke(target, value);
} catch (Throwable var15) {
throw new FatalBeanException("Could not copy property '" + targetPd.getName() + "' from source to target", var15);
}
}
}
}
}
}
借助arthas我们可以知道第一次加载慢是因为耗时都在 getPropertyDescriptors 上面，第一次的时候需要通过反射去获取，这个时间在我电脑上要5-10ms左右，之后再次运行相同的类就不需要这么长，但是为什么在15-16次会有一次比第一次还要长的耗时呢，araths的结果我们就不粘贴了，其中其实耗时都不长，耗时99%的时候都在 java.lang.reflect.Method:invoke 这个方法上
我们知道反射慢是正常的，为啥到了15次之后就没有速度慢的呢，原因是JVM会对发射做一个优化，当请求同一个反射超过15次之后，就会编译成字节码，所以之后速度就起飞，但是由于第一次要生成字节码，所以它耗时还要比第一次通过反射获取的还要慢
具体资料为：https://blog.csdn.net/zhang6622056/article/details/98950855
总结 #
通过这个实验，我们知道，原来即使使用反射，其实JVM的速度也能优化到几微秒，假如你的类不超过50个字段，其实硬编码和Bean复制其实差别不大，你追求的极致优化其实都是优化几微秒，相比于网络的ms优化简直不值一提，而且目前其实也有很多优秀的框架，如JMapper,MapStruct 等可以生成字节码，而不需要你硬编码