• JVM总结-反射(待看,有些地方不是太懂)


    反射是 Java 语言中一个相当重要的特性,它允许正在运行的 Java 程序观测,甚至是修改程序的动态行为。

    在 Web 开发中,我们经常能够接触到各种可配置的通用框架。为了保证框架的可扩展性,它们往往借助 Java 的反射机制,根据配置文件来加载不同的类。举例来说,Spring 框架的依赖反转(IoC),便是依赖于反射机制

    然而,我相信不少开发人员都嫌弃反射机制比较慢。甚至是甲骨文关于反射的教学网页 [1],也强调了反射性能开销大的缺点。

    反射调用的实现

    首先,我们来看看方法的反射调用,也就是 Method.invoke,是怎么实现的。

    public final class Method extends Executable {
      ...
      public Object invoke(Object obj, Object... args) throws ... {
        ... // 权限检查
        MethodAccessor ma = methodAccessor;
        if (ma == null) {
          ma = acquireMethodAccessor();
        }
        return ma.invoke(obj, args);
      }
    }

    如果你查阅 Method.invoke 的源代码,那么你会发现,它实际上委派给 MethodAccessor 来处理。MethodAccessor 是一个接口,它有两个已有的具体实现:一个通过本地方法来实现反射调用,另一个则使用了委派模式。为了方便记忆,我便用“本地实现”和“委派实现”来指代这两者。

    每个 Method 实例的第一次反射调用都会生成一个委派实现,它所委派的具体实现便是一个本地实现。本地实现非常容易理解。当进入了 Java 虚拟机内部之后,我们便拥有了 Method 实例所指向方法的具体地址。这时候,反射调用无非就是将传入的参数准备好,然后调用进入目标方法。

    // v0 版本
    import java.lang.reflect.Method;
     
    public class Test {
      public static void target(int i) {
        new Exception("#" + i).printStackTrace();
      }
     
      public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("Test");
        Method method = klass.getMethod("target", int.class);
        method.invoke(null, 0);
      }
    }
     
    # 不同版本的输出略有不同,这里我使用了 Java 10。
    $ java Test
    java.lang.Exception: #0
            at Test.target(Test.java:5)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl .invoke0(Native Method)
     a      t java.base/jdk.internal.reflect.NativeMethodAccessorImpl. .invoke(NativeMethodAccessorImpl.java:62)
     t       java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.i .invoke(DelegatingMethodAccessorImpl.java:43)
            java.base/java.lang.reflect.Method.invoke(Method.java:564)
      t        Test.main(Test.java:131

    为了方便理解,我们可以打印一下反射调用到目标方法时的栈轨迹。在上面的 v0 版本代码中,我们获取了一个指向 Test.target 方法的 Method 对象,并且用它来进行反射调用。在 Test.target 中,我会打印出栈轨迹。

    可以看到,反射调用先是调用了 Method.invoke,然后进入委派实现(DelegatingMethodAccessorImpl),再然后进入本地实现(NativeMethodAccessorImpl),最后到达目标方法。

    这里你可能会疑问,为什么反射调用还要采取委派实现作为中间层?直接交给本地实现不可以么?

    其实,Java 的反射调用机制还设立了另一种动态生成字节码的实现(下称动态实现),直接使用 invoke 指令来调用目标方法。之所以采用委派实现,便是为了能够在本地实现以及动态实现中切换

    // 动态实现的伪代码,这里只列举了关键的调用逻辑,其实它还包括调用者检测、参数检测的字节码。
    package jdk.internal.reflect;
     
    public class GeneratedMethodAccessor1 extends ... {
      @Overrides    
      public Object invoke(Object obj, Object[] args) throws ... {
        Test.target((int) args[0]);
        return null;
      }
    }

    动态实现和本地实现相比,其运行效率要快上 20 倍 [2] 。这是因为动态实现无需经过 Java 到 C++ 再到 Java 的切换,但由于生成字节码十分耗时,仅调用一次的话,反而是本地实现要快上 3 到 4 倍 [3]

    考虑到许多反射调用仅会执行一次,Java 虚拟机设置了一个阈值 15(可以通过 -Dsun.reflect.inflationThreshold= 来调整),当某个反射调用的调用次数在 15 之下时,采用本地实现;当达到 15 时,便开始动态生成字节码,并将委派实现的委派对象切换至动态实现,这个过程我们称之为 Inflation。

    为了观察这个过程,我将刚才的例子更改为下面的 v1 版本。它会将反射调用循环 20 次。

    // v1 版本
    import java.lang.reflect.Method;
     
    public class Test {
      public static void target(int i) {
        new Exception("#" + i).printStackTrace();
      }
     
      public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("Test");
        Method method = klass.getMethod("target", int.class);
        for (int i = 0; i < 20; i++) {
          method.invoke(null, i);
        }
      }
    }
     
    # 使用 -verbose:class 打印加载的类
    $ java -verbose:class Test
    ...
    java.lang.Exception: #14
            at Test.target(Test.java:5)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl .invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl .invoke(NativeMethodAccessorImpl.java:62)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:564)
            at Test.main(Test.java:12)
    [0.158s][info][class,load] ...
    ...
    [0.160s][info][class,load] jdk.internal.reflect.GeneratedMethodAccessor1 source: __JVM_DefineClass__
    java.lang.Exception: #15
           at Test.target(Test.java:5)
           at java.base/jdk.internal.reflect.NativeMethodAccessorImpl .invoke0(Native Method)
           at java.base/jdk.internal.reflect.NativeMethodAccessorImpl .invoke(NativeMethodAccessorImpl.java:62)
           at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:43)
           at java.base/java.lang.reflect.Method.invoke(Method.java:564)
           at Test.main(Test.java:12)
    java.lang.Exception: #16
           at Test.target(Test.java:5)
           at jdk.internal.reflect.GeneratedMethodAccessor1 .invoke(Unknown Source)
           at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:43)
           at java.base/java.lang.reflect.Method.invoke(Method.java:564)
           at Test.main(Test.java:12)
    ...

    可以看到,在第 15 次(从 0 开始数)反射调用时,我们便触发了动态实现的生成。这时候,Java 虚拟机额外加载了不少类。其中,最重要的当属 GeneratedMethodAccessor1(第 30 行)。并且,从第 16 次反射调用开始,我们便切换至这个刚刚生成的动态实现(第 40 行)。

    反射调用的 Inflation 机制是可以通过参数(-Dsun.reflect.noInflation=true)来关闭的。这样一来,在反射调用一开始便会直接生成动态实现,而不会使用委派实现或者本地实现。

    反射调用的开销

    下面,我们便来拆解反射调用的性能开销。

    在刚才的例子中,我们先后进行了 Class.forName,Class.getMethod 以及 Method.invoke 三个操作。其中,Class.forName 会调用本地方法,Class.getMethod 则会遍历该类的公有方法如果没有匹配到,它还将遍历父类的公有方法。可想而知,这两个操作都非常费时。

    值得注意的是,以 getMethod 为代表的查找方法操作,会返回查找得到结果的一份拷贝。因此,我们应当避免在热点代码中使用返回 Method 数组的 getMethods 或者 getDeclaredMethods 方法,以减少不必要的堆空间消耗

    在实践中,我们往往会在应用程序中缓存 Class.forName 和 Class.getMethod 的结果。因此,下面我就只关注反射调用本身的性能开销。

    为了比较直接调用和反射调用的性能差距,我将前面的例子改为下面的 v2 版本。它会将反射调用循环二十亿次。此外,它还将记录下每跑一亿次的时间。

    我将取最后五个记录的平均值,作为预热后的峰值性能。(注:这种性能评估方式并不严谨,我会在专栏的第三部分介绍如何用 JMH 来测性能。)

    在我这个老笔记本上,一亿次直接调用耗费的时间大约在 120ms。这和不调用的时间是一致的。其原因在于这段代码属于热循环,同样会触发即时编译。并且,即时编译会将对 Test.target 的调用内联进来,从而消除了调用的开销。

    // v2 版本
    mport java.lang.reflect.Method;
     
    public class Test {
      public static void target(int i) {
        // 空方法
      }
     
      public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("Test");
        Method method = klass.getMethod("target", int.class);
     
        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
          if (i % 100_000_000 == 0) {
            long temp = System.currentTimeMillis();
            System.out.println(temp - current);
            current = temp;
          }
     
          method.invoke(null, 128);
        }
      }
    }

    这里我截取了循环中反射调用编译而成的字节码。可以看到,这段字节码除了反射调用外,还额外做了两个操作。

    第一,由于 Method.invoke 是一个变长参数方法,在字节码层面它的最后一个参数会是 Object 数组(感兴趣的同学私下可以用 javap 查看)。Java 编译器会在方法调用处生成一个长度为传入参数数量的 Object 数组,并将传入参数一一存储进该数组中。

    第二,由于 Object 数组不能存储基本类型,Java 编译器会对传入的基本类型参数进行自动装箱。

    这两个操作除了带来性能开销外,还可能占用堆内存,使得 GC 更加频繁。(如果你感兴趣的话,可以用虚拟机参数 -XX:+PrintGC 试试。)那么,如何消除这部分开销呢?

    关于第二个自动装箱,Java 缓存了 [-128, 127] 中所有整数所对应的 Integer 对象。当需要自动装箱的整数在这个范围之内时,便返回缓存的 Integer,否则需要新建一个 Integer 对象。

    因此,我们可以将这个缓存的范围扩大至覆盖 128(对应参数
    -Djava.lang.Integer.IntegerCache.high=128),便可以避免需要新建 Integer 对象的场景。

    或者,我们可以在循环外缓存 128 自动装箱得到的 Integer 对象,并且直接传入反射调用中。这两种方法测得的结果差不多,约为基准的 1.8 倍。

    现在我们再回来看看第一个因变长参数而自动生成的 Object 数组。既然每个反射调用对应的参数个数是固定的,那么我们可以选择在循环外新建一个 Object 数组,设置好参数,并直接交给反射调用。改好的代码可以参照文稿中的 v3 版本。

    // v3 版本
    import java.lang.reflect.Method;
     
    public class Test {
      public static void target(int i) {
        // 空方法
      }
     
      public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("Test");
        Method method = klass.getMethod("target", int.class);
     
        Object[] arg = new Object[1]; // 在循环外构造参数数组
        arg[0] = 128;
     
        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
          if (i % 100_000_000 == 0) {
            long temp = System.currentTimeMillis();
            System.out.println(temp - current);
            current = temp;
          }
     
          method.invoke(null, arg);
        }
      }
    }

    测得的结果反而更糟糕了,为基准的 2.9 倍。这是为什么呢?

    如果你在上一步解决了自动装箱之后查看运行时的 GC 状况,你会发现这段程序并不会触发 GC。其原因在于,原本的反射调用被内联了,从而使得即时编译器中的逃逸分析将原本新建的 Object 数组判定为不逃逸的对象。

    如果一个对象不逃逸,那么即时编译器可以选择栈分配甚至是虚拟分配,也就是不占用堆空间。具体我会在本专栏的第二部分详细解释。

    如果在循环外新建数组,即时编译器无法确定这个数组会不会中途被更改,因此无法优化掉访问数组的操作,可谓是得不偿失。

    到目前为止,我们的最好记录是 1.8 倍。那能不能再进一步提升呢?

    刚才我曾提到,可以关闭反射调用的 Inflation 机制,从而取消委派实现,并且直接使用动态实现。此外,每次反射调用都会检查目标方法的权限,而这个检查同样可以在 Java 代码里关闭,在关闭了这两项机制之后,也就得到了我们的 v4 版本,它测得的结果约为基准的 1.3 倍。

    // v4 版本
    import java.lang.reflect.Method;
     
    // 在运行指令中添加如下两个虚拟机参数:
    // -Djava.lang.Integer.IntegerCache.high=128
    // -Dsun.reflect.noInflation=true
    public class Test {
      public static void target(int i) {
        // 空方法
      }
     
      public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("Test");
        Method method = klass.getMethod("target", int.class);
        method.setAccessible(true);  // 关闭权限检查
     
        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
          if (i % 100_000_000 == 0) {
            long temp = System.currentTimeMillis();
            System.out.println(temp - current);
            current = temp;
          }
     
          method.invoke(null, 128);
        }
      }
    }

    总结与实践

    今天我介绍了 Java 里的反射机制。

    在默认情况下,方法的反射调用为委派实现,委派给本地实现来进行方法调用。在调用超过 15 次之后,委派实现便会将委派对象切换至动态实现。这个动态实现的字节码是自动生成的,它将直接使用 invoke 指令来调用目标方法。

    方法的反射调用会带来不少性能开销,原因主要有三个:变长参数方法导致的 Object 数组,基本类型的自动装箱、拆箱,还有最重要的方法内联。

  • 相关阅读:
    java获取指定文件夹下的所有文件名
    org.dom4j.DocumentException: unknown protocol: d Nested exception: unknown
    如何在spring中获取request对象
    Java获取文件后缀名
    解析XML并将信息封装到对象中
    在web项目启动时执行某个方法
    Maven Dependencies没有了的解决办法
    B-树(B+树) 学习总结
    Netty学习笔记之一(Netty解析简单的Http Post Json 请求)
    用到的设计模式总结--单例模式+工厂方法模式+Builder模式
  • 原文地址:https://www.cnblogs.com/yintingting/p/8807242.html
Copyright © 2020-2023  润新知