概述
Java程序起初是通过解释器（Interperter）进行解析执行的，当虚拟机发现某个代码或方法特别频繁时，就会把这些代码认定为热点代码（hot spot code）。为了提高热点代码执行效率，运行时，会将其编译为本地的机器码，并进行各种层次优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler JIT编译器）。
JIT并不是虚拟机必须部分，JVM也没有规定必须要有JIT的存在。更没有限定或指导JIT应该如何去实现。但是，JIT的编译性能好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键指标之一，他是虚拟机中最核心且最体现虚拟机技术水平的部分。下面都是讨论的HotSpot虚拟机内的JIT。
HotSpot虚拟机内即时编译器
解释器与编译器
解释器与编译器各有优势：当程序需要迅速启动和执行时，解释器首先发挥作用，省去编译时间，立即执行。在程序运行之后，随着时间推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，获得更高的执行效率。当程序运行环境中内存资源限制较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化的一个逃生门，让编译器根据概率选择一些大多数时候都能够提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承关系发生变化等，可以通过逆优化退回到解释状态继续执行。因此，在整个虚拟机架构中，解释器与编译器经常配合工作。（部分没有解释器的虚拟机也会采用不进行激进优化的C1编译器担任逃生门的角色）
JRockit是个例外，他内部没有解释器，因此会存在启动响应时间长之类的缺点，但它主要是面向服务端的应用，这类应用一般不会重点关注启动时间。
HotSpot中内置了两个JIT，分别为Client Compiler和Server Compiler，虚拟机中习惯将Client Compiler称为C1，将Server Compiler称为C2。目前主流的HotSpot虚拟机中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot会根据自身版本与机器性能自动选择运行模式，用户也可以使用-client或-server参数去强制指定虚拟机运行在client模式或Server模式。
无论采用的编译器是Client Compiler还是ServerCompiler，解释器与编译器搭配使用的方式在虚拟机中称为混合模式（Mixed Mode），用户可以使用参数-Xint强制虚拟机运行于解释模式（Interpreted Mode），这时编译器完全不介入工作，全部代码使用解释方式执行。另外，也可以使用参数-Xcomp强制虚拟机运行于编译模式（Compiled Mode），这时优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，java -version命令的输出结果会显示出这三种模式。
由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启用分层编译的策略，分层编译在JDK1.7的Server模式虚拟机中作为默认编译策略可开启。
第0层，程序解释执行，解释器不开启性能监控功能，可触发第1层编译。
第1层，也称为C1编译，将字节码编译为本地代码，进行简单可靠的优化，如有必要将加入性能监控逻辑。
第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启动一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译执行，解释执行时解释器也无须再承担收集性能监控信息的任务。
编译对象与触发条件
啊、在运行过程中会被JIT编译的“热点代码”有两类：
被多次调用的方法
被多次执行的循环体
对于第一种情况，由于方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的JIT编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称为栈上替换。（On Stack Replacement，简称OSR编译，即方法栈帧还在栈上，方法就被替换了）。
判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判断方式有两种：
基于采样的热点探测（Sample Based Hot Spot Detection）：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是热点方法。基于采样的热点探测的好处就是实现简单、高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确地缺点一个方法的热度，容易因为受到线程阻塞或别的外界原因的影响而扰乱热点探测。
基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方法的虚拟机会为每个方法（甚至代码块）建立计数器，统计方法的执行次数，如果次数超过一定的阈值就认定它是“热点代码”。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对更加精确和严谨。
在HotSpot虚拟机中使用的是第二种-基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。
我们首先看看方法调用计数器，顾名思义，这个计数器就用于统计方法被调用的次数，它的默认阈值在client模式下是1500次，在Server模式下是10000次，这个阈值可以通过虚拟机参数-XX:CompileThreshold来人为设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器+1，然后判断方法调用计数器与回边计数器之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向JIT提交一个该方法的代码编译请求。
如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解析器按照解释代码执行字节码，知道提交的请求被编译器编译完成。当编译工作完成后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法就会使用已编译的版本。
如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减，而这段时间就称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大多数方法都会编译成本地代码。另外我们可以使用-XX: CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。
再看看另外一个计数器-回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（back Edge），显然，建立回边计数器统计的目的就是为了触发OSR编译。
关于回边计数器的阈值，虽然HotSpot虚拟机也提供了一个类似于方法调用计数器阈值-XX:CompileThreshold的参数-XX:BackEdgeThreshold供用户设置，但是当前的虚拟机实际上并未使用此参数，因此我们需要设置另外一个参数-XX:OnStackReplacePercentage来间接调整回边计数器的阈值。计算公式如下：
虚拟机运行在Client模式下，回边计数器阈值计算公式为：
方法调用计数器阈值（CompileThreshold）* OSR比率（OnStackReplacePercentage）/ 100，其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机回边计数器阈值为13995
虚拟机运行在Server模式下，回边计数器阈值的计算公式为：
方法调用计数器阈值（CompileThreshold）* （OSR比率 （OnStackReplaePercentage）- 解释器监控比率（InterperterProfilePercentage））/100
其中OnStackReplacePercentage默认值140，InterperterProfilePercentage默认值Wie33，如果都取默认值，那Server模式虚拟机回边计数器阈值为10700。
当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有则优先执行已编译的代码，否则就把回边计数器的值+1，然后判断方法调用计数器与回边计数器之和是否超过阈值，超过阈值时条件OSR编译请求，并且把回边计数器值降低一些，以便继续再解释器中执行循环，等待编译器输出编译结果。
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此计数器统计的是该方法循环的绝对次数。当计数器溢出时，他还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法时就会执行标准编译过程。（疑问：如果在client模式中，方法调用计数器的阈值为1500，回边计数器阈值为13995，将方法调用计数器调至1500+再将回边计数器调低还可以接受，但是在server模式下，方法调用计数器阈值为10000回边计数器阈值为10700，此时就不合适了）
上面描述的都是Client VM的即时编译方式，对于Server VM来说，执行情况会比上面的描述更复杂一些。
编译过程
在默认设置下，无论是方法调用产生的即时编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。用户可以通过参数-XX:-BackgroundCompilation来禁止后台编译·，在禁止后台编译后，一旦达到JIT编译条件，执行线程向虚拟机提交请求后将会一直等待，直到编译过程完成后再开始执行编译输出的本地代码。
在后台执行编译的过程中，编译器做了什么事情呢？Server Compiler和Client Complier两个编译器的编译过程是不同的。对于Client Compiler来说，他是一个简单快速的一段式编译器，主要关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。
Client Compiler编译过程：
而Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器。他会执行所有经典的优化动作，如无用代码消除、循环展开、循环表达式外提、消除公共子表达式、常量传播等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除、空值检查消除，不过并非所有的控制检查消除都是依赖编译器优化的等。还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联、分支频率预测等。Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构上的大寄存器集合。以即时编译的标准来看，Server Complier无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server模式的虚拟机运行。
查看及分析即时编译结果
虚拟机提供了一些参数用来输出即时编译和某些优化手段（如方法内联）的执行情况，本节将介绍如何从外部观察虚拟机的即时编译行为。下面提到的运行参数有一部分需要Debug或FastDebug版虚拟机的支持。Product版本虚拟机将无法使用这部分参数。
测试代码：
public class TestJIT {
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编译。（部分截图）
从上面可以却，main，calcSum和doubleValue方法已经被编译，我们还可以加上参数-XX:+PrintInlining要求虚拟机输出方法内联信息：
doubleValue被内联编译到calcSum中，而calcSum又被内联编译到方法main中，所以虚拟机再次执行main时，calcSum和doubleValue方法都不会再被调用，他们的代码逻辑直接被内联到main方法中了。
编译优化技术
以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额为消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把所有的优化措施都集中在类即时编译器中。因此一般来说，即时编译器产生的本地代码会比Javac产生的字节码更加优秀。
优化技术概览
举例：
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源码之上的。上面代码非常简单，但是仍有许多优化的余地，第一步进行方法内联，方法内联的重要性要高于其他优化措施，它的主要目的有两个，一是去除方法调用的成本（如建立栈帧等），而是为其他优化建立良好的基础，方法内联膨胀后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。一次，各种编译器一般都会把内联优化放在优化序列的最靠前位置。内联后：
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;
}经过，方法内联、公共子表达式消除、复写传播、无用代码消除后的代码与原始代码所达到的效果是一致的，但是前者比后者省略了许多语句（体现在字节码和机器码指令上差距会更大）执行效率也会更高。下面我们将看下几项最有代表性的优化技术是如何运作的，他们分别是：
语言无关的经典优化技术之一：公共子表达式消除
语言相关的经典优化技术之一：数组范围检查消除
最重要的优化技术之一：方法内联
最前沿的优化技术之一：逃逸分析
由于Java语言提倡使用面向对象的编程方式，而Java对象的方法默认就是虚方法，因此Java间接鼓励了程序员使用大量的虚方法来完成程序逻辑。如果内联的与虚方法之间产生矛盾，那该怎么办？是不是为了提高性能，就要到处使用final关键字修饰呢？
为了解决虚方法的内联问题，Java虚拟机设计团队想了很多办法，首先是引入一种名为“类型继承关系分析”（CHA）的计算，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。
编译器在进行内联时，如果是非虚方法，那么直接进行内联即可，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进的优化，需要预留一个逃生门（Guard（守护）条件不成立时），称为守护内联。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接受者的继承关系变化的类，那这个内联优化的代码就可以一直使用下去。但是如果加载了导致继承关系发生变化的类。那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新编译。
如果像CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致为：未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接受者的版本信息，并且每次进行方法调用时都比较接受者版本，如果以后进来的每次调用的方法接受者版本都一样，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多台特性，这时候才会取消内联，查找虚方法表进行方法分派。
所以说，许多情况下虚拟机进行内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小的分支等都可以被激进优化“移除”，如果真的出现了小概率的事件，这时才会从“逃生门”回到解释状态重新执行。
逃逸分析
逃逸分析时目前Java虚拟机中比较前沿的优化技术，他与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，他可能被外部方法所吸引，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效优化：
栈上分配（Stack Allocation）：JVM中，在Java堆上分配创建对象的内存空间几乎是Java程序员的常识，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的垃圾收集系统可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都耗费时间。如果确定一个对象不会逃逸出方法之外，那这个对象在栈上分配内存将会是一个很不错的主意。对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁，GC系统压力会小很多。
同步消除（synchronization Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会存在竞争，对这个变量实施的同步措施也就可以消除掉。
标量替换（Scalar Replacement）：标量是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中原始数据（int long 等数值类型以及reference类型等）都不能再进一步分解，他们就可以成为标量。如果一个数据可以继续分解，那他就称为聚合量，Java中的对象就是最典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行时将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写外，还可以为后续进一步的优化手段创建条件。
逃逸分析的论文在1999年就已经发表，但知道jdk1.6才实现，而且直到现在这项优化都尚未成熟。不成熟的原因主要是不能保证逃逸分析的性能收益必定高于它的消耗。如果要完全准确地判断一个对象是否会逃逸，需要进行一系列复杂的分析。从而确定程序各个分支执行时对此对象的影响。这是一个高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间就白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。还有一点，基于逃逸分析的一些优化手段，如上面提到的栈上分配，由于HotSpot虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此HotSpot中暂时还没有做这项优化。
实施逃逸分析的程序在实际应用程序，尤其是大型程序中可能会出现效果不稳定的情况，所以在很长一段时间中，即时是Server Compiler，也默认不开启逃逸分析，甚至在某些版本（如JDK1.6 Update18）中还短暂的完全禁止了这项优化。
如果有需要，并且确认对程序运行有益，用户可以使用参数手动开启逃逸分析、标量替换、同步消除等。尽管目前逃逸分析技术仍然不是十分成熟，但是它却是JIT优化技术的一个重要发展方向，在今后的虚拟机中，逃逸分析技术肯定会支撑起一系列实用有效的优化技术。 在JDK1.6的Update23的Server Compiler中才开始默认开启逃逸分析。