晚期（运行期）优化
在部分的商用虚拟机中，Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为热点代码。为了提高热点代码的执行效率，在运行时，虚拟机会将这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器
本章提到的编译器、即时编译器都是指HotSpot虚拟机内的即时编译器，虚拟机也是特质HotSpot虚拟机
1、HotSpot虚拟机内的即时编译器
1）、解释器与编译器
当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编辑成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率
HotSpot虚拟机中内置了两个即时编译器，分别称为Client Compiler和Server Compiler，或者简称为C1编译器和C2编译器。目前主流的HotSpot虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式。用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式
解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”，用户可以使用参数“-Xint”强制虚拟机运行于解释模式，这时编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数“-Xcomp”强制虚拟机运行于编译模式，这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，可以通过虚拟机的“-version”命令的输出结果显示出这3中模式
C:\Users\hxt>java -version java version "1.8.0_162" Java(TM) SE Runtime Environment (build 1.8.0_162-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode) ---------------------------------------------------------------------- C:\Users\hxt>java -Xint -version java version "1.8.0_162" Java(TM) SE Runtime Environment (build 1.8.0_162-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, interpreted mode) ---------------------------------------------------------------------- C:\Users\hxt>java -Xcomp -version java version "1.8.0_162" Java(TM) SE Runtime Environment (build 1.8.0_162-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, compiled mode)
为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机会启用分层编译的策略，分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
- 第0层，程序解释执行，解释器不开启性能监控功能，可触发第1层编译
- 第1层，也称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑
- 第2层，也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化
用C1编译器获取更高的编译速度，用C2编译器获取更高的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务
2）、编译对象与触发条件
在运行过程中会被即时编译器编译的热点代码有两类：
- 被多次调用的方法
- 被多次执行的循环体
对于第一种情况，由于是由方法调用触发的编译，因此编译器会以整个方法作为编译对象，这种编译也是虚拟机标准的JIT编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此称之为栈上替换（OSR编译，即方法帧还在栈上，方法就被替换了）
判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测，其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种：
- 基于采用的热点探测：采用这种方式的虚拟机会周期性地检查各个线程的栈顶，如果发现某个方法经常出现在栈顶，那这个方法就是热点方法。基于采样的热点探测的好处是实现简单、高效，还可以很容易地获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测
- 基于计数器的热点探测：采用这种方法的虚拟机会为每个方法建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是热点方法。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨
在HotSpot虚拟机中使用的是基于计数器的热点探测，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译
方法调用计数器用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10000 次，这个阈值可以通过虚拟机参数-XX:CompileThreshold来设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否查过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求
如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX: -UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，单位是秒
回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”。显然，建立回边计数器统计的目的就是为了触发OSR编译
关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX:CompileThreshold的参数-XX:BackEdgeThreashold供用户设置，但是当前的虚拟机实际上并未使用此参数，因此我们需要设置另外一个参数-XX:OnStackReplacePercentage来简介调整回边计数器的阈值，其计算公式如下
- 虚拟机运行在 Client 模式下，回边计数器阈值计算公式为：
方法调用计数器阈值（CompileThreshold）× OSR 比率（OnStackReplacePercentage）/ 100
其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回边计数器的阈值为 13995
- 虚拟机运行在 Server 模式下，回边计数器阈值的计算公式为：
方法调用计数器阈值（CompileThreshold）× （OSR 比率（OnStackReplacePercentage）- 解释器监控比率（InterpreterProfilePercentage）） / 100
其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机回边计数器的阈值为10700
当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会有限执行已编译的代码，否则就把回边计数器的值加 1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个OSR编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程
上述内容仅仅描述了Client VM的即时编译方式，对于Server VM来说，执行情况会比上面的描述更复杂一些
3）、编译过程
在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。用户可以通过参数-XX: -BackgroundCompilation来禁止后台编译，在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码
对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段
在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（HIR）。HIR使用静态单分配的形式代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成 HIR之前完成。
在第二个阶段，一个平台相关的后端从HIR中产生低级中间代码表示（LIR），而在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。
最后阶段是在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码
Server Compiler是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，还可以根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化
Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构上的大寄存器集合
2、编译优化技术
1）、公共子表达式消除
如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间在对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除，如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除
2）、数组边界检查消除
Java语言是一门动态安全的语言，数组边界检查是必须做的，但数组边界检查是不是必须在运行期间一次不漏地检查则是可以商量的事情。比如，数组下标是一个常量，如foo[3]，只要在编译期根据数据流分析来确定foo.length的值，并判断下标3没有越界，执行的时候就无须判断了。数组访问发生在循环之中，并且使用循环变量来进行数组访问，如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间[0,foo.length)之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作
隐式异常处理：Java中空指针检查和算数运算中除数为零的检查都采用了隐式异常处理
if (foo != null) {
return foo.value;
else {
throw new NullPointException();
}
在使用隐式异常优化之后，虚拟机会把上面伪代码所表示的访问过程变为如下伪代码
try {
return foo.value;
} catch (segment_fault) {
uncommon_trap();
}
虚拟机会注册一个Segment Fault信号的异常处理器（伪代码中的uncommon_trap()），这样当foo不为空的Z候，对value的访问是不会额外消耗一次对foo判空的开销的。代价就是当foo真的为空时，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。当foo极少为空的时候，隐式异常优化是值得的，但假如foo经常为空的话，这样的优化反而会让程序更慢，还好HotSpot虚拟机会根据运行期收集到的 Profile 信息自动选择最优方案
3）、方法内联
方法内联除了消除方法调用的成本之外，还为其他优化手段建立良好的基础
只有使用invokespecial指令调用的私有方法、实例构造器、父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4中方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者，Java语言中默认的实例方法是虚方法
对于一个虚方法，编译器做内联的时候根本无法确定应该使用哪个版本，为了解决虚方法的内联问题，引入了一种名为类型继承关系分析（CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息
编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向CHA查询方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个逃生门称为守护内联。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译
如果向CHA查询出来的结果是有多个版本的目标方法可供选择，编译器使用内联缓存来完成方法内联，在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派
4）、逃逸分析
逃逸分析是为其他优化手段提供依据的分析技术
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化：
- 栈上分配：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的空间内存就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多
- 同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉
- 标量替换：标量是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量，Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写外，还可以为后续进一步的优化手段创建条件
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对自由互联的支持。如果你想了解更多相关内容请查看下面相关链接