Java 程序编译与代码优化续

上一篇我们主要是介绍编译期的代码优化，今天来介绍一下运行期的代码优化。在部分的商用虚拟机中（Sun HotSpot、IBM J9），Java 程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块运行的特别频繁时，就会把这些代码认定为『热点代码』（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码并进行优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，JIT 编译器）。

概述

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

即时编译器

由于 Java 虚拟机规范没有具体的规则去限制即时编译器应该如何实现，所以这部分功能完全依赖于虚拟机的具体实现，如无特殊说明，本文提及的编译器、即时编译器都是指 HotSpot 虚拟机内的即时编译器，虚拟机也是特指 HotSpot 虚拟机。

解释器与编译器

解释器

尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如 HotSpot、J9 等，都同时包含解释器与编译器。解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样就可以获取更高的执行效率。

当程序运行环境中内存资源限制较大（如部分嵌入式系统），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化时的一个『逃生门』，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现『罕见陷阱』（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的 C1 编译器担任『逃生门』的角色），因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作，下图所示。

解释器与编译器的交互

编译器

HotSpot 虚拟机中内置了两个即时编译器，分别称为 Client Compiler 和 Server Compiler，或者简称为 C1 编译器和 C2 编译器。在 HotSpot 虚拟机中，默认采用解释器与其中一个编译器互相配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式。

无论采用的编译器是 Client Compiler 还是 Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为『混合模式』（Mixed Mode），用户可以使用参数 -Xint 强制虚拟机运行于『解释模式』（Interpreted Mode），这时编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数 -Xcomp 强制虚拟机运行于『编译模式』（Compiled Mode），这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，可以通过虚拟机的 -version 命令显示出这 3 种模式。

3 种模式

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

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

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

编译对象与触发条件

编译对象

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

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

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

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

触发条件

判断一段代码是不是热点代码、是否需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection）。目前主要的热点探测判定方式有两种，分别如下：

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

HotSpot 虚拟机中使用的是第二种——基于计数器的热点探测方法，它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值了，就会触发JIT编译。

方法调用计数器

顾名思义，这个计数器就用于统计方法被调用的次数，它的默认阈值在 Client 模式下是 1500 次，在 Server 模式下是 10000 次，这个阈值可以通过虚拟机参数 -XX:CompileThreshold 来设定。当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在被 JIT 编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果超过阈值，将会向即时编译器提交一个编译该方法的请求。

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

方法调用计数器

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。热度衰减这个动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX:-UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用 -XX:CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。

回边计数器

它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为『回边』（Back Edge）。当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已编译版本的代码，否则就把回边计数器的值加 1，然后判断方法调用计数器与回边计数器值之和是否超过阈值。当超过阈值时，将会提交一个 OSR 编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果，整个执行过程如下图所示。

回边计数器

与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环体执行的绝对次数。当回边计数器值超过阈值时，它还会把方法计数器的值也调整为超过阈值，这样下次再进入该方法的时候就会执行标准的 JIT 编译过程。

查看及分析即时编译结果

OSR

一般来说，虚拟机的即时编译过程对用户程序是完全透明的，虚拟机通过解释执行代码或者通过编译执行代码，对于用户来说并没有什么影响（执行结果没有影响，但速度上会有差别），在大多数情况下用户也没有必要知道。但是虚拟机也提供了一些参数用来输出即时编译和某些优化手段（如方法内联）的执行状况，本节将介绍如何从外部观察虚拟机的即时编译行为。

本节中提到的运行参数有一部分需要 Debug 或 FastDebug 版虚拟机的支持，Product 版的虚拟机无法使用这部分参数。Mac 用户可以参照这篇文章来构建属于自己的 JDK，或者去网上下载已经构建好的 JDK。注意，本节中所有的测试都基于示例 1 中的代码。

代码示例 1

/**
 * 1.可以使用参数 -XX:+PrintCompilation 要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来。
 * jvm 参数: -XX:+PrintCompilation
 *
 * 2.可以加上参数 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 要求虚拟机输出方法内联信息。
 * jvm 参数: -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining
 *
 * 3.使用自己编译的 JDK 10，可以加参数。
 * jvm 参数: -XX:+PrintOptoAssembly -XX:+PrintCFGToFile
 *
 * 4.使用 Ideal Graph Visualizer 工具。
 * jvm 参数: -XX:PrintIdealGraphLevel=2 -XX:PrintIdealGraphFile=ideal.xml
 *
 */
public class TestJIT {
    public static final int NUM = 15000;

    public static int doubleValue(int i) {
        for (int j = 0; j < 1000000; j++) {
        }
        return i * 2;
    }

    public static long calcSum() {
        long sum = 0;
        for (int i = 0; i < 100; i++) {
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++) {
            calcSum();
        }
    }
}

首先运行这段代码，并且需要确认这段代码是否触发了即时编译。如果想知道某个方法是否被 JIT 编译过，可以使用参数 -XX:+PrintCompilation 要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来，如下图所示。（其中带有 % 的说明是由回边计数器触发的 OSR 编译）。

OSR 栈上替换

方法内联

我们还可以加上参数 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 来要求虚拟机输出方法内联的信息，如下所示。

方法内联

本地机器码

除了查看哪些方法被编译之外，还可以进一步查看即时编译器生成的机器码内容，不过如果虚拟机输出一串 0 和 1，对于我们来说是没有意义的，机器码必须反汇编成基本的汇编语言才可能被阅读。使用自己编译的 JDK 10，再加上参数 -XX:+PrintOptoAssembly -XX:+PrintCFGToFile 可以输出本地机器码反汇编结果，其中包含了许多注释。

部分本地机器码的反汇编信息

本地代码的生成过程

如果想再进一步跟踪本地代码生成的具体过程，那还可以使用参数 -XX:+PrintCFGToFile（Client Compiler）或 -XX:PrintIdealGraphFile（Server Compiler）令虚拟机将编译过程中各个阶段的数据输出到文件中。下面以 Server Compiler 为例，一起来分析一下 JIT 编译器的代码生成过程。

Server Compiler 的中间代码表示是一种名为 Ideal 的 SSA 形式程序依赖图（ProgramDependence Graph），在 JVM 参数中加入 -XX:PrintIdealGraphLevel=2 -XX:PrintIdealGraphFile=ideal.xml，编译后将产生一个名为 ideal.xml 的文件，它包含了 Server Compiler 编译代码的过程信息，可以使用 Ideal Graph Visualizer 对这些信息进行分析。
ideal-xml 文件

用 Ideal Graph Visualizer 加载 ideal.xml 文件后，Outline 面板上将显示程序运行过程中编译过的方法列表，如下图所示。这里列出的方法是示例 1 中的代码，其中 doubleValue 方法出现了两次，这是由于该方法的编译结果存在标准 JIT 编译和 OSR 编译两个版本。
Ideal Graph Visualizer

在代码示例 1 中，笔者特别为 doubleValue 方法增加了一个空循环，这个循环对方法的运算结果不会产生影响，但如果没有任何优化，执行空循环会占用 CPU 时间，到今天还有许多程序设计的入门教程把空循环当做程序延时的手段来介绍，在 Java 中这样的做法真的能起到延时的作用吗？

展开方法根节点，可以看到下面罗列了方法优化过程的各个阶段（根据优化措施的不同，每个方法所经过的阶段也会有所差别）。我们先打开『After Parsing』这个阶段，JIT 编译器在编译一个 Java 方法时，首先要把字节码解析成某种中间表示形式，然后才可以继续做分析和优化，最终生成代码。『After Parsing』就是 Server Compiler 刚完成解析，还没有做任何优化时的 Ideal 图表示，图中每一个方块就代表了一个程序的基本块（Basic Block），而右侧的 Control Flow 则代表了基本块的执行逻辑。
After Parsing

这样我们要看空循环是否被优化，或者何时优化，只要观察代表循环的基本块是否被消除，或者何时消除就可以了。

要观察到这一点，可以在 Outline 面板上右键点击『Difference to current graph』，让软件自动分析指定阶段与当前打开的 Ideal 图之间的差异，如果基本块被消除了，将会以红色显示。对『After Parsing』和『PhaseIdealLoop 1』阶段的 Ideal 图进行差异分析，发现在『PhaseIdealLoop1』阶段循环操作被消除了，如图下图所示，这也就说明空循环实际上是不会被执行的。
PhaseIdealLoop 1

从『After Parsing』阶段开始，一直到最后的『Final Code』阶段，可以看到 doubleValue 方法的 Ideal 图从繁到简的过程，这也是 Java 虚拟机在尽力优化代码的过程。到了最后的『Final Code』阶段，不仅空循环的开销消除了，许多语言安全和 Safepoint 轮询的操作也一起消除了，因为编译器判断即使不做这些安全保障，虚拟机也不会受到威胁。

final-code

最后提醒一下读者，要输出 CFG 或 IdealGraph 文件，需要一个 Debug 版或 FastDebug 版的虚拟机支持，Product 版的虚拟机无法输出这些文件。

这里是一个相对比较全面的、在即时编译器中采用的优化技术列表，其中有经典的编译器优化手段，也有针对 Java 语言（准确地说是针对运行在 Java 虚拟机上的语言）本身进行的优化技术，感兴趣的同学可以自行阅读。

Java 与 C/C++ 的编译器对比

大多数程序员都认为 C/C++ 会比 Java 语言快，甚至觉得从 Java 语言诞生以来『执行速度缓慢』的帽子就应当扣在它的头顶，这种观点的出现是由于 Java 在刚出现的时候即时编译技术还不成熟，主要靠解释器执行的 Java 语言性能确实比较低下。但目前即时编译技术已经十分成熟，Java 语言有可能在速度上与 C/C++ 一争高下吗？要想知道这个问题的答案，让我们从两者的编译器谈起。

Java 与 C/C++ 的编译器对比实际上代表了即时编译器与静态编译器的对比，很大程度上也决定了 Java 与 C/C++ 的性能对比的结果，因为无论是 C/C++ 还是 Java 代码，最终编译之后被机器执行的都是本地机器码，哪种语言的性能更高，除了它们自身的 API 库实现得好坏以外，其余的比较就成了一场『拼编译器』和『拼输出代码质量』的游戏。当然，这种比较也是剔除了开发效率的片面对比，语言间孰优孰劣、谁快谁慢的问题都是很难有结果的争论，下面我们就回到正题，看看这两种语言的编译器各有何种优势。

Java 的劣势

Java 虚拟机的即时编译器与 C/C++ 的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势：

第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。
第二，Java 语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检查空指针、数组元素访问时检查上下界范围、类型转换时检查继承关系等。对于这类没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。
第三，Java 语言中虽然没有 virtual 关键字，但是使用虚方法的频率却远远大于 C/C++ 语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于 C/C++ 语言，也意味着即时编译器在进行一些优化（例如方法内联）时的难度要远大于 C/C++ 的静态优化编译器。
第四，Java 语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。
第五，Java 语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而 C/C++ 的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++ 中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。

Java 的优势

上面说了一大堆 Java 语言相对 C/C++ 的劣势，不是说 Java 就真的不如 C/C++了，相信读者也注意到了，Java 语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、动态扩展、垃圾回收这些『拖后腿』的特性都为 Java 语言的开发效率做出了很大贡献。

何况，还有许多优化是 Java 的即时编译器能做而 C/C++ 的静态优化编译器不能做或者不好做的。例如，在 C/C++ 中，别名分析（Alias Analysis）的难度就要远高于 Java。Java 的类型安全保证了在类似如下代码中，只要 ClassA 和 ClassB 没有继承关系，那对象 objA 和 objB 就绝不可能是同一个对象，即不会是同一块内存两个不同别名。
代码示例 2

void foo(ClassA objA, ClassB objB){
    objA.x=123;
    objB.y=456;
    //只要 objB.y 不是 objA.x 的别名，下面就可以保证输出为 123
    print(objA.x);
}

确定了 objA 和 objB 并非对方的别名后，许多与数据依赖相关的优化才可以进行（重排序、变量代换）。具体到这个例子中，就是无须担心 objB.y 其实与 objA.x 指向同一块内存，这样就可确定打印语句中的 objA.x 为 123。

Java 编译器另外一个红利是由它的动态性所带来的，由于 C/C++ 编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选择的分支（Untaken Branch Pruning）等，这些都会成为 Java 语言独有的性能优势。

小结

《Java 程序编译与代码优化》、《Java 程序编译与代码优化续》分别介绍了 Java 程序从源码编译成字节码和从字节码编译成本地机器码的过程，虚拟机外部的 Javac 字节码编译器与虚拟机内部的 JIT 编译器的执行过程合并起来其实就等同于一个传统编译器所执行的编译过程。

通过这两篇文章，我们了解了虚拟机的热点探测方法、HotSpot 的即时编译器、编译触发条件，以及如何从虚拟机外部观察和分析 JIT 编译的数据和结果。对 Java 编译器的深入了解，有助于在工作中分辨哪些代码是编译器可以自动帮我们处理的，哪些代码需要自己调节以便于编译器优化的。

引用

《深入理解 Java 虚拟机》