晚期（运行期）优化

在部分的商用虚拟机中，Java程序最初是通过解释器进行解释执行的，当虚拟机发现莫格方法或代码的运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器。

即时编译器并不是虚拟机必须的一部分，Java虚拟机规范并没有规定Java虚拟机内必须要有即时编译器存在，跟没有限定或指导即时编译器应该如何去实现。但是，即时编译性能的好坏，代码优化程度的高低却是衡量一款商用虚拟机优秀与否的关键的指标之一，它也是虚拟机最核心且最能体现虚拟机技术水品的部分。

由于Java虚拟机规范并没有具体的约束规则去限制即时编译器应该如何实现，所以这部分共功能完全是与虚拟机具体实现相关的内容。

HotSpot虚拟机内的即时编译器

我们将要了解HotSpot虚拟机内的即时编译器的运作过程，同时，还要解决以下几个问题：

• 为何HotSpot虚拟机要使用解释器与编译器并存的架构？
• 为何HotSpot虚拟机要实现两个不同的即时编译器？
• 程序何时使用解释器执行？何时使用编译器执行？
• 哪些程序代码会被便以为本地代码？如何编译为本地代码？
• 如何从外部观察即时编译器的编译过程和编译结果？

解释器与编译器

尽管并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机都同时包含解释器与编译器。解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候能提升运行速度的优化手段，当激进化的假设不成立，如加载了新类型继承结构出现变化，出现“罕见陷阱”时可以通过逆优化退回到解释状态继续执行，因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作。

HotSpot虚拟机中内置了两个即时编译器，分被称为Client Compiler和Server Compiler，或者简称为C1编译器和C2编译器（也叫Opto编译器）。目前主流的HotSpot虚拟机中，默认采用计时器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本于宿主集器的硬件性能自动选择运行模式。

无论采用的编译器是Client Compiler还是Server Compiler，解释器于编译器搭配使用的方式在虚拟机中称为“混合模式”，用户可以使用“-Xint”强制虚拟机运行于“解释模式”，这是编译器完全不介入工作，全部代码都是用解释方式执行。另外，也可以使用参数“-Xcomp”强制虚拟机运行于“编译模式”，这时将优先采用编译方式执行程序，但是解释器仍然要在编译器无法进行的情况下介入执行过程。

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程序更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度于运行效率之间达到最佳平衡，HopSpot虚拟机还会逐渐启用分层编译的策略，分层变异的概念在JDK1.6时期出现，后来一直处于改进阶段，最终在JDK1.7的server模式虚拟机中作为默认编译策略被开启。分层编译根据编译器编译，优化的规模于耗时，划分出不同的编译层次，其中包括：

• 第0层，程序解释执行，解释器不开启性能监控功能，可触发第一层编译。
• 第1层，也称为C1编译，将字节码编译为本地代码，进行简单，可靠的优化，如有必要将加入性能监控的逻辑。
• 第2层（或者2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会开启用一些编译耗时较长的优化，甚至会根据性能检测控制信息进行一些不可靠的激进优化。

实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解析执行的时候页无需在承担收集性能监控信息的任务。

编译对象与触发条件

在运行过程中会被即时编译的“热点代码”有两类，即：

• 被多次调用的方法。
• 被多次执行的循环体。

前者很好理解，一个方法被调用的多了，方法体内代码执行的次数自然就多，它成为“热点代码”是理所当然的。而后者则是为了解决一个方法智能被调用一次或者少量几次，但是方法体内部在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是“热点代码”。

对于第一种情况，由于是方法调用触发的编译，一次编译器理所当然的会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程中，因此形象的称之为栈上替换（即方法栈帧还在栈上，方法就被替换了）。

无论是“多次执行的方法”，还是“对此执行的代码块”，所谓“多次”都不是一个具体，严谨的用语，那到底多少次才算“多次”呢？还有一个问题，就是虚拟机如何统计一个方法或者一段代码被执行多多少此呢？解决了这两个问题，也就回答了即时编译器被触发的条件。

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测，其实进行热点探测并不一定要知道方法具体被调用多少次，目前主要的热点探测判定方式有两种，分别如下：

• 基于采样的热点探测：采用这种方法的虚拟机会周期性的检测各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”。基于采样的热点探测的好处是实现简单，高效，还可以很容易的获取方法调用关系（将调用堆栈展开即可），缺点是很难精确的确认一个方法的热度，容易因为受到线程阻塞或者别的外界因素的影响而扰乱热点探测。
• 基于计数器的热点探测：采用这种方法的虚拟机会为每个方法（甚至代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点代码”。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。

在HotSpot虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器。

在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

我们首先来看看方法调用计数器。顾名思义，这个计数器就是用于统计方法被调用的次数，它的默认阈值在Client模式下是1500此，在Server模式下是10000次。当一个方法被调用时，会检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已经超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器暗战解释方式执行字节码，知道提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下次调用该方法时就会使用已编译的版本。

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器会被减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的。

现在我们再来看看另外一个计数器——回边计数器，它的作用时统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”。显然，建立回边计数器统计的目的就是为了触发OSR编译。

当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，一边继续在解释器中执行循环，等待编译器输出变异结果。

与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会吧方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行便准编译过程。