深入分析 JVM 执行引擎

程序和机器沟通的桥梁

一、闲聊

相信很多朋友在出国旅游，或者与外国友人沟通的过程中，都会遇到语言不通的烦恼。这时候我们就需要掌握对应的外语或者拥有一部翻译机。而笔者只会中文，所以需要借助一部翻译器才能与不懂中文的外国友人交流。咱们的执行引擎就类似于这部“翻译机”。

二、概述

执行引擎的作用就是将字节码指令解释或者编译为对应平台上的本地机器指令。简单来说，执行引擎充当了将高级语言翻译为机器语言的翻译者。对于 Hotspot 虚拟机，执行引擎中包含两部分：解释器和 JIT 编译器（即时编译器）。下图是执行引擎的原理：

三、解释器

解释器所承担的角色就是一个运行时翻译者，将字节码文件中的内容翻译为对应平台的本地机器码指令。当一条字节码指令被解释执行后，接着再根据 pc 寄存器中记录的下一条需要被执行的字节码指令执行解释操作。JVM 解释器一共有两套，一套是远古的字节码解释器，另一套是现在普遍使用的模板解释器。

1、字节码解释器

字节码解释器在执行过程中通过纯软件代码模拟字节码执行，效率非常低。

2、模板解释器

模板解释器将每一条字节码和一个模板函数关联，模板函数中直接产生这条字节码指令执行时的机器码，从而提高了解释器的性能。在常用的 HotSpot VM 中，解释器主要由 Interpreter 模板和 code 模块构成。Interpreter 模板：实现了解释器的核心功能。code 模块：用于管理 HotSpot VM 在运行时生成的本地机器码指令。

四、即时编译器（JIT 编译器）

即时编译器的目的是避免函数被解释执行，而是将整个函数体编译成机器码指令，每次函数执行时，只执行编译后的机器码即可，这种方式可以大大的提高效率。

1、热点代码及探测方式

当然，是否需要 JIT 编译器将字节码直接编译成对应平台的机器码，需要根据代码被调用的执行频率而定。需要被 JIT 编译器编译成机器码的字节码，也称为热点代码，JIT 编译器会对热点代码做出深度优化，将其从字节码编译成机器码，并缓存到方法区，提高代码的执行效率。JIT 编译的方式发生在方法执行过程中，因此也被称之为_栈上替换_，或简称 OSR(On Stack Replacement)编译。通过热点探测的方法，判断一个方法被调用多少次，或循环体执行多少次才可以达到阈值，进行编译。而 Hotspot VM 热点探测的方式是基于计数器实现的。这种基于技术的热点探测方式又分为两种：1.方法调用计数器 2.回边计数器

关于栈上替换这里笔者不展开赘述，有兴趣的小伙伴可以自行了解下

1.1 方法调用计数器

方法调用计数器用于统计方法调用次数，它的默认阈值是 client 模式下是 1500 次，在 server 模式下是 10000 次。超过这个阈值，就会触发 JIT 编译。当然，这个阈值也可以通过修改虚拟机参数-XX:CompileThreshold来手动指定。当一个方法被调用的时候，会优先检查该方法是否被 JIT 编译过，如果存在，则优先使用编译过的本地代码来执行，如果不存在，则将此方法的调用计数器加一，然后再判断计数器的值是否超过配置的阈值。如果已经超过了，就会向 JIT 编译器提交一个该方法的编译请求。下面是方法调用计数器执行的流程图：

关于方法调用计数器，如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对执行的频率。当超过一定的时间限度，如果方法的调用次数仍然达不到阈值，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器的热度衰减，而这段时间被称作为该方法的半衰周期。进行热度衰减的过程是虚拟机进行垃圾回收的时候顺便进行的，举手之劳而已。可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减。这样的话，只要运行时间足够长，绝大部分方法都会被编译成本地代码。最后，还可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，单位为秒。

1.2 回边计数器

它的作用是统计一个方法中循环体代码执行次数，在字节码中遇到控制流向后，跳转的指令称为“回边”。显然，建立回边计数器统计的目的是为了触发 OSR 编译。下面是回边计数器执行的流程图：

关于 OSR 编译上文中有提到

2、即时编译器分类

在 Hotspot VM 中，内嵌有两个 JIT 编译器，分别为 client compiler 和 server compiler，但是大多数情况下我们简称 C1 编译器和 C2 编译器。可以通过命令显示的指定 JVM 在运行时到底使用哪种 JIT 编译器。

2.1 c1 编译器

指定 Java 虚拟机运行在 client 模式下，使用 C1 编译器。C1 编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度，但是编译后的代码执行速度相对慢。C1 编译器主要有方法内联，去虚拟化，冗余消除。

1. 方法内联：将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程。

2. 去虚拟化：对唯一实现的类进行内联。

3. 冗余消除：在运行期间把一些不会执行的代码叠掉。

2.2 c2 编译器

指定 Java 虚拟机运行在 server 模式下，使用 C2 编译器。C2 编译器对代码优化时间长，编译时间也长。但是编译后的代码执行速度比较快。C2 的优化主要在全局层面，逃逸分析式优化的基础。基于逃逸分析，C2 上有如下几种优化：

1. 标量替换：用标量值代替聚合对象的属性值。

2. 栈上分配：对于未逃逸的对象分配在栈上而不是堆上。

3. 同步消除：清楚同步操作，通常指 synchronized。

2.3 Graal 编译器

JDK10 起，在 C1 编译器和 C2 编译器之后，HotSpot VM 新增了一个 Graal 即时编译器。编译效果短短几年的时间就追平了 C2 编译器。目前，带着“实验状态”标签，需要使用开关参数-XX:+UnlockExperimentalVMOptions，-XX:+UseJVMCICompiler去激活这个编译器，才能使用。

五、解释器和 JIT 并存

为什么需要解释器和 JIT 并存，原因有几点：

1. 当程序启动的时候，解释器可以马上发挥作用，省去编译的时间。

2. 编译器想要执行，需要把字节码编译成本地机器码，并且缓存编译后的机器码，编译需要一定的时间。

3. 编译后的本地机器码，执行效率高。所以，在两种并存的模式下，解释器首先发挥作用，而不必等到即时编译器全部编译完在执行，这样可以省去不必要的编译时间。

4. 随着程序继续不断运行，编译器发挥作用，根据热点探测功能，把越来越多的字节码编译成本地机器码，获得更高的执行效率。

六、执行引擎执行程序的方式

在默认的情况下，HotSpot VM 采用的是解释器和 JIT 编译器并存的架构，当然读者可以根据具体的应用场景，通过虚拟机参数，为虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。

1. -Xint：完全采用解释器模式执行程序

2. -XComp：完全采用即时编译器模式执行程序。如果即时编译器出现问题，解释器会介入执行；

3. -Xmixed：采用解释器+即时编译器的混合模式共同执行程序，HotStop VM 默认就是这个模式。

七、参考源码

编程文档：https://gitee.com/cicadasmile/butte-java-note
应用仓库：https://gitee.com/cicadasmile/butte-flyer-parent