本文主要是介绍深入理解JVM之早期（编译期）优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
读了深入理解JVM之早期优化这一章，JVM作者从编译期源码实现的层次上让我们了解了Java源代码编译为字节码的过程，分析了Java语言中泛型、主动装箱/拆箱、条件编译等多种语法糖的前因后果，并实战练习了如何使用插入式注解处理器来完成一个检查程序命令规范的编译器插件。在前端编译器中，“优化”手段主要用于提升程序的编码效率，之所以把Javac这类将java代码转变为字节码的编译器称做“前端编译器”，是因为它只完成了从程序到抽象语法树或中间字节码的生成，而在此之后，还有一组内置于虚拟机内部的“后端编译器”完成了从字节码生成本地机器码的过程，即前面多次提到了即时编译器或JIT编译器，这个编译器的编译速度及编译结果的优劣，是衡量虚拟机性能一个很重要的指标。
1：概述
java语言的“编译期”其实是一段“不确定”的操作过程，因为它可能是指一个前端编译器（其实叫“编译器的前端”更准确点）把*.java文件转化为*.class文件的过程；也可能是指虚拟机的后端运行期编译器（JIT编译器，Just In Time Compiler）把字节码转化为机器码的过程；还可能是指使用静态提前编译器（AOT编译器，Ahead Of Time Compiler）直接把*.java文件编译成本地机器代码的过程。下面列举了这3类编译过程中一些比较有代表性的编译器。
1，前端编译器：Sun的Javac、Eclipse JDT中的增量式编译器（ECJ）；
2，JIT编译器：HotSpot VM的C1、C2编译器；
3，AOT编译器：GNU Compiler for the Java（GCJ）、Excelsior JET；
这3类过程中最符合大家对Java程序编译认知的应该是第一类，在本章的后续文字里，JVM笔者提到的“编译期”和“编译器”都仅限于第一类编译过程，把第二类编译过程留到下一章中讨论。限制了编译范围后，我们对于“优化”二字的定义就需要宽松一些，因为Javac这类编译器对代码的运行效率几乎没有任何优化措施。虚拟机设计团队把对性能的优化集中到了后端的即时编译器中，这样可以让那些不是由Javac产生的Class文件（如JRuby、Groovy等语言的Class文件）也同样能享受到编译器优化所带来的好处。但是Javac做了许多针对Java语言编码过程的优化措施来改善程序员的编码风格和提高编码效率。相当多新生的Java语法特性，都是靠编译器的“语法糖”来实现，而不是依赖虚拟机的底层改进来支持，可以说，Java中即时编译器在运行期的优化过程对于程序运行来说更重要，而前端编译器在编译期的优化过程对于程序编码来说关系更加密切。
2：Javac编译器
分析源码是了解一项技术的实现内幕最有效的手段，Javac编译器不像HotSpot虚拟机那样使用C++语言（包含C少量C语言）实现，它本身就是一个由Java语言编写的程序，这为纯Java的程序员了解它的编译过程带来了很大的便利。
1：Javac的源码与调试
Javac的源码存放在JDK_SRC_HOME/langtools/src/share/classes/com/sun/tools/javac中，除了JDK自身的API外，就只用了JDK_SRC_HOME/langtools/src/share/classes/com/sum/*里面的代码，调试环境建立起来简单方便，因为基本上不需要处理依赖关系。
以Eclipse IDE环境为例，先建立一个名为“Compiler_javac”的Java工程，然后把JDK_HOME/langtools/src/share/classes/com/sun/*目录下的源文件全部复制到工程的源码目录中，如图10-1所示。
导入代码期间，源文件“AnnotationProxyMaker.java”可能会提示"Access Restriction"，被eclipse拒绝编译，如图10-2所示：
这是由于Eclipse的JRE System Library中默认包含了一系列的代码访问规则（Access Rules），如果代码中引用了这些访问规则所禁止引用的类，就会提示这个错误。可以通过添加一条允许访问JRE包中所有类的访问规则来解决这个问题，如图10-3所示：
导入了Javac的源码后，就可以运行com.sun.tools.javac.Main的main()方法来执行编译了，与命令行中使用的Javac的命令没有什么区别，编译的文件与参数在Eclipse的“Debug Configurations”面板中的“Arguments”页签中制定。
虚拟机规范严格定义了Class文件的格式，但是《JVM虚拟机规范（第二版）》中，虽然有专门的一章“Compiling for the Java Virtual Machine”，但都是以举例的形式描述，并没有如何把Java源码文件转变为Class文件的编译过程进行十分严格的定义，这导致Class文件编译在某种程度上是与具体JDK实现相关的，在一些极端情况，可能出现一段代码Javac编译器可以编译，但是ECJ编译器就不可以编译的问题（10.3.1节中将会给出这样的例子）。从Sun Javac的代码来看，编译过程大致可以分为3个过程，分别是：
1，解析与填充符合表过程；
2，插入式注解处理器的注解处理过程；
3，分析与字节码生成过程。
这三个步骤之间的关系与交互顺序如图10-4所示：
Javac编译动作的入口是com.sun.tools.javac.main.JavaCompiler类，上述3个过程的代码逻辑集中在这个类的compile()和compile2()方法中，其中主体代码如图10-5所示，整个编译最关键的处理就由图中标注的8个方法来完成，下面我们具体看一下这8个方法实现了什么功能。
2：解析与填充符号表
解析步骤由图10-5中的parseFile（）方法（图10-5中的过程1.1）完成，解析步骤包括了经典程序编译原理中的词法分析和语法分析两个过程。
1：词法、语法分析
词法分析是将源代码的字符流转变为标记（Token）集合，单个字符是程序编写过程的最小元素，而标记则是编译过程的最小元素，关键字、变量名、字面量、运算符都可以成为标记，如“int a = b + 2”这句代码包含了6个标记，分别是int、a、=、b、+、2，虽然关键字int由3个字符构成，但是它只是一个Token，不可再拆分。在Javac的源码中，词法分析过程由com.sun.tools.javac.parser.Scanner类来实现。
语法分析是根据Token序列构造抽象语法树的过程，抽象语法树（Abstract Syntax Tree，AST）是一种用来描述程序代码语法结构的树形表示方式，语法树的每一个阶段都代表着程序代码中的一个语法结构（Construct），例如包、类型、修饰符、运算符、接口、返回值甚至代码注释等都可以是一个语法结构。
图10-6是根据Eclipse AST View插件分析出来的某段代码的抽象语法树视图，读者可以通过这张图对抽象语法树有一个直观的认识。在Javac的源码中，语法分析过程由com.sun.tools.javac.parser.Parser类实现，编译器就基本不会再对源码文件进行操作了，后续的操作都建立在抽象语法树之上。
2：填充符号表
完成了语法分析和词法分析之后，下一步就是填充符号表的过程，也就是图10-5中enterTress()方法（图10-5中的过程1.2）所做的事情。符号表（Symbol Table）是由一组符号地址和符号信息构成的表格，读者可以把它想象成哈希表中K-V值对的形式（实际上符号表不一定是哈希表实现，可以是有序号表、树状符号表、栈结构符号表等）。符号表中所登记的信息在编译的不同阶段都要用到。在语义分析中，符号表所登记的内容将用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码。在目标代码生成阶段，当对符号名进行地质分配时，符号表是地址分配的依据。
在Javac源代码中，填充符号表的过程由com.sun.tools.javac.comp.Enter类实现，此过程的出口是一个待处理列表（To Do List），包含了每一个编译单元的抽象语法树的顶级节点，以及package-info.java（如果存在的话）的顶级节点。
3：注解处理器
在JDK1.5之后，Java语言提供了对注解（Annotation）的支持，这些注解与普通的Java代码一样，是在运行期间发挥作用的。在JDK1.6中实现了JSR-269规范，提供了一组插入式注解处理器的标准API在编译期间对注解进行处理，我们可以把它看做是一组编译器的插件，在这些插件里面，可以读取、修改、添加抽象语法树中的任意元素。如果这些插件在处理注解期间对语法树进行了修改，编译器将回到解析及填充符号表的过程重新处理，直到所有插入式注解处理器都没有再对语法树进行修改为止，每一次循环称为一个Round，也就是图10-4中的回环过程。
有了编译器注解处理的标准API后，我们的代码才有可能干涉编译器的行为，由于语法树中的任意元素，甚至包括代码注释都可以在插件之中访问到，所以通过插入式注解处理器实现的插件在功能上有很大的发挥空间。只要有足够的创意，程序员可以使用插入式注解处理器来实现许多原本只能在编码中完成的事情，本章最后会给出一个使用插入式注解处理器的简单实战。
在Javac源码中，插入式注解处理器的初始化过程是在initPorcessAnnotations()方法中完成的，而它的执行过程则是在processAnnotations()方法中完成的，这个方法判断是否还有新的注解处理器需要执行，如果有的话，通过com.sun.tools.javac.processing.JavacProcessingEnvironment类的doProcessing（）方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理。
4：语义分析与字节码生成
语法分析之后，编译器获得了程序代码的抽象语法树表示，语法树能表示一个结构正确的源程序的抽象，但无法保证源程序是符合逻辑的。而语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查，如进行类型审查。举个例子，假设有如下的3个变量定义语句：
int a = 1;
boolean b = false;
char c = 2;int d = a + c;
int d = b + c;
char d = a + c;后续代码中如果出现了如上3中赋值运算的话，那它们都能构成结构正确的语法树，但是只有第一种的写法在语义上是没有问题的，能够通过编译，其余两种在Java语言中是不合逻辑的，无法编译（是否合乎语义逻辑必须限定在具体的语言与具体的上下文环境之中才有意义。如在C语言中，a、b、c的上下文定义不变，第2、3种写法都是可以正确编译）。
1：标注检查
Javac的编译过程中，语义分析过程分为标注检查以及数据及控制流分析两个步骤，分别由图10-5中所示的attribute()和flow()方法（分别对应图10-5中的过程3.1和过程3.2）完成。
标注检查步骤检查的内容包括诸如变量使用前是否已被声明、变量与赋值之间的数据类型是否能够匹配等。在标注检查步骤中，还有一个重要的动作称为常量折叠，如果我们在代码中写了如下定义：
int a = 1 + 2;标注检查步骤在Javac源码中的实现类是com.sun.tools.javac.comp.Attr和com.sun.tools.javac.comp.Check类。
2：数据及控制流分析
数据及控制流分析是对程序上下文逻辑更进一步的验证，它可以检查出诸如程序局部变量在使用前是否有赋值、方法的每条路径是否都有返回值、是否所有的受查异常都被正确处理了等问题。编译时期的数据及控制流分析与类加载时的数据及控制流分析的目的基本上是一致的，但校验范围有所区别，有一些校验项只有在编译期或运行期才能进行。下面举一个关于final修饰符的数据及控制流分析的例子，见代码清单10-1：
//代码清单10-1 final语义校验
//方法一带有final修饰
public void foo(final int arg){final int var = 0;//do something
}//方法二没有final修饰
public void foo(int arg){int var = 0;//do something
}在这两个foo()方法中，第一种方法的参数和局部变量定义使用了final修饰符，而第二种方法则没有，在代码编写的时程序肯定会受到final修饰符的影响，不能再改变arg和var变量的值，但是这两段代码编译出来的Class文件是没有任何一点区别的，通过第六章的讲解我们已经知道，局部变量与字段（实例变量、类变量）是有区别的，它在常量池中没有CONSTANT_Fieldref_info的符号引用，自然就没有访问标志（Access_Flags）的信息，甚至可能连名称都不会保留下来（取决于编译时的选项），自然在Class文件中不可能知道一个局部变量是不是声明为final了。因此，将局部变量声明为final，对运行期是没有影响的，变量的不变性仅仅由编译器在编译期间保障。在Javac的源码中，数据及控制流分析的入口是图10-5中的flow()方法（对应图10-5中的过程3.2），具体操作有com.sun.tools.javac.comp.Flow类来完成。
3：解语法糖
语法糖（System Sugar），也成糖衣语法，是由英国计算机科学家彼得-约翰-兰达（Peter J.Landin）发明的一个术语，指在计算机语言中添加的某种语法，这种语法对语言的功能并没有影响，但是更方便程序员使用。通常来说，使用语法糖能够增加程序的可读性，从而减少程序代码出粗的机会。
Java在现代编程语言之中属于“低糖语言”（相对于C#及许多其他JVM语言来说），尤其是JDK1.5之前的版本，“低糖”语法也是Java语言被怀疑已经“落后”的一个表面理由。Java中最常用的语法糖主要是前面提到过的泛型（泛型并不一定都是语法糖实现，如C#的泛型就是直接由CLP支持的）、变长参数、自动装箱/拆箱等，虚拟机运行时不支持这些语法，它们在编译阶段还原回简单地基础语法结构，这个过程称为解语法糖。Java的这些语法糖被解除后是什么样子，将在10.3节中详细讲述。
在Javac的源码中，解语法糖的过程由desugar()方法触发，在com.sun.tools.javac.comp.TransTypes类和com.sun.tools.javac.comp.Lower类中完成。
4：字节码生成
字节码生成是Javac编译过程的最后一个阶段，在Javac源码里面由com.sun.tools.javac.jvm.Gen类来完成。字节码生成阶段不仅仅是把前面各个步骤所生成的信息（语法树、符号表）转化成字节码写到磁盘中，编译器还进行了少量的代码添加和转换工作。
例如，前面章节中多次提到的实例构造器<init>（）方法和类构造器<clinit>（）方法就是在这个阶段添加到语法树之中的（注意，这里的实例构造器并不是指默认构造函数，如果用户代码中没有提供任何构造函数，那编译器将会添加一个没有参数的、访问性（public、protected或private）与当前类一致的默认构造函数，这个工作在填充符号表阶段就已经完成），这两个构造器的产生过程实际上是一个代码收敛的过程，编译器会把语句块（对于实例构造器而言是“{}”块，对于类构造器而言是“static{}”块）、变量初始化（实例变量和类变量）、调用父类的实例构造器（仅仅是实例构造器，<clinit>()方法中无须调用父类的<clinit>()方法，虚拟机会自动保证父类构造器的执行，但在<clinit>()方法中经常会调用java.lang.Object的<init>()方法的代码）等操作收敛到<init>()和<clinit>()方法之中，并且保证一定是按先执行父类的实例构造器，然后初始化变量，最后执行语句块的顺序进行，上面所述的动作由Gen.normalizeDefs()方法来实现。除了生成构造器以外，还有其他的一些代码替换工作用于优化程序的实现逻辑，如把字符串的加操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK1.5）的append()操作。
完成了对语法树的遍历和调整之后，就会把填充了所需信息的符号表交给com.sun.tools.javac.jvm.ClassWriter类，由这个类的writeClass()方法输出字节码，生成最终的Class文件，到此为止整个编译过程宣告结束。
3：Java语法糖的味道
几乎各种语言或多或少都提供过一些语法糖来方便程序员的代码开发，这些语法糖虽然不会提供实质性的功能改进，但是它们或能提高效率，或能提升语法的严谨性，或能较少编码出错的机会。不过也有一种观点认为语法糖并不一定都是有益的，大量添加和使用“含糖”的语法，容易让程序员产生依赖，无法看清语法糖的躺椅背后，程序代码的真实面目。
总而言之，语法糖可以看做是编译器实现的一些“小把戏”，这些“小把戏”可能会使得效率“大提升”，但我们也应该去了解这些“小把戏”背后的真实世界，那样才能利用好它们，而不是被它们所诱惑。
1：泛型与类型擦除
泛型是JDK1.5的一项新增特性，它的本质是参数化类型（Parametersized Type）的应用，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。
泛型思想早在C++语言的模板（Template）中就开始生根发芽，在Java语言处于还没有出现泛型的版本时，只能通过Object是所有类型的父类和类型强制转换两个特点的配合来实现类型泛化。例如，在哈希表的存取中，JDK1.5之前使用HashMap的get()方法，返回值就是一个Object对象，由于Java语言里面所有的类型都继承于java.lang.Object，所以Object转型成任何对象都是有可能的。但是也因为无限的可能性，就只有程序员和运行期的虚拟机才知道这个Object到底是个什么类型的对象。在编译期间，编译器无法检查这个Object的强制转型是否成功，如果仅仅依赖程序员区保障这项操作的正确性，许多ClassCastException的风险就会转嫁到程序运行之中。
泛型技术在C#和Java之中的使用方式看似相同，但实现上却有着根本性的分析，C#里面泛型无论在程序源码中、编译后的IL中（Intermediate Language，中间语言，这时候泛型是一个占位符），或是运行期的CLR中，都是切实存在的，List<int>与List<String>就是两个不同的类型，它们在系统运行期生成，有自己的虚方法表和类型数据，这种实现称为类型膨胀，基于这种方法实现的泛型称为真实泛型。
Java语言中的泛型则不一样，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（Raw Type，也称为裸类型）了，并且在相应的地方插入了强制转型代码，因此，对于运行期的Java语言来说，ArrayList<int>与ArrayList<String>就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。
代码清单10-2是一段简单的Java泛型的例子，我们可以看一下它编译后的结果是怎样的。
//10-2 泛型擦除前的例子
public static void main(String []args){Map<String, String> map = new HashMap<String, String>();map.put("hello", "您好");map.put("how are you?", "吃了没？");System.out.println(map.get("hello"));System.out.println(map.get("how are you?"));
}这段代码编译成Class文件，然后再用字节码反编译工具进行反编译后，将会发现泛型都不见了，程序又变回了Java泛型出现之前的写法，泛型类型都变回了原生类型，如代码清单10-3所示：
//代码清单10-3 泛型擦除后的样子public static void main(String[] args) {Map map = new HashMap();map.put("hello", "你好,");map.put("how are you!", "吃了么?");System.out.println((String)map.get("hello"));System.out.println((String)map.get("how are you!"));}当初JDK设计团队为什么选择类型擦除的方式来实现Java语言的泛型支持呢？是因为实现简单，兼容性考虑还是别的原因？我们已不得而知，但确实有不少人对Java语言提供的伪泛型颇有微词，当时甚至连《Thinking in Java》一书的作者Bruce Eckel也发表了一篇文章《这不是泛型！》来批评1.5中的泛型实现。
在当时众多的批评之中，有一些是比较表面的，还有一些从性能上说泛型会由于强制转型操作和运行期缺少针对类型的优化等从而导致比C#的泛型慢一些，则是完全偏离了方法，姑且不论Java泛型是不是真的会比C#泛型慢，选择从性能的角度上评价用于提升语义准确性的泛型思想就不太恰当。但笔者也并非在为Java的泛型辩护，它在某些场景下确实存在不足，笔者认为通过擦除法来实现泛型丧失了一些泛型实现应有的优雅，例如代码清单10-4的例子。
/*** 代码清单10-4* 当泛型遇到重载 1* @author Peter**/
public class GenericTypes {public static void method(List<String> list){System.out.println("invoke method(List<String> list)");}public static void method(List<Integer> list){System.out.println("invoke method(List<Integer> list)");}
}
/*** 代码清单10-5* 当泛型遇到重载2* @author Peter**/
public class GenericTypes1 {public static String method(List<String> lits){System.out.println("invoke method(List<String> list)");return "";}public static int method(List<Integer> list){System.out.println("invoke method(List<Integer> list)");return 1;}public static void main(String[] args) {method(new ArrayList<String>());method(new ArrayList<Integer>());}
}执行结果：
代码清单10-5与代码清单10-4的差别是两个method方法添加了不同的返回值，由于这两个返回值的加入，方法重载居然成功了，即这段代码可以被编译和执行了。这是对Java语言中返回值不参与重载选择的基本认知的挑战吗？
代码清单10-5中的重载当然不是根据返回值来确定的，之所以这次能编译和执行成功，是因为两个method()方法加入了不同的返回值后才能共存一个Class文件之中。第6章介绍Class文件方法表（method_info）的数据结构时曾经提到过，方法重载要求方法具备不同的特征签名，返回值并不包含在方法的特征签名之中，所以返回值不参与重载选择，但是在Class文件格式之中，只要描述符不是完全一致的两个方法就可以共存。也就是说，两个方法如果有相同的名称和特征签名，但返回值不同，那它们也是可以合法地共存于一个Class文件中的。
由于Java泛型的引入，各种场景（虚拟机解析、反射等）下的方法调用都可能对原有的基础产生影响和新的需求，如在泛型类中如何获取传入的参数化类型等。因此，JCP组织对虚拟机规范做出了相应的修改，引入了诸如Signature、LocalVariableTypeTable等新的属性用于解决伴随泛型而来的参数类型的识别问题，Signature是其中最重要的一项属性，它的作用就是存储一个方法在字节码层面的特征签名，这个属性中保存的参数类型并不是原生类型，而是包括了参数化类型的信息。修改后的虚拟机规范要求所有能识别49.0以上版本的Class文件的虚拟机都要能正确地识别Signature参数。
从上面的例子可以看出擦除法对实际编码带来的影响，由于List<String>和List<Integer>擦除后是同一个类型，我们只能添加两个并不需要实际使用到的返回值才能完成重载，这是一种毫无优雅和美感可言的解决方案，并且存在一定语义上的混乱，比如上面脚注提到的，必须用Sun JDK1.6的Javac才能编译成功，其他版本或者ECJ编译器都可能拒绝编译。
另外，从Signature属性的出现我们还可以得出结论，擦除法所谓的擦除，仅仅是对方法的Code属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息，这也是我们能通过反射手段取得参数化类型的根本依据。
2：自动装箱、拆箱与遍历循环
从纯技术的角度来讲，自动装箱、自动拆箱与遍历循环（Foreach循环）这些语法糖，无论是实现上还是思想上都不能和上文介绍的泛型相比，两个的难度和深度都有很大的差距。它们是Java语言里使用得最多的语法糖。通过代码清单10-6和代码10-7中所示的代码来看看语法糖在编译后会发生什么样的变化。
/*** 代码清单10-6* 自动装箱、拆箱与遍历循环* @author Peter**/
public class Test03 {public static void main(String []args){List<Integer> list = Arrays.asList(1, 2, 3, 4);//如果在JDK1.7中，还有另外一种语法糖//能让上面这句代码进一步简写成List<Integer> list = [1, 2, 3, 4];int sum = 0;for(int i : list){sum += i;}System.out.println(sum);}
}/*** 代码清单10-7* 自动装箱、拆箱与遍历循环编译之后* @author Peter**/
public class Test04 {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);}
} 这些语法糖虽然看起来很简单，但也不见得就没有任何值得我们注意的地方，代码清单10-8演示了自动装箱的一些错误用法。
/*** 代码清单10-8* 自动装箱的陷阱* @author Peter**/
public class Test05 {public static void main(String[] args) {Integer a = 1;Integer b = 2;Integer c = 3;Integer d = 3;Integer e = 321;Integer f = 321;Long g = 3L;System.out.println(c == d);System.out.println(e == f);System.out.println(c == ( a + b));System.out.println(c.equals(a+b));System.out.println(g == ( a + b));System.out.println(g.equals(a + b));}
}
3：编译条件
许多程序设计语言都提供了条件编译的途径，如C、C++中使用预处理指示符（#ifdef）来完成条件编译。C、C++的预处理器最初的任务是解决编译时的代码依赖关系（如非常常用的#include预处理命令），而在Java语言之中并没有使用预处理器，因为Java语言天然的编译方式（编译器并非一个个地编译Java文件，而是将所有编译单元的语法树顶级节点输入到待处理列表后再进行编译，因此各个文件之间能够互相提供符号信息）无须使用预处理器。那Java语言是否有办法实现条件编译呢？
Java语言当然也可以进行条件编译，方法就是使用条件为常量的if语句。代码清单10-9所示，此代码中的if语句不同于其他Java代码，它在编译阶段就会被“运行”，生成的字节码之中只包括“System.out.println("block 1");”一条语句，并不会包含if语句及另外一个分子中的“System.out.println("block 2")；”
/*** 代码清单10-9 Java语言的条件编译* @author Peter**/
public class Test06 {public static void main(String[] args) {if(true){System.out.println("block 1");}else{System.out.println("block 2");}}
}public class Test06 {public static void main(String[] args) {System.out.println("block 1");}
}
/*** 代码清单10-10* 不能使用其他条件语句来完成条件编译* @author Peter**/
public class Test07 {public static void main(String[] args) {//编译器将会提示 “Unreachable code”while(false){System.out.println("");}}
}
除了本节中介绍的泛型、自动装箱、自动拆箱、遍历循环、变长参数和条件编译之外，Java语言还有不少其他的语法糖，如内部类、枚举类、断言语句、对枚举和字符串（在JDK1.7中支持）的switch支持、try语句中定义和关闭资源（在JDK1.7中支持）等，读者可以通过跟踪Javac源码、反编译Class文件等方式了解它们的本质实现。
这篇关于深入理解JVM之早期（编译期）优化的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
