一、早期（编译器）优化
1.编译期
Java 语言的 “编译期” 其实是一段 “不确定” 的操作过程，因为它可能是指
- 一个前端编译器（其实叫 “编译器的前端” 更准确一些）把 *.java 文件转变成 *.class 文件的过程；
- 也可能是指虚拟机的后端运行期编译器（JIT 编译器，Just In Time Compiler）把字节码转变成机器码的过程；
- 还可能是指使用静态提前编译器（AOT 编译器，Ahead Of Time Compiler）直接把 *.java 文件编译成本地机器代码的过程。
2.Javac编译器的编译过程
- 解析与填充符号表过程
- 插入式注解处理器的注解处理过程
- 分析与字节码生成过程
3.Java语法糖
几乎各种语言或多或少都提供过一些语法糖来方便程序员的代码开发，这些语法糖虽然不会提供实质性的功能改进，但是它们或能提高效率，或能提升语法的严谨性，或能减少编码出错的机会。
（1）泛型与类型擦除
泛型是 JDK 1.5 的一项新增特性，它的本质是参数化类型（Parametersized Type）的应用，也就是说操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。
Java 语言中的泛型则不一样，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型，并且在相应的地方插入了强制类型代码，因此，对于运行期的 Java 语言来说，ArrayList<int> 与 ArrayList<String> 就是同一个类，所以Java 语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。
使用类型擦除实现的泛型，在遇到重载时可能出现问题，如果每个方法的参数在类型擦除之后的参数类型一样，那么就无法选择正确的方法。解决这个问题的方法就是令两种不同的方法返回执行泛型的返回值，例如方法参数为ArrayList<int>的方法增加return 1; 语句，而方法参数为ArrayList<String>的方法增加return “"; 语句
（2）自动装箱、拆箱与遍历循环
例如：
public static void main(String[] args) { List<Integer> list = Arrays.asList(1, 2, 3, 4); // 如果在 JDK 1.8 中，还有另外一颗语法糖 // 能让上面这句代码进一步简写成 List<Integer> list = [1, 2, 3, 4]; int sum = 0; for (int i : list) { sum += i; } System.out.println(sum); }
在经过自动装箱、拆箱与遍历循环编译之后
public static void main(String[] args) { List list = Arrays.asList( new Integer[] { Integer.valueOf(1); Integer.valueOf(2); Integer.valueOf(3); Integer.valueOf(4); }}; int sum = 0; for(Iterator localIterator = list.iterator(); localIterator,hasNext(); ){ int i = ((Integer)localIterator.next()).intValue(); sum += i; } System.out.println(sum); }
可以看到，一共包含了泛型、自动装箱、自动拆箱、遍历循环与变长参数 5 种语法糖。泛型就不必说了，自动装箱、拆箱在编译之后被转换成了对应的包装和还原方法，如本例中的 Integer.valueOf() 与 Integer.intValue() 方法，而遍历循环则把代码还原 成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现Iterable接口的原因。最后再看看变长参数，它在调用的时候变成了一个数组类型的参数，例如new Integer[]，在变长参数出现之前，程序员就是使用数组来完成类似功能的。
（3）条件编译
在 Java 语言之中并没有使用预处理器，因为 Java 语言天然的编译方式（编译器并非一个个地编译 Java 文件，而是将所有编译单元的语法树顶级节点输入到待处理列表后再进行编译，因此各个文件直接能够互相提供符号信息）无须使用预处理器。
Java 语言当然也可以进行条件编译，方法就是使用条件为常量的 if 语法。例如下面的代码中的 if 语句不同于其他 Java 代码，它在编译阶段就会被 “运行”，生成的字节码之中之包括 “System.out.println("block 1"); ” 一条语句，并不会包含 if 语句及另外一个分子中的 “System.out.println("block 2);”
public static void main(String[] args) { if (true) { System.out.println("block 1"); } else { System.out.println("block 2"); } }
上述代码编译后Class文件的反编译结果为：
public static void main(String[] args) { System.out.println("block 1"); }
只能使用条件为常量的 if 语句才能达到上述效果，如果使用常量与其他带有条件判断能力的语句搭配，则可能在控制流分析中提示错误，被拒绝编译，例如“while(false) {...}”代码就无法进行编译。
Java 语言中条件编译的实现，也是 Java 语言的一颗语法糖，根据布尔常量值的真假，编译器将会把分支中不成立的代码块消除掉，这一工作将在编译器解除语法糖阶段完成。由于这种条件编译的实现方式使用了 if 语句，所以它必须遵循最基本的 Java 语法，只能写在方法体内部，因此它只能实现语句基本块（Block）级别的条件编译，而没有办法实现根据条件调整整个 Java 类的结构。
二、晚期（运行器）优化
在部分的商用虚拟机（Sun HotSpot、IBM J9）中，Java 程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码” （Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称 JIT 编译器）。
1.HotSpot虚拟机使用解释器与编译器并存的架构
解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。
同时，解释器还可以作为编译器激进优化时的一个 “逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现 “罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的 C1（注：在虚拟机中习惯将 Client Compiler 称为 C1，将 Server Compiler 称为 C2） 编译器担任 “逃生门” 的角色），因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作。
2.HotSpot虚拟机实现两个不同的即时编译器
HotSpot 虚拟机中内置了两个即时编译器、分别称为 Client Compiler 和 Server Compiler 或者简称为 C1 编译器和 C2 编译器（也叫 Opto 编译器）。目前主流的 HotSpot 虚拟机（Sun 系列 JDK 1.7 及之前版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用 “-client” 或 “-server” 参数去强制指定虚拟机运行在 Client 模式或 Server 模式。
3.编译对象与触发条件
在运行过程中会被即时编译器编译的“热点代码”有两类：
- 被多次调用的方法
- 被多次执行的循环体。
前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为 “热点代码” 是理所当然的。而后者则为了解决一个方法只被调用过一次或少量的几次，但是方法体内部存在循环次数较多的循环体内部存在循环次数较多的循环体的问题，这样循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是 “热点代码”。
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT 编译方式。而对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为 OSR 编译，即方法栈帧还在栈上，方法就被替换了）。
判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种：基于采样的热点探测和基于计数器的热点探测。
HotSpot虚拟机中使用第二种--基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器和回边计数器。
方法调用计数器用于统计方法被调用的次数，它的默认阈值在 Client 模式下是 1500 次，在 Server 模式下是 10 000 次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否查过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
回边计数器的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。
4.编译过程
- 在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（HIR）。HIR 使用静态单分配（Static Single Assignment，SSA）的形式来代表代码值，这可以使得一些在 HIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成 HIR 之前完成。
- 在第二个阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（LIR），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HIR 达到更高效的代码表示形式。-
- 最后阶段是在平台相关的后端使用线性扫描算法在 LIR 上分配寄存器，并在 LIR 上做窥孔（Peephole）优化，然后产生机器代码。
5.编译优化
Java 程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中。因此一般来说，即时编译器产生的本地代码会比 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; }
第一步进行方法内联，方法内联的重要性要高于其他优化措施，它的主要目的有两个，一是去除方法调用的成本（如建立栈帧等），二是为其他优化建立良好的基础。方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。
public void foo() { y = b.value; // ...do stuff... z = b.value; sum = y + z; }
第二步进行冗余访问消除（Redundant Loads Elimination），假设代码中间注释掉的 “do stuff...” 所代表的操作不会改变 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; }
（1）语言无关的经典优化技术之一：公共子表达式消除
公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替 E 就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。
例如，假设存在下面的代码：
int d = (c * b) * 12 + a + (a + b * c);
Javac编译器不会对上述代码进行任何优化，字节码为：
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);
这时，编译器还可能（取决于那种虚拟机的编译器以及具体的上下文而定）进行另外一种优化：代数化简（Algebraic Simplification），把表达式变为：
int d = E * 13 + a * 2;
（2）语言相关的经典优化技术之一：数组范围检查消除
隐式异常处理技术，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 信息自动选择最优方案。
（3）最重要的优化技术之一：方法内联
方法内联是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础。
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() 两个方法里面的操作都可能是有意义的。
方法内联的优化行为看起来很简单，不过是把目标方法的代码 “复制” 到发起调用的方法之中，避免发生真实的方法调用而已。但实际上 Java 虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的 Java 方法都无法进行内联。无法内联的原因是只有使用 invokespecial 指令调用的私有方法、实例构造器、父类方法以及使用invokestatic 指令进行调用的静态方法才是在编译期进行解析的，除了上述 4 种方法之外，其他的 Java 方法调用都需要在运行时进行方法接收者的多态选择，并且都可能存在多于一个版本的方法接收者（最多再除去被 final 修饰的方法这种特殊情况，尽管它使用 invokevirtual 指令调用，但也是非虚方法，Java 语言规范中明确说明了这点），简而言之，Java 语言中默认的实例方法是虚方法。
对于一个虚方法，编译期做内联的时候根本就无法确定应该使用哪个方法版本，假如有 ParentB 和 SubB 两个具有继承关系的类，并且子类重写了父类的 get() 方法，那么，是要执行父类的 get() 方法还是子类的 get() 方法，需要在运行期才能确定，编译期无法得出结论。
由于 Java 语言提倡使用面向对象的编程方式进行编程，而 Java 对象的方法默认就是虚方法，因此 Java 间接鼓励了程序员使用大量的虚方法来完成程序逻辑。根据上面的分析，如果内联与虚方法之间产生 “矛盾”，那该怎么办呢？是不是为了提高执行性能，就要到处使用 final 关键字去修饰方法呢？
为了解决虚方法的内联问题，Java 虚拟机设计团队想了很多办法，首先是引入了一种名为 “类型继承关系分析”（Class Hierarchy Analysis，CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。
编译器在进行内联时，如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。如果遇到虚方法，则会向 CHA 查询此方法在当前程序下是否有多个目标版本可供选择，如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个 “逃生门”（Guard 条件不成立时的 Slow Path），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
如果向 CHA 查询出来的结果是多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。
所以说，在许多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小（通过经验数据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支等都可以被激进优化 “移除”，如果真的出现了小概率事件，这时才会从 “逃生门” 回到解释状态重新执行。
（4）最前沿的优化技术之一：逃逸分析
逃逸分析（Escape Analysis）是目前 Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，方法包括：栈上分配、同步消除和标量替换。
6.Java与C/C++编译器的对比
Java 与 C/C++ 的编译器对比实际上代表了最经典的即时编译器与静态编译器的对比，很大程度上也决定了 Java 与 C/C++ 的性能对比的结果，因为无论是 C/C++ 还是 Java 代码，最终编译之后被机器执行的都是本地机器码，哪种语言的性能更高，除了它们自身的 API 库实现得好坏以外，其余的比较就成了一场 “拼编译器” 和 “拼输出代码质量” 的游戏。
Java虚拟机的即时编译器可能由于下列的原因导致输出的本地代码有一些劣势：
- 因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。
- 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。 - 另外一个红利是由它的动态性所带来的，由于 C/C++ 编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选中的分支（Untaken Branch Pruning）等，这些都会成为 Java 语言都有的性能优势。