运行期优化

写在前面

本文作为阅读了《深入理解Java虚拟机》第11章 “晚期（运行期）优化” 的笔记。本文仅简要说明理论，起到抛砖引玉的效果。

当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”，为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（JIT 编译器）。

为何 HotSpot 虚拟机要使用解释器与编译器并存的架构？

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

HotSpot 的即时编译器

HotSpot 内置了两个即时编译器，称为 Client Compiler 和 Server Compiler ，或者简称为 C1 编译器和 C2 编译器。

主流的 HotSpot 虚拟机中，默认是采用解释器与其中一个编译器直接配合的方式工作（混合模式）。

用户可以使用参数 -Xint 强制虚拟机运行于“解释模式”（编译器完全不介入工作）。也可以使用参数 -Xcomp 强制虚拟机运行于“编译模式”，这时候将优先采用编译的方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能越长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有所影响。

为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机将会逐渐启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

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

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

编译对象和触发条件

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

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

前者是指一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为“热点代码”是理所当然的。这种情况，由于是方法调用触发的编译，那编译器理所当然地会以整个方法作为编译对象，这种编译方式也是虚拟机中标准的编译方式。

后者是为了解决当一个方法只被调用过一次或几次，但是方法体内部存在循环次数较多的循环体，这样循环体的代码也被重复执行多次。这种情况，尽管编译动作是由循环体触发的，但编译器仍然会以整个方法作为编译对象。这种编译方式因为编译发生在方法执行过程中，因此被很形象的称为 栈上替换（OSR）。

要知道一段代码是不是热点代码，是不是需要触发即时编译，这个行为称为 热点探测。目前主要的热点探测判定方式有两种，分别是：

• 基于采样的热点探测：周期性地检查各个线程的栈顶，如果发现某个方法经常出现在栈顶，那这个方法就是“热点方法”。这种方式的好处是简单高效，还可以很容易地获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易受到线程阻塞或别的外界因素的影响而扰乱热点探测。
• 基于计数器的热点探测：为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是 “热点代码”。

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

方法调用计数器，顾名思义，就是统计方法被调用的次数，但这个并不是一个绝对的次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。

当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程被称为方法调用计数器的 热度衰减。而这段时间就称为此方法统计的 半衰周期。

回边计数器，用于统计一个方法中循环体代码执行的次数。

编译优化技术

编译优化技术远不止我下面所写的这些，这里仅仅列出了我想关心的。

1. 方法内联：除了消除方法调用的成本之外，它还为其他优化手段建立良好的基础。

   为了解决虚方法的内联问题，引入了一种名为“类型继承关系分析”（CHA）的技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类且子类是否为抽象类等信息。

   目的是为了帮助确定此方法是否只有一个版本，如果只有一个，那么就可以进行内联。不过这种内联属于激进内联（因为动态拓展的存在），需要预留一个“逃生门”，称为 守护内联。

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

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

   • 栈上分配：如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的注意，对象所占用的内存空间就可以随栈帧出栈而销毁。

   • 同步消除：如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其它线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。

   • 标量替换：标量是指一个数据已经无法在分解成更小的数据来表示了。如果一个数据可以继续分解，那它称做聚合量。

     如果把一个 Java 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。

     如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写之外，还可以为后续进一步的优化手段创建条件。

我与风来

认认真真学习，做思想的产出者，而不是文字的搬运工。

但行善事，莫问前程。