概述

Java 程序在运行期间，可能会有某个方法或者代码运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时 JVM 会将这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，JIT 编译器）。

解释器和编译器

事实上，现在许多主流的商用虚拟机，都同时包含有解释器与编译器，解释器与编译器两者各有优势。与解释器相比，编译器会将常运行到的代码编译成本地代码区实现，可以获取更高的执行效率。而当程序运行环境中内存资源限制较大时，可以使用解释执行节约内存，反之可以使用编译执行来提高效率。解释器和编译器之间还可以通过逆优化退回到解释状态继续执行，因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作。

关系如图所示：

HotSpot 虚拟机中内置了两个 JIT 编译器：Client Complier(C1 编辑器) 和 Server Complier(C2 编辑器)，分别用在客户端和服务端。目前主流的 HotSpot 虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。

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

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

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

编译对象与触发条件

编译对象

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

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

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

触发条件

判断一段代码是不是热点代码，是不是需要出发即时编译，这种行为成为热点探测，但进行热点探测也不一定要知道方法具体调用了多少次，目前主要的热点探测判定方法有两种：

基于采样的热点探测：

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

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

在 HotSpot 中使用的是第二种方法，基于计数器的热点探测法，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器（回边计数器是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为”回边“；显然，建立回边计数器统计的目的是为了触发 OSR 编译）

方法调用计数器（统计方法被调用次数）

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

整个 JIT 编译的交互过程如下：
回边计数器（统计方法循环体代码执行次数）

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

编译过程

在默认设置下，无论是方法调用产生即使编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。

在后台执行编译的过程中，对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

一个平台独立前段将字节码构造成一种高级中间代码表示（HIR），HIR 使用静态单分配的形式来表示代码值，这可以使得一些在 JIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前，编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等。
一个平台相关的后端从 HIR 中产生低级中间代码表示，而在此之前，在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等。
在平台的后端使用线性扫描算法在 LIR 上分配寄存器，并在 LIR 上做窥孔优化，然后产生机器代码。

过程如图所示：

对于 Server Compiler 则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译期，也是一个充分优化过的高级编译器，它会执行所有经典的优化动作。
Server Compiler 的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构上的大寄存器集合。所以它也是比较缓慢的，但是编译代码质量高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以很多非服务端的应用选择使用 server 模式的虚拟机运行。

编译优化技术

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

公共子表达式消除
如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那 E 的这次出现就成公共子表达式，可以用原先的表达式进行消除。
数组边界检查消除
系统将自动进行数组上下界的范围检查。
隐式异常处理：Java 中空指针和算术运算中除数为零的检查。此外还有：自动装箱消除、安全点消除、消除反射等等。
方法内联
把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的方法调用。
逃逸分析
分析对象的动态作用域：
- 当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递给其他方法，称为方法逃逸。
- 甚至还有可能被外部线程访问到，比如赋值给类变量或可以在其他线程中访问到的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，就可以为这个变量进行一些高效的优化：如：栈上分配（在栈上分配内存）、同步消除（消除线程同步操作）、标量替换等。