android-notes/blogs/JVM/晚期（运行期）优化.md

晚期（运行期）优化

目录

1. 概述
2. HotSpot 虚拟机内的即时编译器
   • 解释器与编译器
   • 编译对象与触发条件
   • 编译过程
3. 编译优化技术
   • 公共子表达式消除
   • 数组边界检查
   • 方法内联
   • 逃逸分析

概述

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

HotSpot 虚拟机内的即时编译器

先来思考以下几个问题：

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

解释器与编译器

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

HotSpot 虚拟机中内置了两个即时编译器，分别称为 Client Compiler 和 Server Compiler，或者简称为 C1 编译器和 C2 编译器。用户可以配置虚拟机参数强制虚拟机运行于解释模式或者编译模式。

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所发费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替换编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

• 第 0 层

  程序解释执行，解释器不开启性能监控功能（Profiling），可触发第 1 层编译。

• 第 1 层

  也称为 C1 编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。

• 第 2 层

  也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

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

编译对象与触发条件

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

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

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

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

那多少次才算 “多次” 呢？虚拟机如何统计一个方法或一段代码被执行多少次了呢？解决这两个问题，也就回答了即时编译被触发的条件。

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

• 基于采样的热点探测

  采用这种方法的虚拟机会周期性的检查各个线程的栈顶，如果发现某个方法经常出现在栈顶，那么这个方法就是 “热点方法”。基于采样的热点探测的好处是实现简单、高效，还可以很容易的获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。

• 基于计数器的热点探测

  采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是 “热点方法”。这种统计方法实现起来要麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。

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

在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发 JIT 编译。方法计数器，它的默认阈值在 Client 模式下是 1500 次，在 Server 模式下是 10000 次，这个阈值可以通过虚拟机参数调整。

当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

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

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

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

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

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

编译过程

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

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

在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（HIR）。HIR 使用静态单分配的形式来代表代码值，这可以使得一些在 HIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成 HIR 之前完成。

在第二个阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（LIR），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HIR 达到更高效的代码表示形式。

最后阶段是在平台相关的后端使用线性扫描算法在 LIR 上分配寄存器，并在 LIR 上做窥孔优化，然后产生机器代码。Client Compiler 的大致执行过程如下图：

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

编译优化技术

首先需要明确的是，这些代码优化变化是建立在代码的某种中间表示或机器码之上，绝不是建立在 Java 源码之上的，为了展示方便，就使用了 Java 语言的语法来表示这些优化技术所发挥的作用。

编译器的这些优化技术实现起来也许比较复杂，但是要理解它们的行为对于一个普通的程序员来说是没有困难的，接下来，我们将查看以下几项最有代表性的优化技术是如何运作的，它们分别是：

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

公共子表达式消除

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

比如：

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

如果这段代码交给 Javac 编译器则不会进行任何优化，但是当这段代码进入到虚拟机即时编译器后，它将进行如下优化：

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

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

int d = E * 13 + a * 2

数组边界检查消除

方法内联

方法内联，它是编译器最重要的优化手段之一，除了消除方法调用本身的开销之外，它更重要的意义是为了其他优化手段建立良好的基础。比如以下例子：

    public static void foo(Object object) {
        if (object != null) {
            System.out.println("do something");
        }
    }

    public static void main(String[] args) {
        Object obj = null;
        foo(obj);
    }

事实上，main 方法里面全部是无用的代码，如果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何 "Dead Code"。

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

无法内联的原因在前面讲解 Java 方法解析和分派调用的时候就已经介绍过了。只有使用 invokespecial 指令调用的私有方法、实例构造器、父类方法以及使用 invokestatic 指令进行调用的静态方法才是在编译器进行解析饿，除了上述 4 种方法之外，其他的 Java 方法调用都需要在运行时进行方法接受者的多态选择，并且都有可能存在多于一个版本的方法接受者（最多再除去被 final 修饰的方法这种特殊情况，尽管它使用 invokevirtual 指令调用，但也是非虚方法，Java 语言规范中明确说明了这点），简而言之，Java 语言中默认的实例方法是虚方法。

对于一个虚方法，编译器做内联的时候根本无法确定应该使用哪个方法版本，只能在运行期才能确定。

那是不是为了提高执行性能，就要到处使用 final 关键字去修饰方法呢？

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

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

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

所以说，在很多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了方法内联之外，对于出现概率很小的隐式异常、使用概率很小的分支等都可以被激进优化 “移除”，如果真的出现了小概率事件，这时才会从 “逃生门” 回到解释状态重新执行。

逃逸分析

逃逸分析是目前 Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为了其他优化手段提高依据的分析技术。

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

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

栈上分配

我们知道，Java 中的对象大多都是分配到堆上的，虚拟机的垃圾收集可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费时间。如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用战上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。

同步消除

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

标量替换

标量是指一个数据已经无法再分解成更小的数据来表示了，Java 虚拟机中的原始数据类型（int、long 等数值类型以及 reference 类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量，Java 中的对象就是最典型的聚合量。如果把一个 Java 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。