Java反射性能优化

　　先来看看java。lang。reflect。Method里的invoke方法：
　　java。lang。reflect。Method的invoke方法
　　注意，MethodAccessor接口有两个实现：NativeMethodAccessorImpl，通过本地方法来实现反射调用DelegatingMethodAccessorImpl，使用了委派模式
　　打印反射调用堆栈信息：
　　反射调用堆栈信息
　　从堆栈信息可以看到，Method实例的第一次反射调用会生成一个委派实现，它所委派的具体实现是一个本地实现。
　　为什么反射调用要采取委派实现作为中间层？为什么不直接交给本地实现？
　　实际上，Java的反射调用机制还有一种动态生成字节码的实现（以下简称为动态实现），简单来说，就是直接使用invoke指令来调用目标方法。
　　之所以采用委派实现作为中间层，是为了能够在本地实现以及动态实现中切换。
　　动态实现的运行效率要优于本地实现，这是因为动态实现无需经过Java到C再到Java的切换，但是由于生成字节码十分耗时，仅调用一次的话，反而是本地实现要快上3到4倍。
　　达到多少次才切换呢？
　　在本地实现和动态实现中切换
　　说明：通过sun。reflect。inflationThreshold这个参数控制，默认值是15切换成动态实现这个过程称为Inflation，所以还可以通过设置Dsun。reflect。noInflationtrue，在反射调用一开始便会直接生成动态实现这个动态实现就是上图出现的GeneratedMethodAccessor1
　　接下来我们借助JMH测试一下直接调用方法和反射调用方法的性能：
　　JMH测试直接调用方法和反射调用方法的性能
　　从上面的测试结果可以看到，直接调用方法的性能大概是反射调用方法的17倍。
　　注意，在调用目标方法时，传入的参数是66，如果超出〔128，127〕这个范围（可以通过参数java。lang。Integer。IntegerCache。high或者XX：AutoBoxCacheMax调整上限），将不会使用IntegerCache，而是每次调用新建一个Integer对象。
　　另外，java。lang。reflect。Method的invoke方法接收的是变长参数，下边是相关字节码：
　　invoke方法接收变长参数的字节码
　　可以看到，每次调用都会生成一个长度为1的Object数组。
　　接下来，我们进一步优化，因为传入参数可以认为是固定不变的，所以我们提前创建好这个Object数组，然后直接传给invoke方法：
　　传入提前创建好的Object数组
　　可以看到，直接调用方法的性能大概是这一轮优化后的反射调用的10倍。
　　再进一步，我们关闭反射调用的Inflation机制，直接使用动态实现：
　　关闭反射调用的Inflation机制
　　结果如下：
　　性能测试结果
　　可以看到，直接调用方法的性能大概是第二轮优化后的反射调用的9倍。
　　可是我们真实的使用场景往往没有这么理想和简单，我们很有可能对多个方法做反射调用，如下图所示：
　　对多个方法做反射调用
　　在做benchmark测试前，对另外两个方法做了2000次反射调用，然后我们之前优化后的反射调用性能大幅降低。
　　为什么会这样呢？
　　只对target这一个方法做反射调用，方法内联情况如下图所示：
　　只对一个方法做反射调用的内联情况
　　对target2和target3这两个方法做2000次反射调用后，再反射调用target方法，方法内联情况如下图所示：
　　对多个方法做反射调用的内联情况
　　简单来说，当我们榨干了反射调用的水分后，即时编译器中的方法内联将决定反射的性能。在关闭了Inflation的情况下，内联的瓶颈在于Method。invoke方法中对MethodAccessor。invoke方法的调用，如下图所示：
　　内联瓶颈
　　说明：
　　对于invokevirtual或者invokeinterface，JVM会记录下调用者的具体类型，即类型Profile
　　上述调用点（CallSite）的类型Profile无法同时记录这么多个类（XX：TypeProfileWidth默认值为2），而在C2中，如果类型Profile是不完整的，即时编译器压根不会进行条件去虚化，而是直接使用内联缓存或者方法表，因此可能造成所测试的反射调用没有被内联的情况
　　综上所述，影响反射性能的主要原因有3个：变长参数方法导致新建Object数组基本类型的自动装箱和拆箱方法内联