部分的商用虚拟机中，Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的运行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，简称JIT编译器）。
即时编译器并不是虚拟机的必要组成部分，JVM规范中并没有规定JVM必须要有即时编译器的存在，更没有限定或指导即时编译器应该如何实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。
HotSpot虚拟机的即时编译器
我们要了解HotSpot虚拟机内的即时编译器的运作过程，同时，还要解决以下几个问题：
- 为何HotSpot虚拟机要使用解释器与编译器并存的架构？
- 为何HotSpot虚拟机要实现两个不同的即时编译器？
- 程序何时使用解释器执行？何时使用编译器执行？
- 哪些程序代码会被编译为本地代码？如何编译为本地代码？
- 如何从外部观察即时编译器的编译过程和编译结果
解释器和编译器
解释器和编译器各有两个优势：
- 当程序需要迅速启动和执行的时候，解释器首先发挥作用，省去编译的时间，立即执行。
- 在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
- 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，繁殖可以使用编译执行来提升效率。
- 同时，解释器还可以作为编译器激进优化时的一个逃生门，让编译器根据效率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类之后类型继承结构出现变化、出现罕见陷阱时可以通过逆优化退回到解释状态继续执行。
因此，在整体虚拟机执行架构中，解释器和编译器经常配合工作。
HotSpot虚拟机中内置了两个即时编译器，分别是Client Compiler和Server Compiler，或者简称C1编译器和C2编译器。目前主流的HotSpot虚拟机中，默认采用解释器与一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
无论采用的编译器是Client Compiler还是Server Compiler，解释器与编译器搭配使用的方式在虚拟机中称为混合模式，用户可以使用参数“-Xint”强制虚拟机运行于“解释模式”，这时编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数“-Xcomp”强制虚拟机运行于“编译模式”，这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的时候进入执行过程，可以通过虚拟机的“-version”命令的输出结果看出这3种模式
C:\>java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
C:\>java -Xint -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, interpreted mode)
C:\>java -Xcomp -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, compiled mode)
由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长：而且要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动相应速度和运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略，分层编译的概念在JDK1.6时期出现，后来一直处于改进阶段，最终在JDK1.7的Server模式虚拟机中作为默认编译策略被开启。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
- 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
- 第1层，也成为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要加入性能监控的逻辑。
- 第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的仅仅有话。
实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。
编译对象与触发条件
在运行过程中会即时编译的“热点代码”有两类，
- 被多次调用的方法
- 被多次执行的循环体
前者好理解，一个方法被调用的多了，方法内部代码执行的次数自然就多，它成为“热点代码”是理所当然的。而后者则是为了解决一个方法只被调用一次或少量几次，但是方法体内部存在循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是“热点代码”。
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然的会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法作为编译对象。
这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称OSR编译，即方法栈帧还在栈上，方法就被替换了）。
在上面的文字描述中，无论是“多次执行的方法”，还是“多次执行的代码块”，所谓“多次”都不是一个具体、严谨的用语，那么到底多少次才算“多次”呢？还有一个问题，就是虚拟机如何统计一个方法或一段代码被执行过多少次呢？解决了这两个问题，也就回答了即时编译被触发的条件。
判断一段代码是不是热点代码，这样的行为称为热点探测，其实进行热点探测并不一定要知道方法具体被调用了多少次，目前热点探测判定的方法有两种：
- 基于采样的热点cancel：采用这种方法的虚拟机会周期性的检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是热点方法。基于采样的热点探测的好处是实现简单、高效，还可以很容易的获得方法调用关系（将调用堆栈展开即可），缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
- 基于计数器的热点探测：采用这种方式的虚拟机会为每个方法甚至代码块建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就任务它是热点方法。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确严谨。
在HotSpot虚拟机中使用的是第二种：计数器热点探测。因为它为每个方法都准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器阈值溢出了，就会触发JIT编译。
方法调用计数器
顾名思义，这个计数器就用于统计方法被调用的次数，它的默认阈值在Client模式下是1500次，在Server模式下是10000次，这个阈值可以通过虚拟机参数-XX:CompileThreshold来人为设定。当一个方法调用时，会先检查该方法是否在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器+1，然后判断方法调用计数器与会变计数器之和是否超过方法调用计数器的阈值。如果已超越阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照届时方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。
如果不做任何限制，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器会被减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰期（Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺带进行的，可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大多数方法都会被编译成本地代码。另外，可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，时间是秒。
回边计数器
虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX:CompileThreshold的参数-XX:BackEdgeThreshold供用户设置，但是当前的虚拟机实际上并未使用此参数，因此我们需要设置另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式如下
- 虚拟机运行在Client模式下，回边计数器阈值计算公式为：方法调用计数器阈值×OSR比率÷100。其中，OSR比率（OnStackReplacePercentage）默认值为933，如果都去默认值，那Client模式虚拟机的回边计数器的阈值就是13995。
- 虚拟机运行在Server模式下，回边计数器阈值的计算公式为：方法计数器阈值×（OSR比率-解释器监控比率）÷100.其中OSR比率默认值为140，解释器监控比率（InterpreterProfilePercentage）默认值为33，如果都是默认值，Server模式虚拟机回边计数器的阈值为10700。
当解释器遇到一条回边指令时，会先查找要执行的代码片段是否有已经编译好的版本，如果有，它将会优先执行已经编译的代码，否则就把回边计数器的值加1，然后判断方法调用计数器与回边计数器的阈值。当超过阈值的时候，将会提交一个OSR请求，并且把回边计数器的值降低一些，以便在解释器中执行循环，等待编译器输出编译结果，整个过程如下所示：
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当方法溢出的时候，它还会把方法计数器的值调整到溢出状态，这样下次进入该方法的时候就会执行标准编译过程。
需要注意的是，上面的两张流程图展示的都仅仅是ClientVM的即时编译方式，对于ServerVM来说，执行情况会比上面的描述更复杂一些。
编译过程
在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都任然按照解释方式继续执行，而编译动作则在后台的编译线程中进行，用户可以通过参数-XX:-BackgroundCompilation来禁止后台编译，在禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译器输出的本地代码。
在后台执行编译的过程中，Server Compiler和Client Compiler两个编译器的编译过程是不一样的。对于ClientCompiler来说，它是一个简单快速的三段式编译器你，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。
在第一阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation， HIR）。HIR使用的静态单分派（Static Single Assignment， SSA）的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。
在第二阶段，一个平台相关的后端从HIR中产生低级中间代码表示（Low-Level Intermediate Representation， LIR），在此之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。
最后阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码。Client Compiler的大致执行过程如图：
而ServerCompiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化轻度，它会执行所有经典的优化动作，如无用代码消除（Dead Code Elimination）、循环展开（Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块重排序（Basic Block Reordering）等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination，不过并非所有的空值检查消除都是依赖编译器优化的，有一些是在代码过程中自动优化了）等。另外，如守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）等。
Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理架构（如RISC）上的大寄存器集合。以即时编译器的标准来看，Server Compiler无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server模式的虚拟机运行。
公共子表达式消除
公共子表达式小数是一个普遍存在于各种编译器的经典优化技术，它的含义是：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就称为了公共子表达式。对于这种表达式，没有必要花时间再对它计算，只需要直接用钱买计算过的表达式结果代替E就行了。如果这种优化仅限用程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围覆盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。举个例子说明它的优化过程，假设存在如下代码：
int a = 1, b = 2, c = 3;
int d = (c * b) * 12 + a + (a + b * c);
如果直接交给Javac编译器则不会进行任何优化，字节码如下：
0: iconst_1
1: istore_1
2: iconst_2
3: istore_2
4: iconst_3
5: istore_3
6: iload_3
7: iload_2 //b
8: imul //计算b*c
9: bipush 12 //推入12
11: imul //计算(b*c)*12
12: iload_1 //a
13: iadd //计算(b*c)*12+a
14: iload_1 //a
15: iload_2 //b
16: iload_3 //c
17: imul //计算(b*c)
18: iadd //计算a+b*c
19: iadd //计算(b*c)*12+a+(a+b*c)
20: istore 4
22: return
当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检查到“c*b”与“b*c”是一样的表达式，而且在执行期间b与c的值是不变的。因此这条表达式就可被视为：
int d = E * 12 + a + (a + E);
这时编译器还可能进行了另外一种优化：代数化简（这取决于哪种虚拟机的编译器以及具体的上下文而定），把表达式变为：
int d = E * 13 + a * 2;
数组边界检查消除
数组边界检查消除（Array Bounds Checking Elimination）是即时编译器中的一项语言相关的经典优化技术。我们知道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，除数为0会得到ArithmeticException等，在C/C++程序中出现类似的问题，一不小心就会出现Segment Fault信号或者Window编程中常见的“xxx内存不能为Read/Write”之类的提示，处理不好程序就直接崩溃退出了。但这些安全检查也导致了相同的程序，Java要比C/C++做更多的事情，这些事情就成为一种隐式的开销，如果处理不好，就很可能成为一个Java语言比C/C++更慢的因素。要消除这些隐式开销，除了如数组边界检查优化的这种尽可能把运行期检查提到编译期完成的思路之外，另外还有一种思路--隐式异常处理，Java中控指针检查和算数运算中除数为0的检查都是这种思路。例如，程序中访问一个对象foo的某个属性value，那么以Java伪代码表示虚拟机访问的过程如下。
if(foo != null) {
return foo.value;
} else {
throw new NullPointException();
}
在隐式异常优化后，虚拟机会把上面的伪代码转变成如下操作
try {
return foo.value;
} catch(segment_fault) {
uncommon_trap();
}
虚拟机会注册一个Segment Fault信号的异常处理器，这样当foo不为空的时候，对value的访问是不会额外消耗一次对foo判空的开销的。代价就是当foo真的为空的时候，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。当foo极少为空的时候，隐式异常优化是值得的，但假如foo经常为空，这样的优化反而会让程序更慢，还好HotSpot会根据运行期间收集到的Profile信息自动选择最优方案。
方法内联
方法内联是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础。如下所示：
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);
}
事实上，testInline方法内部全部都是无用的代码，如果不做内联，后续继续进行了无用代码的消除优化，也无法发现任何“Dead Code”，因为如果分开看，foo和testInline里面的操作都可能是有意义的。
方法内联的优化看起来很简单，不过是把目标方法的代码“复制”到发起调用的方法之中，避免发生真是的方法调用而。但实际上JVM中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些努力，按照经典编译原理的优化理论，大多数的Java方法都无法进行内联。
无法内联的原因是：只有使用invokespecial指令调用的私有方法、实例构造器、父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者，简而言之，Java语言中默认的实例方法是虚方法。
对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本。由于Java语言提倡使用面向对象，为了解决虚方法的内联问题，JVM设计团队想了很多办法，首先是引入了一个名为“类型继承关系分析”（Class Hierarchy Analysis，CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。
编译器在内联的时候，如果方法是非虚方法，那么直接进行内联就可以了，这个时候的内联是由稳定前提保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个逃生门（Guard条件不成立时的SlowPath），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一致没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系变化的类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新编译。
所以说，在许多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小（通过经验数据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支等都可以被激进优化“移出”，如果真的出现了小概率事件，这时才会从“逃生门”回到解释状态重新执行。
Java与C/C++的编译器对比
Java与C/C++的编译器对比实际上代表了最经典的即时编译器与静态编译器的对比，很大程度上也决定了Java与C/C++的性能对比的结果，因为无论C/C++还是Java代码，最终编译之后被机器执行的都是本地机器码，哪种语言的性能更高，除了它们自身的API库实现得好坏之外，其余的比较都是一场“拼编译器”和“拼输出代码质量”的游戏。当然，这种比较也是剔除了开发效率的片面对比，语言间孰优孰劣、谁慢谁快的问题都是很难有结果的争论。
Java虚拟机的即时编译器与C/C++的静态优化编译器相比，可能会由于下列原因导致输出的本地代码有一些劣势。
- 第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间夜里，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间内成本在静态优化编译器中并不是主要的关注点。
- 第二，Java语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反程序语言语义或访问非结构化内存。从实现层面上看，这就意味着虚拟机必须频繁的进行动态检查，如实例方法访问时检查空指针、数组元素访问时检查上下界范围、类型转换时检查继承关系等。这对这列程序代码没有明确写出检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。
- 第三，Java语言中虽然没有virtual关键字，但是使用虚方法的频率远远大于C/C++语言，这意味着运行时堆方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着即时编译器在运行一些优化时难度要远大于C/C++的静态优化编译器。
- 第四，Java语言是可以动态扩展的语言，运行时加载的新类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。
- 第五，Java语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而C/C++的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++中主要由用户程序员来回收分配的内存，这局不存在无用对象筛选的过程，因此运行效率上也比垃圾回收机制要高。
Java语言的这些性能上的劣势都是为了换取开发效率的优势而付出的代建，动态安全、动态扩展、垃圾回收这些特性都为Java语言的开发效率做出了很大的贡献。
