郑重声明：本片博客是学习<深入理解Java虚拟机>一书所记录的笔记，内容基本为书中知识．
Java程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中（在JDK 1.3之
后，Javac就去除了-O选项，不会生成任何字节码级别的优化代码了），因此一般来说，即时编译器产生的本地代码会比Javac产生的字节码更加优秀[1]。本篇博客，我们将一起学习HotSpot虚拟机的即时编译器在生成代码时采用的代码优化技术。
优化技术概览
在Sun官方的Wiki上，HotSpot虚拟机设计团队列出了一个相对比较全面的、 在即时编译器中采用的优化技术列表，其中有不少经典编译器的优化手段，也有许多针对Java语言（准确地说是针对运行在Java虚拟机上的所有语言）本身进行的优化技术。 
下面举一个简单的例子，即通过Java代码变化来展示其中几种优化技术是如何发挥作用的。
优化前的原始代码
static class B{
int value；
final int get（）{
return value；
} } p
ublic void foo（）{
y=b.get（）；
//……do stuff……
z=b.get（）；
sum=y+z；
}首先需要明确的是，这些代码优化变换是建立在代码的某种中间表示或机器码之上，绝不是建立在Java源码之上的，为了展示方便，这里使用了Java语言的语法来表示这些优化技术所发挥的作用。
上述代码已经非常简单了，但是仍有许多优化的余地。 第一步进行方法内联（Method Inlining），方法内联的重要性要高于其他优化措施，它的主要目的有两个，一是去除方法调用的成本（如建立栈帧等），二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。 因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。 内联后的代码下所示
内联后的代码
public void foo（）{
y=b.value；
//……do stuff……
z=b.value；
sum=y+z；
}第二步进行冗余访问消除（Redundant Loads Elimination），假代码中间注释掉的“dostuff……”所代表的操作不会改变b.value的值，那就可以把“z=b.value”替换为“z=y”，因为上一句“y=b.value”已经保证了变量y与b.value是一致的，这样就可以不再去访问对象b的局部变量了。 如果把b.value看做是一个表达式，那也可以把这项优化看成是公共子表达式消除
（Common Subexpression Elimination），优化后的代码如下所示。
public void foo（）{
y=b.value；
//……do stuff……
z=y；
sum=y+z；
}第三步我们进行复写传播（Copy Propagation），因为在这段程序的逻辑中并没有必要使用一个额外的变量“z”，它与变量“y”是完全相等的，因此可以使用“y”来代替“z”。 复写传播之后程序如下所示。
复写传播的代码
public void foo（）{
y=b.value；
//……do stuff……
y=y；
sum=y+y；
}第四步我们进行无用代码消除（Dead Code Elimination）。 无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为“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；表达式进行变换之后，再计算起来就可以节省一些时间了。
数组边界检查消除
数组边界检查消除（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++程序容易很多， 但这些安全检查也导致了相同的程序，Java要比C/C++做更多的事情（各种检查判断），这些事情就成为一种隐式开销，如果处理不好它们，就很可能成为一个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信息自动选择最优方案。
方法内联
未做任何优化的字节码
public static void foo（Object obj）{
if（obj！=null）{
System.out.println（"do something"）；
}}p
ublic static void testInline（String[]args）{
Object obj=null；
foo（obj）；
}例子代码揭示了内联对其他优化手段的意义：事实上testInline（）方法的内部全部都是无用的代码，如果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何“Dead Code”，因为如果分开来看，foo（）和testInline（）两个方法里面的操作都可能是
有意义的。
无法内联的原因是，只有使用invokespecial指令调用的私有方法、 实例构造器、 父类方法以及使用invokestatic指令进行调用的静态方法才是在编译期进行解析的，除了上述4种方法之外，其他的Java方法调用都需要在运行时进行方法接收者的多态选择，并且都有可能存在多于一个版本的方法接收者（最多再除去被final修饰的方法这种特殊情况，尽管它使用invokevirtual指令调用，但也是非虚方法，Java语言规范中明确说明了这点），简而言之，Java语言中默认的实例方法是虚方法。
对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本，如果以上述代码中把“b.get（）”内联为“b.value”为例的话，就是不依赖上下文就无法确定b的实际类型是什么。 假如有ParentB和SubB两个具有继承关系的类，并且子类重写了父类的get（）方法，那么，是要执行父类的get（）方法还是子类的get（）方法，需要在运行期才能确定，编译期无法得出结论。
为了解决虚方法的内联问题，Java虚拟机设计团队想了很多办法，首先是引入了一种名为“类型继承关系分析”（Class Hierarchy Analysis,CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、 子类是否为抽象类等信息。
编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。 如果遇到虚方法，则会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个“逃生门”（Guard条件不成立时的Slow Path），称为守护内联（GuardedInlining）。 如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继
承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。 但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
如果向CHA查询出来的结果是有多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。 如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。
逃逸分析
逃逸分析（Escape Analysis）是目前Java虚拟机中比较前沿的优化技术，它与类型继关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。 甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如下所示。
栈上分配（Stack Allocation）：Java虚拟机中，在Java堆上分配创建对象的内存空间几乎是Java程序员都清楚的常识了，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。 虚拟机的垃圾收集系统可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费时间。
如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。 在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。
标量替换（Scalar Replacement）：标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型（int、 long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。 相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java中的对象就是最典型的聚合量。 如果把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。 如果逃
逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。 将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。
Sun JDK 1.6才实现了逃逸分析，而且直到现在这项优化尚未足够成熟，仍有很大的改进余地。 不成熟的原因主要是不能保证逃逸
分析的性能收益必定高于它的消耗。 如果要完全准确地判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂分析，从而确定程序各个分支执行时对此对象的影响。 这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间就白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。 还有一点是，基于逃逸分析的一些优化手段，如上面提到的“栈上分配”，由于HotSpot虚
拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在HotSpot中暂时还没有做这项优化。
如果有需要，并且确认对程序运行有益，用户可以使用参数-XX：+DoEscapeAnalysis来手动开启逃逸分析，开启之后可以通过参数-XX：+PrintEscapeAnalysis来查看分析结果。 有了逃逸分析支持之后，用户可以使用参数-XX：+EliminateAllocations来开启标量替换，使用+XX：+EliminateLocks来开启同步消除，使用参数-XX：+PrintEliminateAllocations查看标量的替换情况。
尽管目前逃逸分析的技术仍不是十分成熟，但是它却是即时编译器优化技术的一个重要的发展方向，在今后的虚拟机中，逃逸分析技术肯定会支撑起一系列实用有效的优化技术。
Java与C/C++的编译器对比
Java虚拟机的即时编译器与C/C++的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势（下面列举的也包括一些虚拟机执行子系统的性能劣势）：
第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。 如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。
第二，Java语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。 从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检查空指针、 数组元素访问时检查上下界范围、 类型转换时检查继承关系等。 对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。
第三，Java语言中虽然没有virtual关键字，但是使用虚方法的频率却远远大于C/C++语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于C/C++语言，也意味着即时编译器在进行一些优化（如前面提到的方法内联）时的难度要远大于C/C++的静态优化编译器。
第四，Java语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。
第五，Java语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。 而C/C++的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。 另外，C/C++中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。
但从另外的角度来说，还有许多优化是Java的即时编译器能做而C/C++的静态优化编译器不能做或者不好做的。 例如，在C/C++中，别名分析（Alias Analysis）的难度就要远高于Java。 Java的类型安全保证了在类似如下代码中，只要ClassA和ClassB没有继承关系，那对象objA和objB就绝不可能是同一个对象，即不会是同一块内存两个不同别名。
void foo（ClassA objA,ClassB objB）{
objA.x=123；
objB.y=456；
//只要objB.y不是objA.x的别名，下面就可以保证输出为123
print（objA.x）；
}
确定了objA和objB并非对方的别名后，许多与数据依赖相关的优化才可以进行（重排序、 变量代换）。 具体到这个例子中，就是无须担心objB.y其实与objA.x指向同一块内存，这样就可以安全地确定打印语句中的objA.x为123。
Java编译器另外一个红利是由它的动态性所带来的，由于C/C++编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测、 分支频率预测、 裁剪未被选择的分支等，这些都会成为Java语言独有的性能优势