运行期优化

尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如 HotSpot、J9 等，都同时包含解释器与编译器。解释器与编译器两者各有优势：

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

     部分没有解释器的虚拟机中也会采用不进行激进优化的 C1 编译器担任 “逃生门” 的角色

     在虚拟机中习惯将 Client Compiler 称为 C1，将 Server Compiler 称为 C2 

在整个虚拟机执行架构中，解释器与编译器经常配合工作，如图所示：

HotSpot虚拟机中内置了两个即时编译器，分别称为 Client Compiler 和 Server Compiler ，或者简称为 C1编译器 和 C2编译器 （也叫Opto编译器）。目前主流的HotSpot虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于 虚拟机运行的模式 ，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用 -client 或 -server 参数去强制指定虚拟机运行在Client模式或Server模式

无论采用的编译器是Client Compiler还是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为 混合模式 ：

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

可以通过虚拟机的 -version 命令的输出结果显示出这3种模式，如下面所示：

C：\＞java -version
java version"1.6.0_22"
Java（TM）SE Runtime Environment（build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM（build 0.2-b02-internal，19.0-b04-internal,mixed mode）

C：\＞java -Xint-version
java version"1.6.0_22"
Java（TM）SE Runtime Environment（build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM（build 0.2-b02-internal，19.0-b04-internal,interpreted mode）

C：\＞java -Xcomp-version
java version"1.6.0_22"
Java（TM）SE Runtime Environment（build 1.6.0_22-b04）
Dynamic Code Evolution 64-Bit Server VM（build 0.2-b02-internal，19.0-b04-internal,compiled mode）

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

分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

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

作为三大商用虚拟机之一的JRockit是个例外，它内部没有解释器，因此会存在“启动响应时间长”之类的缺点
但它主要是面向服务端的应用，这类应用一般不会重点关注启动时间

在虚拟机中习惯将Client Compiler称为C1，将Server Compiler称为C2。

在最新的Sun HotSpot中，已经去掉了-Xcomp参数。

Tiered Compilation在JDK 1.7之前需要使用-XX：+TieredCompilation参数来手动开启

如果不开启分层编译策略，而虚拟机又运行在Server模式，Server Compiler需要性能监控信息提供编译依据
则可以由解释器收集性能监控信息供Server Compiler使用

实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译：

• 用Client Compiler获取更高的编译速度
• 用Server Compiler来获取更好的编译质量
• 在解释执行的时候也无须再承担收集性能监控信息的任务

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

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

     前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为 热点代码 是理所当然的

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

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

     在上面的文字描述中，无论是 “多次执行的方法”，还是 “多次执行的代码块”，所谓“多次”都不是一个具体、严谨的用语，那到底多少次才算“多次”呢？

     还有一个问题，就是虚拟机如何统计一个方法或一段代码被执行过多少次呢？

     解决了这两个问题，也就回答了即时编译被触发的条件

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

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

     还有其他热点代码的探测方式，如基于“踪迹”（Trace）的热点探测再最近相当流行

     像 Firefox 中的 TraceMonkey 和 Dalvik 中新的 JIT 编译器都用了这种热点探测方式

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

1. 方法调用 计数器
2. 回边 计数器

在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的 阈值 ， 当计数器超过阈值溢出了，就会触发 JIT 编译

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

那么在后台执行编译的过程中，编译器做了什么事情呢？Server Compiler和Client Compiler两个编译器的编译过程是不一样的

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

先看下测试代码：

public static final int NUM = 15000;

public static int doubleValue(int i) {
    // 这个空循环用于后面演示JIT代码优化过程
    for(int j=0; j<100000; j++);  
    return i * 2;
}

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

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

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

VM option'+PrintCompilation'
310 1 java.lang.String：charAt（33 bytes）
329 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
329 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
332 1%org.fenixsoft.jit.Test：main@5（20 bytes）

从输出的确认信息中可以确认 main() 、 calcSum() 和 doubleValue() 方法已经被编译，还可以加上参数 -XX:+PrintInlining 要求虚拟机输出方法内联信息，如下面所示：

VM option'+PrintCompilation'
VM option'+PrintInlining'
273 1 java.lang.String：charAt（33 bytes）
291 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot）
294 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
295 1%org.fenixsoft.jit.Test：main@5（20 bytes）
@5 org.fenixsoft.jit.Test：calcSum inline（hot）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot）

输出中可以看到方法 doubleValue() 被内联编译到 calcSum() 中，而 calcSum() 又被内联编译到方法 main() 中，所以虚拟机再次执行 main() 方法的时候，calcSum() 和doubleValue() 方法都不会再被调用，它们的代码逻辑都被直接内联到main() 方法中了 （当然 main方法不会被再次调用，这里只是假设）

除了查看哪些方法被编译之外，还可以进一步查看即时编译器生成的机器码内容，不过如果虚拟机输出一串0和1，对于阅读来说是没有意义的，机器码必须反汇编成基本的汇编语言才可能被阅读。虚拟机提供了一组通用的反汇编接口，可以接入各种平台下的反汇编适配器来使用，如使用32位80x86平台则选用hsdis-i386适配器，其余平台的适配器还有hsdis-amd64、hsdis-sparc和hsdis-sparcv9等，可以下载或自己编译出反汇编适配器，然后将其放置在JRE/bin/client或/server目录下，只要与jvm.dll的路径相同即可被虚拟机调用。在为虚拟机安装了反汇编适配器之后，就可以使用 -XX:+PrintAssembly 参数要求虚拟机打印编译方法的汇编代码了

如果没有HSDIS插件支持，也可以使用 -XX:+PrintOptoAssembly （用于Server VM）或 -XX:+PrintLIR （用于Client VM）来输出比较接近最终结果的中间代码表示，被编译后部分反汇编，使用 -XX:+PrintOptoAssembly 的输出结果如下面所示：

……
000 B1：#N1＜-BLOCK HEAD IS JUNK Freq：1
000 pushq rbp
subq rsp，#16#Create frame
nop#nop for patch_verified_entry
006 movl RAX,RDX#spill
008 sall RAX，#1
00a addq rsp，16#Destroy frame
popq rbp
testl rax，[rip+#offset_to_poll_page]#Safepoint：poll for GC
……

从阅读角度来说，使用 -XX:+PrintOptoAssembly 参数输出的伪汇编结果包含了更多的信息（主要是注释）
利于阅读并理解虚拟机JIT编译器的优化结果

使用-XX:+PrintAssembly参数输出反汇编信息需要Debug或者FastDebug版的虚拟机才能直接支持
如果使用Product版的虚拟机，则需要加入参数-XX:+UnlockDiagnosticVMOptions打开虚拟机诊断模式后才能使用

如果除了本地代码的生成结果外，还想再进一步跟踪本地代码生成的具体过程，那还可以使用参数 -XX:+PrintCFGToFile （使用Client Compiler）或 -XX:PrintIdealGraphFile （使用Server Compiler）令虚拟机将编译过程中各个阶段的数据（例如，对C1编译器来说，包括 字节码 、 HIR生成 、 LIR生成 、 寄存器分配过程 、 本地代码 生成等数据）输出到文件中。然后使用 Java HotSpot Client Compiler Visualizer （用于分析Client Compiler）或 Ideal Graph Visualizer （用于分析Server Compiler）打开这些数据文件进行分析

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

Ideal Graph Visualizer加载ideal.xml文件后，在Outline面板上将显示程序运行过程中编译过的方法列表，如图所示。这里列出的方法是测试代码，其中 doubleValue() 方法出现了两次，这是由于 该方法的编译结果存在 标准编译 和 OSR编译 两个版本 。在测试代码中特别为 doubleValue() 方法增加了一个空循环，这个循环对方法的运算结果不会产生影响，但如果没有任何优化，执行空循环会占用CPU时间，到今天还有许多程序设计的入门教程把 空循环当做程序延时 的手段来介绍，在Java中这样的做法真的能起到延时的作用吗？

展开方法根节点，可以看到下面罗列了方法优化过程的各个阶段的Ideal图，先打开 After Parsing 这个阶段。JIT编译器在编译一个Java方法时，首先要把字节码解析成某种中间表示形式，然后才可以继续做分析和优化，最终生成代码。_After Parsing_ 就是Server Compiler刚完成解析，还没有做任何优化时的Ideal图表示。在打开这个图后，每一个方块就代表了一个程序的基本块，基本块的特点是只有 唯一的一个入口 和 唯一的一个出口 ，只要基本块中 第一条指令执行了，那么基本块内所有执行都会按照顺序仅执行一次

doubleValue() 方法虽然只有简单的两行字，但是按基本块划分后，形成的图形结构要比想象中复杂得多，这一方面是要满足Java语言所定义的安全需要（如类型安全、空指针检查）和Java虚拟机的运作需要（如Safepoint轮询），另一方面是由于有些程序代码中一行语句就可能形成好几个基本块（例如循环）。例子中的doubleValue() 方法，如果忽略语言安全检查的基本块，可以简单理解为按顺序执行了以下几件事情：

1. 程序入口，建立栈帧
2. 设置j=0，进行Safepoint轮询，跳转到 4 的条件检查
3. 执行j++
4. 条件检查，如果j＜100000，跳转到 3

5. 设置i=i*2，进行Safepoint轮询，函数返回

   

以上几个步骤，反映到Ideal Graph Visualizer的图上，就是下图所示的内容。这样要看空循环是否优化，或者何时优化，只要观察代表循环的基本块是否消除，或者何时消除就可以了

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

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

在 Sun 官方的 Wiki 上，HotSpot 虚拟机设计团队列出了一个相对比较全面的、在即时编译器中采用的优化技术列表，见表 11-1），其中有不少经典编译器的优化手段，也有许多针对 Java 语言（准确地说是针对运行在 Java 虚拟机上的所有语言）本身进行的优化技术：

为了消除对这些优化技术的陌生感，先举一个简单的例子，即通过大家熟悉的Java代码变化来展示其中几种优化技术是如何发挥作用的（仅使用Java代码来表示而已）。首先从原始代码开始，如下所示：

static class B{
    int value;
    final int get() {
        return value;
    }
}
public void foo() {
    y = b.get();
    // ...do stuff...
    z = b.get();
    sum = y + z;
}

     这些代码优化变换是建立在代码的某种中间表示或机器码之上的，绝不是建立在Java 源码之上的

     为了展示方便，使用了 Java 语言的语法来表示这些优化技术所发挥的作用

上面代码已经非常简单了，但是仍然有许多优化的余地：

• 方法内联 ，方法内联的重要性要高于其他优化措施，它的主要目的有两个：
  • 去除方法调用的成本 ：如建立栈帧等
  • 其他优化建立良好的基础

方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。内联后的代码如下所示：

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;
}

• 无用代码消除 。无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为 “Dead Code”，在上面代码 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);

如果这段代码交给 Javac 编译器则不会进行任何优化，那生成的代码将如下所示，是完全遵照 Java 源码的写法直译而成的：

iload_2     // b
imul        // 计算b * c
bipush 12   // 推入12
imul        // 计算（c * b）*12
iload_1     // a
iadd        // 计算（c * b）*12+a
iload_1     // a
iload_2     // b
iload_3     // c
imul        // 计算b * c
iadd        // 计算a+b * c
iadd        // 计算（c * b）*12+a+（a+b * c）
istore 4

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

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

这时，编译器还可能（取决于那种虚拟机的编译器以及具体的上下文而定）进行另外一种优化： 代数化简 ，把表达式变为：

int d = E * 13 + a * 2;

表达式进行变换之后，再计算起来就可以节省一些时间了

数组边界检查消除 是即时编译器中的一项语言相关的经典优化技术

Java 语言是一门动态安全的语言，对数组的读写访问也不像 C、C++ 那样在本质上是裸指针操作

如果有一个数组 foo[]，在 Java 语言中访问数组元素 foo[i] 的时候系统将会自动进行上下界的范围检查

即检查 i 必须满足 i >= 0 && i < foo.length 这个条件，否则将会抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException

这对软件开发者来说是一件很好的事情，即使程序员没有专门编写防御代码，也可以避免大部分的溢出攻击

但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作
对于拥有大量数组访问的程序代码，这无疑也是一种性能负担

无论如何，为了安全，数组边界检查肯定是必须做的，但数组边界是不是必须在运行期间 一次不漏地检查 则是可以“商量”的事情：

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

     将这个数组边界检查的例子放在更高的角度来看，大量的安全检查令编写 Java 程序比编写 C/C++ 程序容易很多
     如数组越界会得到 ArrayIndexOutOfBoundsException 异常，空指针访问会得到 NullPointException，除数为零会得到 ArithmeticException 等

     在 C/C++ 程序中出现类似的问题，一不小心就会出现 Segment Fault 信号
     或者 Windows 编程中常见的 “xxx 内存不能为 Read/Wrie” 之类的提示处理不好程序就和直接崩溃退出了

     但这些安全检查也导致了相同的程序，Java 要比 C/C++ 做更多的事情（各种检查判断），这些事情就成为一种隐式开销

除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外，另外还有一种避免思路： 隐式异常处理 ，Java 中空指针检查和算术运算中除数为零的检查都采用了这种思路。举个例子，例如程序中访问一个对象（假设对象叫 foo）的某个属性（假设属性叫 value），那以 Java 伪代码来表示虚拟机访问 foo.value 的过程如下：

if (foo != null) {
    return foo.value;
    else {
        throw new NullPointException();
    }
}

在使用隐式异常优化之后，虚拟机会把上面伪代码所表示的访问过程变为如下伪代码：

try {
    return foo.value;
} catch (segment_fault) {
    uncommon_trap();
}

虚拟机会注册一个 Segment Fault 信号 的 异常处理器 （伪代码中的 uncommon_trap()），这样当 foo 不为空的时候，对 value 的访问是不会额外消耗一次对 foo 判空的开销的。代价就是当 foo 真的为空时，必须转入到 异常处理器 中恢复并抛出 NullPointException 异常，这个过程必须从 用户态转到内核态中处理，结束后再回到用户态 ，速度远比一次判空检查慢。 当 foo 极少为空的时候，隐式异常优化是值得的 ，但假如 foo 经常为空的话，这样的优化反而会让程序更慢，还好 HotSpot 虚拟机足够 “聪明”，它会根据 运行期收集到的 Profile 信息自动选择最优方案

     与语言相关的其他消除操作还有不少，如自动装箱消除、安全点消除、消除反射等

_方法内联_，它是编译器最重要的优化手段之一，除了 消除方法调用的成本 之外，它更重要的意义是 为其他优化手段建立良好的基础 ，如下面所示的简单例子就揭示了内联对其他优化手段的意义：事实上 testInline() 方法的内部全部都是无用的代码，如果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何 "Dead Code" ，因为如果分开来看，foo() 和 testInline() 两个方法里面的操作都可能是有意义的

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

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

     方法内联的优化行为看起来很简单，不过是把目标方法的代码 “复制” 到发起调用的方法之中，避免发生真实的方法调用而已

     但实际上 Java 虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力

     按照经典编译原理的优化理论，大多数的 Java 方法都无法进行内联

无法内联的原因：只有使用 invokespecial 指令调用的 私有方法 、 实例构造器 、 父类方法 以及使用 invokestatic 指令进行调用的 静态方法 才是在 编译期进行解析 的，除了上述 4 种方法之外，其他的 Java 方法调用都需要在 运行时进行方法接收者的多态选择 ，并且都可能 存在多于一个版本的方法接收者 。简而言之，Java 语言中默认的实例方法是 虚方法

     最多再除去被 final 修饰的方法这种特殊情况，尽管它使用 invokevirtual 指令调用，但也是非虚方法，Java 语言规范中明确说明了这点

对于一个虚方法，编译期做内联的时候根本就 无法确定应该使用哪个方法版本 ，如果代码中把 b.get() 内联为 b.value 为例的话，就是不依赖上下文就无法确定 b 的实际类型是什么。假如有 ParentB 和 SubB 两个具有继承关系的类，并且子类重写了父类的 get() 方法，那么，是要执行父类的 get() 方法还是子类的 get() 方法，需要在运行期才能确定，编译期无法得出结论

逃逸分析 是目前 Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是 为其他优化手段提供依据的分析技术 。基本行为就是 分析对象动态作用域 ：

• 方法逃逸 ：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中
• 线程逃逸 ：还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量

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

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

	  关于逃逸分析的论文在 1999 年就已经发表，但直到 Sun JDK 1.6 才实现了逃逸分析
	  而且直到现在这项优化尚未足够成熟，仍有很大的改进余地

	  不成熟的原因主要是不能保证逃逸分析的性能收益必定高于它的消耗：
	  如果要完全准确地判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂分析，从而确定程序各个分支执行时对此对象的影响
	  这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间久白白浪费了
	  所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析

	  还有一点是，基于逃逸分析的一些优化手段，如上面提到的 “栈上分配”
	  由于 HotSpot 虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在 HotSpot 中暂时还没有做这项优化

	  在测试结果中，实施逃逸分析后的程序在 Micro Benchmarks 中往往能运行出不错的成绩
	  但是在实际的应用程序，尤其是大型程序中反而发现实施逃逸分析可能出现效果不稳定的情况
	  或因分析过程耗时但却无法有效判别出非逃逸对象而导致性能（即时编译的收益）有所下降

	  所以在很长的一段时间里，即时是 Server Compiler，也默认不开启逃逸分析
	  甚至在某些版本（如 JDK 1.6 Update 18）中还曾经短暂地完全禁止了这项优化

如果有需要，并且确认对程序运行有益，可以使用参数 -XX:+DoEscapeAnalysis 来手动 开启逃逸分析 ，开启之后：

• 通过参数 -XX:+PrintEscapeAnalysis 来 查看分析结果 。有了逃逸分析支持之后：
  • 使用参数 -XX:+EliminateAllocations 来 开启标量替换
  • 使用 +XX:+EliminateLocks 来 开启同步消除
  • 使用参数 -XX:+PrintEliminateAllocations 来 查看标量的替换情况

     尽管目前逃逸分析的技术仍不失十分成熟，但是它却是即时编译器优化技术的一个重要发展方向

     在今后的虚拟机中，逃逸分析技术肯定会支撑起一系列实用有效的优化技术