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.noInflation=true，在反射调用一开始便会直接生成动态实现
• 这个动态实现就是上图出现的 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数组
• 基本类型的自动装箱和拆箱
• 方法内联