【小家java】Java反射性能问题，你真的需要考虑吗？

每篇一句

当一个人输球成为头条新闻的话，那么这个球员得有多么伟大啊

Java的反射，是我们进阶的敲门砖。反射肯定比直接调用慢，这个毋庸置疑了，我这篇文章也不是证明反射有多高效的。我举个快递小哥的例子：

举个栗子

如果快递员就在你住的小区，那么你报一个地址：xx栋xx号，那么快递员就可以马上知道你在哪里，直接就去到你家门口；但是，如果快递员是第一次来你们这里，他是不是首先得查查百度地图，看看怎么开车过去，然后到了小区是不是得先问问物管xx栋怎么找，然后，有可能转在楼下转了两个圈才到了你的门前。

分析

我们看上面这个场景，如果快递员不熟悉你的小区，是不是会慢点，他的时间主要花费在了查找百度地图，询问物业管理。OK，反射也是一样，因为我事先什么都不知道，所以我得花时间查询一些其他资料，然后我才能找到你。大家有兴趣可以查看反射的实现原理，以及MetaData的相关概念。

反射到底比直接调用慢多少?

好了，我们知道反射肯定慢的，那么是不是反射就不能用了呢？有些人一听到慢，就非常着急的下结论，反射怎样怎样不行，怎样怎样不能用。但是，同学，反射到底比直接调用慢多少，你造吗，能给我个实际的数据吗？很多人其实对性能只有个模糊的概念，而没有数值支撑。之前我给同事找了一个动态解析表达式的类库，他觉得不太好用，他很聪明，很快的找到了用DataTale.Compute可以实现公式的动态解析。我问他，这个方法和我给的类库性能上有什么区别？他跟我说，这个已经很快了，执行1秒都不到。我一听，就觉得不对劲，你的思想还停留在秒级，跟我谈什么性能? 怎么去判断一个函数的性能?因为函数的执行太快太快了，你需要一个放慢镜，这样才能捕捉到他的速度。怎么做？把一个函数执行一百万遍或者一千万遍，你才能真正了解一个函数的性能。也就是，你如果想判断性能，你就不能还停留在秒级，毫秒级的概念，你必须用另外一个概念替代，才能知道真正的性能。结果我同事把这两种方法执行了100w遍，确实，我提供的类库比他的快了8秒。 好了，现在拿我早两天提供的工厂方法来做测试，其中CodeTimer的实现参考赵大神的文章《一个简单的性能计数器：CodeTimer》： 测试方法如下：

相关示例代码 此处全部省略，重点看描述吧

看到没，我们的放大镜起作用了，现在我们大概可以下这么一个结论：在执行100万遍的时候，反射大概把直接调用慢50~100倍。100倍，咋一看，是相差很大的，但是，我前文说了，别着急下结论，你要看看前提条件。自古我们就喜欢断章取义，比如“以德报怨”这个成语，好像古人说让我们遇到不好的，你不能怨恨，要更好的对待他人，别人打你左脸一巴掌，你应该把右脸伸过去让他再打一下。但实际这个成语是怎样的呢？ 或曰：“以德报怨，何如？” 子曰：“何以报德？以直报怨，以德报德” 老孔的意思其实是如果别人对你好，那么你就对他好，要是他招你惹你了，你就干他娘的！你看，傻眼了吧？ 有多少情况下需要考虑反射带来的影响? 我认为这个情况是非常非常少的，绝大多数的我们根本就无需考虑这个。就上我上一篇文章提到的工厂，你程序有多少个实体，有100万个吗？如果你只是在弹出窗口的时候new一下，这个百万分之十秒的影响对你很重要吗？ 另外，有些人讲，我要是真有这种需求，要把一个对象new一百万遍，那不还是慢吗？这种情况有没有，有！比如我有100w条记录，需要取出来，然后通过反射赋值到一个Model类中。 但是对于这种情况，如果你真是这么想的话，我只能说，你坐办公室坐久了，脑袋生锈了，该去爬爬山，泡泡妞了。如果你需要对一个对象反射一百万遍，那么你就应该缓存这个对象了。拿我们上面那个例子来说，如果这个快递员给小区的人送一百万遍的快递还认不得路，每次都还得百度地图，然后问物业管理，你丫的你还没把他开掉了，那你脑袋不是秀逗了，要不就是任性的有钱人。 上面代码如果缓存之后执行一百万遍，跟直接调用有多大的区别？我这里就不贴代码了，免得你们直接看结果没有意思，自己把代码敲一遍，印象更深刻。 那么，还有没有更快的办法，有。比如你的快递员开始用的是IPHONE4，现在可以考虑给他买个6+。在.net中，提供了Emit的相关方法来让你更快的反射。这里送你一个通过反射快速给Model赋值的轮子“Dapper”，自己回家造去。 编程中是否应该使用反射？ 其实看完上面的文字，我相信你们都有了一个初步的判断，而我的看法是：绝大多数的情况下你都可以用反射。 如果你觉得是因为反射导致你程序慢的话，那么，请先用放慢镜好好观察一下，到底是不是反射的问题。如果你确定是反射的问题，那么你再好好的考虑下是不是你没有用对反射，是不是像上面那个走了一百万遍都不认识路的快递员一样。最后，如果你觉得性能上还是不够，那么我建议你升级下硬件吧，把硬件性能上升个3%总好过你请个牛逼的工程师来帮你做这种极限的优化，有一句话我觉得很对“工程师比服务器要昂贵的多”。如果你还非得跟我较劲，那么，没办法了，你程序对性能的要求已经超出了本文讨论的范畴，如果你真有这种需求了，我觉得你也没有必要看我这篇文章了，因为你已经足够牛逼到对系统语言都有深入了解了。 大多时候，我们会把程序的性能归结于编程语言，或者使用了反射等技术，而甚少去关心自己的代码，这种心态会导致你技术的发展越来越缓慢，因为你已经失去了求知的欲望，以及一颗追求技术进步的心。请你记住，更多的时候，影响我们程序性能的，是你编程的思想，你对待编码的态度！

总结

说了这么多，估计很多人直接就拖到文章末尾然后因为文章码了这么多字而默默点了个赞，那么，我在最后给大家奉献一下本文的精华：

反射大概比直接调用慢50~100倍（JDK7以后对反射有优化，大概在5倍到20倍不等了），但是需要你在执行100万遍的时候才会有所感觉

如果你想判断一个函数的性能，你需要把这个函数执行100万遍甚至1000万遍，

**如果你只是偶尔调用一下反射，请忘记反射带来的性能影响，如果你需要大量调用反射，请考虑缓存。**你的编程的思想才是限制你程序性能的最主要的因素