深入理解Java虚拟机总结-运行期优化

注:此文是我在读完周志明老师的深入理解Java虚拟机之后总结的一篇文章，请阅读此书获取更加详细的信息．

在这篇文章中，我们将会介绍:

编译器与解释器的关系
什么样的代码才会在运行时被编译成本地代码?
在何时被编译成本地代码?
如何编译成本地代码?
运行期都有哪些优化技术?

解释器与编译器

解释器就是在运行时，读取Class文件中的内容并解释执行，而编译器则指的是，直接将Class文件编译为本地二进制文件，执行时直接执行这个本地二进制文件．

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

HotSpot虚拟机中内置了两个即时编译器，分别成为Client Compiler和Server Compiler，或者简称为C1编译器或C2编译器．

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

为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译(Tiered Compilation)的策略：

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

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

编译对象与触发条件

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

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

它们在编译时，都是以方法作为单位进行的．

第一种情况下很好理解，而在第二种情况下，尽管编译动作是由循环体触发的，但是并不会以这个循环体作为单位来进行编译，而还是采用方法作为单位．第二种编译过程被称为栈上替换(On Stack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了)．

那么到底多少次才是“多次”呢?

目前主要的热点探测判定方式有两种：

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

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

方法调用计数器，顾名思义，就是统计方法调用次数的计数器，它的默认阈值，在Client模式下是1500，在Server模式下是10000次，当然这个阈值可以通过虚拟机参数-XX:CompileThreshold来进行设定．当一个方法在执行的时候，先检查该方法是否已经被JIT编译过，如果存在，则优先使用编译后的本地代码．如果没有，则将其调用次数加一，并判断方法调用计数器加上回边计数器是否达到了JIT编译的触发条件，如果超过了这个阈值，则会向即时编译器提交一个该方法的代码编译请求．

如果不做任何设置，执行引擎并不会同步直到编译完成，而是继续按照解释的方式执行．当编译完成后，这个方法的调用入口就会被系统自动修改为新的，下一次调用该方法时，就会直接使用已编译好的版本．

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

回边计数器呢，其作用是统计一个方法中循环体代码执行的次数．

关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX:CompileThreshold的参数-XX:BackEdgeThreshold供用户设置，但是当前的虚拟机实际上并未使用此参数，因此我们需要设置另外一个参数-XX:OnlineStackReplacePercentage来简介调整回边计数器的阈值．其计算公式为：

虚拟机运行在Client模式下，回边计数器阈值计算公式为： 方法调用计数器阈值(CompileThreshold) * OSR比率(OnStackReplacePercentage) / 100．其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回边计数器的阈值为13995．
虚拟机运行在Server模式下，回边计数器阈值的计算公式为： 方法调用计数器阈值(CompileThreshold) * (OSR比率(OnStackReplacePercentage) - 解释器监控比率(InterpreterProfilePercentage)) / 100．其中OnStackReplacePercentage的默认值为140，InterpreterProfilePercentage的默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700．

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

需要注意的是，上面我们仅仅描述了Client VM的即使编译方式，对于Server VM来说，执行情况会比上面的描述更复杂一些．

编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行．用户可以通过参数-XX:-BackgroundCompilation来进制后台编译，在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将一直等待，直到编译过程完成后再开始执行编译器输出的本地代码．

那么在后台执行编译过程中，编译器做了什么事情呢？Server Compiler和Client Compiler两个编译器的编译过程是不一样的．对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段．

在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示(High Level Intermediate Representation, HIR)．HIR使用静态单分配(Static Single Assignment, SSA)的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更加容易实现．在此之前编译器会在字节码上完成一部分基础优化，如方法内联，常量传播等优化将在字节码被构造成HIR之前完成．
在第二个阶段，一个平台相关的后端从HIR中产生低级中间代码完成(Low-Level Intermediate Representation, LIR)，而在此之前会在HIR上完成另外一种优化，如空值检查清除，范围检查清除等，以便让HIR达到更高效的代码表示形式
最后阶段是在平台相关的后端使用线性扫描算法和LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码．Client Compiler的大致执行过程如下图所示:

而Server Compiler则是专门面向服务器端的典型应用并为服务器端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行所有经典的优化动作，如无用代码消除，循环展开，循环表达式外提，消除公共子表达式，常量传播，基本块重排序等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除，空值检查消除等．此外，还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内敛，分之频率预测等．

编译优化技术

优化技术很多，这里我们仅仅介绍几个典型的．我们先举一个例子，优化的例子．

假设原始代码如下图所示：

static class B {
  int value;
  final int get () {
    return value;
  }
}

public void foo() {
  y = b.get();
  // ....do stuff...
  z = b.get();
  sum = y + z;
}

第一步是进行方法内联(Method Inlining)，方法内联的重要性要高于其他优化措施，它的主要目的有两个，一个是去除方法调用的成本(如建立栈帧等)，二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果．因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置．内敛后的代码如下图所示：

public void foo() {
  y = b.value;
  // ... do stuff...
  z = b.value;
  sum = y+ z;
}

第二步是进行冗余访问消除，假设代码中间注释掉的”…do stuff…“所代表的操作不会改变b.value的值，那就可以把”z=b.value”替换为”z=y”，因为上一句”y=b.value”已经保证了变量y与b.value是一致的，这样就可以不再去访问对象b的局部变量了．如果把b.value看作是一个表达式，那也可以把这项优化看成是公共子表达式消除，优化后的代码如下：

public void foo() {
  y = b.value;
  // ...do stuff...
  z = y;
  sum = y + z;
}

第三步进行复写传播，因为在这段程序的逻辑中并没有必要使用一个额外的变量”z”，它与变量”y”是完全相等的，因此可以使用”y”来代替”z”．复写传播后的程序代码如下：

 public void foo() {
  y = b.value;
  // ...do stuff...
  y = y;
  sum = y + y;
}

第四步是无用代码消除．无用代码指的是那些可能永远不会被执行的代码，也可能是完全没有意义的代码，这上面的这段代码中，”y=y”是没有意义的，把它消除后，代码清单如下：

public void foo() {
  y = b.value;
  // ... do stuff...
  sum = y + y;
}

下面我们将介绍如下几项最有代表性的优化技术是如何运作的，它们分别是：

语言无关的经典优化技术之一：公共子表达式消除
语言相关的经典优化技术之一：数组范围检查消除
最重要的优化技术之一：方法内联
最前沿的优化技术之一：逃逸分析

公共子表达式消除

公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式．对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了．如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除，如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除．举个例子来说明它的优化过程，假设存在如下代码：

int d = (c * b) * 12 + a + (a + b * c);

当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检测到”cb”与”bc”是一样的表达式，而且在计算期间b与c的值是不变的．因此，这条表达式就可能被视为:

int d = E * 12 + a + (a + E);

这时，编译器还可能进行另外一种优化：代数化简，把表达式变为：

int d = E * 13 + a * 2;

数组边界检查消除

由于Java在访问数组时，会有一个隐含的越界检查，这个操作会一定程度上降低效率．

如果数组的下标是一个常量，如foo[3]，只要在编译器根据数据流分析来确定foo.length的值，并判断下标”3”没有越界，执行的时候就无须判断了．更加常见的情况是数组访问发生在循环之中，并且使用循环变量来进行数组访问，如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在[0, foo.length)之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作．

方法内联

方法内联看起来只不过是将目标方法的代码复制到发起调用的方法中，避免发生真实的方法调用而已．但实际上Java虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的Java方法都无法进行内联．

无法内联的原因很简单，对于虚方法来说，Java只有在运行时才能确定到底要调用方法的哪个版本．在编译器的方法内联过程中，根本就无法完成．

为了解决虚方法的内联问题，Java虚拟机设计团队想了很多办法，首先是引入了一种名为”类型继承关系分析”(Class Hierarchy Analysis, CHA)的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类，子类是否为抽象类等信息．

编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的．如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个＂逃生门＂，称为守护内联．如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接受者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去．但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译好的版本，退回到解释状态执行，或者重新进行编译．

如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接受者的版本信息，并且每次进行方法调用时都比较接受者版本，如果以后进来的每次调用的方法接受者版本都是一样的，那这个内联还可以一直用下去．如果发生了方法接受者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内敛，查找虚方法表进行方法分派．

逃逸分析

逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，他可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸．甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸．

如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，比如:

栈上分配：Java虚拟机中，在Java堆上分配创建对象的内存空间几乎是Java程序员都清楚的常识了，Java堆中的对象对于各个线程都是共享和可见的，可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费时间．如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁．在一般应用中，不会逃逸的局部变量所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾回收系统的压力将会小很多．
同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉．
标量替换：标量是指一个数据已经无法再分解为更小的数据来表示了．Java虚拟机中原始数据类型(int,long等数值类型以及reference类型等)都不能再进一步分解，它们就可以称为标量．相对的，如果一个数据可以继续分解，那么它就称作聚合量，Java中的对象就是最典型的聚合量．如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始数据来访问就叫做标量替换．如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替．将对象拆分后，除了可以让对象的成员变量在栈上(栈上存储的数据，有很大概率会被虚拟机分配至物理机器的高速寄存器中存储)分配和读写之外，还可以为后续进一步的优化手段创建条件．