《深刻理解Java虚拟机》-----第10章程序编译与代码优化-早期(编译期)优化

时间 2019-11-07

原文原文链接

概述

Java语言的“编译期”实际上是一段“不肯定”的操做过程,由于它多是指一个前端编译器(其实叫“编译器的前端”更准确一些)把*.java文件转变成*.class文件的过程;也多是指虚拟机的后端运行期编译器(JIT编译器,Just In Time Compiler )把字节码转变成机器码的过程 ;还多是指使用静态提早编译器(AOT编译器,Ahead Of Time Compiler ) 直接把*.java 文件编译成本地机器代码的过程。下面列举了这3类编译过程当中一些比较有表明性的编译器。前端

前端编译器:Sun的Javac、 Eclipse JDT中的增量式编译器( ECJ ) 。
JIT编译器:HotSpotVM的C一、C2编译器。
AOT编译器: GNU Compiler for the Java ( GCJ ) 、 Excelsior JET。

这3类过程当中最符合你们对Java程序编译认知的应该是第一类,在本章的后续文字里, 笔者提到的“编译期”和“编译器”都仅限于第一类编译过程,把第二类编译过程留到下一章中讨论。限制了编译范围后,咱们对于“优化”二字的定义就须要宽松一些,由于Javac这类编译器对代码的运行效率几乎没有任何优化措施(在JDK 1.3之后 ,Javac的-O 优化参数就再也不有意义 )。虚拟机设计团队把对性能的优化集中到了后端的即时编译器中,这样可让那些不是由Javac产生的Class文件 (如JRuby、Groovy等语言的Class文件 )也一样能享受到编译器优化所带来的好处。可是Javac作了许多针对Java语言编码过程的优化措施来改善程序员的编码风格和提升编码效率。至关多新生的Java语法特性,都是靠编译器的“语法糖”来实现,而不是依赖虚拟机的底层改进来支持,能够说,Java中即时编译器在运行期的优化过程对于程序运行来讲更重要,而前端编译器在编译期的优化过程对于程序编码来讲关系更加密切。java

Javac编译器

分析源码是了解一项技术的实现内幕最有效的手段,Javac编译器不像HotSpot虚拟机那样使用C++语言 (包含少许C语言 )实现 ,它自己就是一个由Java语言编写的程序,这为纯Java的程序员了解它的编译过程带来了很大的便利。git

Javac的源码与调试

Javac的源码存放在JDK_SRC_HOME/langtools/src/share/classes/com/sun/tools/javac中, 除了JDK自身的API外 ,就只引用了JDK_SRC_HOME/langtools/src/share/classes/com/sun/*里面的代码 ,调试环境创建起来简单方便,由于基本上不须要处理依赖关系。程序员

以Eclipse IDE环境为例,先创建一个名为“Compiler_javac”的Java工程,而后把 JDK_SRC_HOME/langtools/src/share/classes/com/sun/*目录下的源文件所有复制到工程的源码目录中 ,如图10-1所示。编程

导入代码期间,源码文件“AnnotationProxyMaker.java”可能会提示“Access Restriction”, 被Eclipse拒绝编译,如图10-2 所示。后端

这是因为Eelipse的JRE System Library中默认包含了一系列的代码访问规则(Access Rules ) , 若是代码中引用了这些访问规则所禁止引用的类,就会提示这个错误。能够经过添加一条容许访问JAR包中全部类的访问规则来解决这个问题,如图10-3所示。数组

导入了Javac的源码后,就能够运行com.sun.tools.javac.Main的main ()方法来执行编译了 ,与命令行中使用Javac的命令没有什么区别,编译的文件与参数在Eclipse的“Debug Configurations”面板中的“Arguments”页签中指定。数据结构

虚拟机规范严格定义了Class文件的格式,可是《 Java虚拟机规范(第2版)》中,虽然有专门的一章“Compiling for the Java Virtual Machine” , 但都是以举例的形式描述,并无对如何把Java源码文件转变为Class文件的编译过程进行十分严格的定义,这致使Class文件编译在某种程度上是与具体JDK实现相关的,在一些极端状况,可能出现一段代码.Javac编译器能够编译,可是ECJ编译器就不能够编译的问题。从Sun Javac的代码来看,编译过程大体能够分为3个过程,分别是:app

解析与填充符号表的过程。
插入式注解处理器的注解处理过程。
分析与字节码生成过程。

这3个步骤之间的关系与交互顺序如图10-4所示。框架

Javac编译动做的入口是com.sun.tools.javac.main.JavaCompiler类 ,上述3个过程的代码逻辑集中在这个类的compile() 和compile2() 方法中,其中主体代码如图10-5所示,整个编译最关键的处理就由图中标注的8个方法来完成,下面咱们具体看一下这8个方法实现了什么功能。

解析与填充符号表

解析步骤由图10-5中的parseFiles()方法(图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类实现,这个阶段产出的抽象语法树由com.sun.tools.javac.tree.JCTree类表示,通过这个步骤以后,编译器就基本不会再对源码文件进行操做了,后续的操做都创建在抽象语法树之上。

2.填充符号表

完成了语法分析和此法分析后，下一步就是填充符号表的过程，也就是图10-5中enterTrees()方法（图10-5中的过程1.2）所作的事情。符号表（Symbol Table）是由一组符号地址和符号信息构成的表格，读者能够把它想象成哈希表中K-V值对的形式（实际上符号表不必定是哈希表实现，能够是有序符号表、树状符号表、栈结构符号表等）。符号表中所登记的信息在编译的不一样阶段都要用到。在语义分析中，符号表所登记的内容将用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码。在目标生成阶段，当对符号名进行地址分配时，符号表是地址分配的依据。

在Javac源代码中,填充符号表的过程由com.sun.tools.javac.comp.Enter类实现,此过程的出口是一个待处理列表( To Do List ) ,包含了每个编译单元的抽象语法树的顶级节点, 以及package-info.java ( 若是存在的话）的顶级节点。

注解处理器

在JDK 1.5以后,Java语言提供了对注解(Annotation ) 的支持,这些注解与普通的Java代码同样,是在运行期间发挥做用的。在JDK 1.6中实现了JSR-269规范 ,提供了一组插入式注解处理器的标准API在编译期间对注解进行处理,咱们能够把它看作是一组编译器的插件 ,在这些插件里面,能够读取、修改、添加抽象语法树中的任意元素。若是这些插件在处理注解期间对语法树进行了修改,编译器将回到解析及填充符号表的过程从新处理,直到全部插入式注解处理器都没有再对语法树进行修改成止,每一次循环称为一个Round,也就是图10-4中的回环过程。

有了编译器注解处理的标准API后 ,咱们的代码才有可能干涉编译器的行为,因为语法树中的任意元素,甚至包括代码注释均可以在插件之中访问到,因此经过插入式注解处理器实现的插件在功能上有很大的发挥空间。只要有足够的创意,程序员可使用插入式注解处理器来实现许多本来只能在编码中完成的事情,本章最后会给出一个使用插入式注解处理器的简单实战。

在Javac源码中,插入式注解处理器的初始化过程是在initPorcessAnnotations() 方法中完成的,而它的执行过程则是在processAnnotations() 方法中完成的,这个方法判断是否还有新的注解处理器须要执行,若是有的话,经过com.sun.tools.javac.processing.JavacProcessingEnvironment类的doProcessing() 方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理。

语义分析与字节码生成

语法分析以后,编译器得到了程序代码的抽象语法树表示,语法树能表示一个结构正确的源程序的抽象,但没法保证源程序是符合逻辑的。而语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查,如进行类型审查。举个例子,假设有以下的3个变量定义语句:

int a=1;
boolean b=false; 
char c=2;

后续可能出现的賦值运算:

int d=a+c;
int d=b+c;
char d=a+c;

后续代码中若是出现了如上3种賦值运算的话,那它们都能构成结构正确的语法树,可是只有第1种的写法在语义上是没有问题的,可以经过编译,其他两种在Java语言中是不合逻辑的 ,没法编译 (是否合乎语义逻辑必须限定在具体的语言与具体的上下文环境之中才有意义。如在C语言中 ,a 、b 、c 的上下文定义不变,第2 、3种写法都是能够正确编译)。

1.标注检查

Javac的编译过程当中,语义分析过程分为标注检查以及数据及控制流分析两个步骤,分别由图10-5中所示的attribute() 和flow() 方法(分别对应图10-5中的过程3.1和过程3.2) 完成。

标注检查步骤检查的内容包括诸如变量使用前是否已被声明、变量与賦值之间的数据类型是否可以匹配等。在标注检查步骤中,还有一个重要的动做称为常量折叠,若是咱们在代码中写了以下定义:

int a=1+2;

那么在语法树上仍然能看到字面量“ 1”、“2”以及操做符“+”,可是在通过常量折叠以后 ,它们将会被折叠为字面量“3” ,如图10-7所示,这个插入式表达式( Mix Expression )的值已经在语法树上标注出来了(ConstantExpressionValue : 3 ) 。因为编译期间进行了常量折叠 ,因此在代码里面定义“a=1+2”比起直接定义“a=3” , 并不会增长程序运行期哪怕仅仅一个 CPU指令的运算量。

标注检查步骤在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文件是没有任何一点区别的,经过第6章的讲解咱们已经知道,局部变量与字段(实例变量、类变量)是有区别的,它在常量池中没有 CONSTANT_Fieldref_info的符号引用,天然就没有访问标志(Access_Flags ) 的信息,甚至可能连名称都不会保留下来(取决于编译时的选项),天然在Class文件中不可能知道一个局部变量是否是声明为final了。所以,将局部变量声明为final,对运行期是没有影响的,变量的不变性仅仅由编译器在编译期间保障。在Javac的源码中,数据及控制流分析的入口是图 10-5中的flow() 方法(对应图10-5中的过程3.2) ,具体操做由com.sun.tools.javac.comp.Flow类来完成。

3.解语法糖

语法糖( Syntactic Sugar ) , 也称糖衣语法,是由英国计算机科学家彼得•约翰•兰达 ( Peter J.Landin)发明的一个术语,指在计算机语言中添加的某种语法,这种语法对语言的功能并无影响,可是更方便程序员使用。一般来讲,使用语法糖可以增长程序的可读性, 从而减小程序代码出错的机会。

Java在现代编程语言之中属于“低糖语言” (相对于C#及许多其余JVM语言来讲),尤为是JDK 1.5以前的版本,“低糖”语法也是Java语言被怀疑已经“落后”的一个表面理由。Java中最经常使用的语法糖主要是前面提到过的泛型(泛型并不必定都是语法糖实现,如C#的泛型就是直接由CLR支持的 )、变长参数、自动装箱/拆箱等,虚拟机运行时不支持这些语法 ,它们在编译阶段还原回简单的基础语法结构,这个过程称为解语法糖。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 ( 取决于目标代码的版本是否大于或等于JDK 1.5 )的append() 操做等。

完成了对语法树的遍历和调整以后,就会把填充了全部所需信息的符号表交给 com.sun.tools.javac.jvm.ClassWriter类 ,由这个类的writeClass()方法输出字节码,生成最终的Class文件 ,到此为止整个编译过程宣告结束。

Java语法糖的味道

几乎各类语言或多或少都提供过一些语法糖来方便程序员的代码开发,这些语法糖虽然不会提供实质性的功能改进,可是它们或能提升效率,或能提高语法的严谨性,或能减小编码出错的机会。不过也有一种观点认为语法糖并不必定都是有益的,大量添加和使用“含糖”的语法,容易让程序员产生依赖,没法看清语法糖的糖衣背后,程序代码的真实面目。

总而言之,语法糖能够看作是编译器实现的一些“小把戏” ,这些“小把戏”可能会使得效率“大提高” ,但咱们也应该去了解这些“小把戏”背后的真实世界,那样才能利用好它们,而不是被它们所迷惑。

泛型与类型擦除

泛型是JDK 1.5的一项新增特性,它的本质是参数化类型( Parametersized Type )的应用 ,也就是说所操做的数据类型被指定为一个参数。这种参数类型能够用在类、接口和方法的建立中,分别称为泛型类、泛型接口和泛型方法。

泛型思想早在C++语言的模板( Template ) 中就开始生根发芽,在Java语言处于尚未出现泛型的版本时,只能经过Object是全部类型的父类和类型强制转换两个特色的配合来实现类型泛化。例如,在哈希表的取中, JDK 1.5以前使用HashMap的g et() 方法,返回值就是一个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?"));
}

把这段Java代码编译成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语言提供的伪泛型很有微词，当时甚至连《Thingking in Java》一书的做者Bruce Eckel也发表了一篇文章《这不是泛型！》来批评JDK1.5中的泛型实现。

在当时众多的批评之中，有一些是比较片面的，还有一些从性能上说泛型会因为强制转型操做和运行期缺乏针对类型的优化等从而致使比C#的泛型慢一些，则是彻底偏离了方向，姑且不论Java泛型是否是真的会比C#泛型慢，选择从性能的角度上评价用于提高语义准确性的泛型思想就不太恰当了。但笔者也并不是在为Java的泛型辩护，它在某些场景下确实存在不足，笔者认为经过擦除法来实现泛型丧失了一些泛型思想应有的优雅，例如代码清单10-4的例子。

代码清单10-4 当泛型碰见重载1

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)");
    }
}

请想想,上面这段代码是否正确,可否编译执行?也许你已经有了答案,这段代码是
不能被编译的,由于参数List<Integer>和List<Striiig>编译以后都被擦除了,变成了同样的原生类型List<E> ,擦除动做致使这两种方法的特征签名变得如出一辙。初步看来,没法重载的缘由已经找到了,但真的就是如此吗?只能说 ,泛型擦除成相同的原生类型只是没法重载的其中一部分缘由,请再接着看一看代码清单10-5中的内容。

代码清单10-5 当泛型碰见重载2

public class GenericTypes {

    public static String method(List<String> list) {
        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>());
    }
}

执行结果：

invoke method(List<String> list)
invoke method(List<Integer> list)

代码清单10-5与代码清单10-4的差异是两个method方法添加了不一样的返回值,因为这两个返回值的加入,方法重载竟然成功了,即这段代码能够被编译和执行了。这是对Java语言中返回值不参与重载选择的基本认知的挑战吗?

代码清单10-5中的重载固然不是根据返回值来肯定的,之因此此次能编译和执行成功, 是由于两个method() 方法加入了不一样的返回值后才能共存在一个Class文件之中。第6章介绍Class文件方法表( methodjnfo ) 的数据结构时曾经提到过,方法重载要求方法具有不一样的特征签名,返回值并不包含在方法的特征签名之中,因此返回值不参与重载选择,可是在Class文件格式之中,只要描述符不是彻底一致的两个方法就能够共存。也就是说,两个方法若是有相同的名称和特征签名,但返回值不一样,那它们也是能够合法地共存于一个Class文件中的。

因为Java泛型的引入,各类场景(虚拟机解析、反射等)下的方法调用均可能对原有的基础产生影响和新的需求,如在泛型类中如何获取传入的参数化类型等。所以 ,JCP组织对虚拟机规范作出了相应的修改,引入了诸如Signature、LocalVariableTypeTable等新的属性用于解决伴随泛型而来的参数类型的识别问题,Signature是其中最重要的一项属性,它的做用就是存储一个方法在字节码层面的特征签名,这个属性中保存的参数类型并非原生类型 ,而是包括了参数化类型的信息。修改后的虚拟机规范要求全部能识别49.0以上版本的 Class文件的虚拟机都要能正确地识别Signature参数。

从上面的例子能够看到擦除法对实际编码带来的影响,因为List<String> 和List<Integer> 擦除后是同一个类型,咱们只能添加两个并不须要实际使用到的返回值才能完成重载,这是一种毫无优雅和美感可言的解决方案,而且存在必定语意上的混乱,譬如上面脚注中提到的,必须用SunJDK 1.6的Javac才能编译成功,其余版本或者ECJ编译器均可能拒绝编译。

另外 ,从Signature属性的出现咱们还能够得出结论,擦除法所谓的擦除,仅仅是对方法的Code属性中的字节码进行擦除,实际上元数据中仍是保留了泛型信息,这也是咱们能经过反射手段取得参数化类型的根本依据。

注：在《Java虚拟机规范(第2版 ) 》 ( JDK 1.5修改后的版本)的“§4.4.4 Signatures”章节及《Java语言规范(第3版)》的“§8.4.2 Method Signature”章节中分别定义了字节码层面的方法特征签名,以及Java代码层面的方法特征签名,特征签名最重要的任务就是做为方法独一无二且不可重复的ID ,在Java代码中的方法特征签名只包括了方法名称、参数顺序及参数类型 ,而在字节码中的特征签名还包括方法返回值及受查异常表,本书中若是指的是字节码层面的方法签名,笔者会加入限定语进行说明,也请读者根据上下文语境注意区分。

自动装箱、拆箱与遍历循环

从纯技术的角度来说,自动装箱、自动拆箱与遍历循环(Foreach循环 )这些语法糖,不管是实现上仍是思想上都不能和上文介绍的泛型相比,二者的难度和深度都有很大差距。专门拿出一节来说解它们只有一个理由:毫无疑问,它们是Java语言里使用得最多的语法糖。咱们经过代码清单10-6和代码清单10-7中所示的代码来看看这些语法糖在编译后会发生什么样的变化。

代码清单10-6 自动装箱、拆箱与遍历循环

public static void main(String[] args) {
    List<Integer> list = Arrays.asList(1, 2, 3, 4);
    // 若是在JDK 1.7中，还有另一颗语法糖 ，
    // 能让上面这句代码进一步简写成List<Integer> list = [1, 2, 3, 4];
    int sum = 0;
    for (int i : list) {
        sum += i;
    }
    System.out.println(sum);
}

代码清单10-7 自动装箱、拆箱与遍历循环编译以后

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-6中一共包含了泛型、自动装箱、自动拆箱、遍历循环与变长参数5种语法糖 ,代码清单10-7则展现了它们在编译后的变化。泛型就没必要说了,自动装箱、拆箱在编译以后被转化成了对应的包装和还原方法,如本例中的Integer.valueOf() 与Integer.intValue() 方法,而遍历循环则把代码还原成了迭代器的实现,这也是为什么遍历循环须要被遍历的类实现Iterable接口的缘由。最后再看看变长参数,它在调用的时候变成了一个数组类型的参数,在变长参数出现以前,程序员就是使用数组来完成相似功能的。

这些语法糖虽然看起来很简单,但也不见得就没有任何值得咱们注意的地方,代码清单10-8演示了自动装箱的一些错误用法。

代码清单10-8 自动装箱的陷阱

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));
}

阅读完代码清单10-8,读者不妨思考两个问题:一是这6句打印语句的输出是什么?二是这6句打印语句中,解除语法糖后参数会是什么样子?这两个问题的答案能够很容易试验出来 ,笔者就暂且略去答案,但愿读者本身上机实践一下。不管读者的回答是否正确,鉴于包装类的“= ”运算在不遇到算术运算的状况下不会自动拆箱,以及它们equals()方法不处理数据转型的关系,笔者建议在实际编码中尽可能避免这样使用自动装箱与拆箱。

条件编译

许多程序设计语言都提供了条件编译的途径,如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语言的条件编译

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语句才能达到上述效果,若是使用常量与其余带有条件判断能力的语句搭配,则可能在控制流分析中提示错误,被拒绝编译,如代码清单10-10所示的代码就会被编译器拒绝编译。

代码清单10-10 不能使用其余条件语句来完成条件编译

public static void main(String[] args) {
    // 编译器将会提示“Unreachable code”
    while (false) {
        System.out.println("");
    }
}

Java语言中条件编译的实现,也是Java语言的一颗语法糖,根据布尔常量值的真假,编译器将会把分支中不成立的代码消除掉 ,这一工做将在编译器解除语法糖阶段
( com.sun.tools.javac.comp.Lower类中)完成。因为这种条件编译的实现方式使用了if语句,因此它必须遵循最基本的Java语法 ,只能写在方法体内部,所以它只能实现语句基本块 ( Block)级别的条件编译,而没有办法实现根据条件调整整个Java类的结构。

除了本节中介绍的泛型、自动装箱、自动拆箱、遍历循环、变长参数和条件编译以外 ,Java语言还有很多其余的语法糖,如内部类、枚举类、断言语句、对枚举和字符串(在 JDK 1.7中支持)的switch支持、try语句中定义和关闭资源(在JDK 1.7中支持)等 ,读者能够经过跟踪Javac源码、反编译Class文件等方式了解它们的本质实现。

实战：插入式注解处理器

JDK编译优化部分在本书中并无设置独立的实战章节，由于咱们开发程序，考虑的主要是程序会如何运行，不多会有针对程序编译的需求。也由于这个缘由，在JDK的编译子系统里面，提供给用户直接控制的功能相对较少，除了第11章会介绍的虚拟机JIT编译的几个相关参数之外，咱们就只有使用JSR-296中定义的插入式注解处理器API来对JDK编译子系统的行为产生一些影响。

可是笔者并不认为相对于前两部分介绍的内存管理子系统和字节码执行子系统，JDK的编译子系统就不那么重要。一套编程语言中编译子系统的优劣，很大程度上决定了程序运行性能的好坏和编码效率的高低，尤为在Java语言中，运行期即时编译与虚拟机执行子系统很是紧密地互相依赖、配合运做（第11章将主要讲解这方面的内容）。了解JDK如何编译和优化代码，有助于咱们写出适合JDK自优化的程序。下面咱们回到本章的实战中，看看插入式注解处理器API能实现什么功能。

实战目标

经过阅读Javac编译器的源码，咱们知道编译器在把Java程序源码编译为字节码的时候，会对Java程序源码作各方面的检查校验。这些校验主要以程序“写得对不对”为出发点，虽然也有各类WARNING的信息，但整体来说仍是较少去校验程序“写得好很差”。有鉴于此，业界出现了许多针对程序“写得好很差”的辅助校验工具，如CheckStyle、FindBug、Klocwork等。这些代码校验工具备一些是基于Java的源码进行校验，还有一些是经过扫描字节码来完成，在本节的实战中，咱们将会使用注解处理器API来编写一款拥有本身编码风格的校验工具：NameCheckProcessor。

固然，因为咱们的实战都是为了学习和演示技术原理，而不是为了作出一款能媲美CheckStyle等工具的产品来，因此NameCheckProcessor的目标也仅定为对Java程序命名进行检查，根据《Java语言规范（第3版）》中第6.8节的要求，Java程序命名应当符合下列格式的书写规范。

类（或接口）：符合驼式命名法，首字母大写。
方法：符合驼式命名法，首字母小写。
字段：
- 类或实例变量：符合驼式命名法，首字母小写。
- 常量：要求所有由大写字母或下划线构成，而且第一个字符不能是下划线。

上文提到的驼式命名法（Camel Case Name），正如它的名称所表示的那样，是指混合使用大小写字母来分割构成变量或函数的名字，犹如驼峰通常，这是当前Java语言中主流的命名规范，咱们的实战目标就是为Javac编译器添加一个额外的功能，在编译程序时检查程序名是否符合上述对类（或接口）、方法、字段的命名要求。

代码实现

要经过注解处理器API实现一个编译器插件，首先须要了解这组API的一些基本知识。咱们实现注解处理器的代码须要继承抽象类javax.annotation.processing.AbstractProcessor，这个抽象类中只有一个必须覆盖的abstract方法：“process（）”，它是Javac编译器在执行注解处理器代码时要调用的过程，咱们能够从这个方法的第一个参数“annotations”中获取到此注解处理器所要处理的注解集合，从第二个参数“roundEnv”中访问到当前这个Round中的语法树节点，每一个语法树节点在这里表示为一个Element。在JDK 1.6新增的javax.lang.model包中定义了16类Element，包括了Java代码中最经常使用的元素，如：“包（PACKAGE）、枚举（ENUM）、类（CLASS）、注解（ANNOTATION_TYPE）、接口（INTERFACE）、枚举值（ENUM_CONSTANT）、字段（FIELD）、参数（PARAMETER）、本地变量（LOCAL_VARIABLE）、异常（EXCEPTION_PARAMETER）、方法（METHOD）、构造函数（CONSTRUCTOR）、静态语句块（STATIC_INIT，即static{}块）、实例语句块（INSTANCE_INIT，即{}块）、参数化类型（TYPE_PARAMETER，既泛型尖括号内的类型）和未定义的其余语法树节点（OTHER）”。除了process（）方法的传入参数以外，还有一个很经常使用的实例变量“processingEnv”，它是AbstractProcessor中的一个protected变量，在注解处理器初始化的时候（init（）方法执行的时候）建立，继承了AbstractProcessor的注解处理器代码能够直接访问到它。它表明了注解处理器框架提供的一个上下文环境，要建立新的代码、向编译器输出信息、获取其余工具类等都须要用到这个实例变量。

注解处理器除了process（）方法及其参数以外，还有两个能够配合使用的Annotations：@SupportedAnnotationTypes和@SupportedSourceVersion，前者表明了这个注解处理器对哪些注解感兴趣，可使用星号“*”做为通配符表明对全部的注解都感兴趣，后者指出这个注解处理器能够处理哪些版本的Java代码。

每个注解处理器在运行的时候都是单例的，若是不须要改变或生成语法树的内容，process（）方法就能够返回一个值为false的布尔值，通知编译器这个Round中的代码未发生变化，无须构造新的JavaCompiler实例，在此次实战的注解处理器中只对程序命名进行检查，不须要改变语法树的内容，所以process（）方法的返回值都是false。关于注解处理器的API，笔者就简单介绍这些，对这个领域有兴趣的读者能够阅读相关的帮助文档。下面来看看注解处理器NameCheckProcessor的具体代码，如代码清单10-11所示。

代码清单10-11　注解处理器NameCheckProcessor

// 能够用"*"表示支持全部Annotations
@SupportedAnnotationTypes("*")
// 只支持JDK 1.6的Java代码
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public class NameCheckProcessor extends AbstractProcessor {

    private NameChecker nameChecker;

    /**
     * 初始化名称检查插件
     */
    @Override
    public void init(ProcessingEnvironment processingEnv) {
        super.init(processingEnv);
        nameChecker = new NameChecker(processingEnv);
    }

    /**
     * 对输入的语法树的各个节点进行进行名称检查
     */
    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        if (!roundEnv.processingOver()) {
            for (Element element : roundEnv.getRootElements())
                nameChecker.checkNames(element);
        }
        return false;
    }

}

从上面代码能够看出，NameCheckProcessor能处理基于JDK 1.6的源码，它不限于特定的注解，对任何代码都“感兴趣”，而在process（）方法中是把当前Round中的每个RootElement传递到一个名为NameChecker的检查器中执行名称检查逻辑，NameChecker的代码如代码清单10-12所示。

代码清单10-12　命名检查器NameChecker

/**
 * 程序名称规范的编译器插件：<br>
 * 若是程序命名不合规范，将会输出一个编译器的WARNING信息
 */
public class NameChecker {
    private final Messager messager;

    NameCheckScanner nameCheckScanner = new NameCheckScanner();

    NameChecker(ProcessingEnvironment processsingEnv) {
        this.messager = processsingEnv.getMessager();
    }

    /**
     * 对Java程序命名进行检查，根据《Java语言规范》第三版第6.8节的要求，Java程序命名应当符合下列格式：
     * 
     * <ul>
     * <li>类或接口：符合驼式命名法，首字母大写。
     * <li>方法：符合驼式命名法，首字母小写。
     * <li>字段：
     * <ul>
     * <li>类、实例变量: 符合驼式命名法，首字母小写。
     * <li>常量: 要求所有大写。
     * </ul>
     * </ul>
     */
    public void checkNames(Element element) {
        nameCheckScanner.scan(element);
    }

    /**
     * 名称检查器实现类，继承了JDK 1.6中新提供的ElementScanner6<br>
     * 将会以Visitor模式访问抽象语法树中的元素
     */
    private class NameCheckScanner extends ElementScanner6<Void, Void> {

        /**
         * 此方法用于检查Java类
         */
        @Override
        public Void visitType(TypeElement e, Void p) {
            scan(e.getTypeParameters(), p);
            checkCamelCase(e, true);
            super.visitType(e, p);
            return null;
        }

        /**
         * 检查方法命名是否合法
         */
        @Override
        public Void visitExecutable(ExecutableElement e, Void p) {
            if (e.getKind() == METHOD) {
                Name name = e.getSimpleName();
                if (name.contentEquals(e.getEnclosingElement().getSimpleName()))
                    messager.printMessage(WARNING, "一个普通方法 “" + name + "”不该当与类名重复，避免与构造函数产生混淆", e);
                checkCamelCase(e, false);
            }
            super.visitExecutable(e, p);
            return null;
        }

        /**
         * 检查变量命名是否合法
         */
        @Override
        public Void visitVariable(VariableElement e, Void p) {
            // 若是这个Variable是枚举或常量，则按大写命名检查，不然按照驼式命名法规则检查
            if (e.getKind() == ENUM_CONSTANT || e.getConstantValue() != null || heuristicallyConstant(e))
                checkAllCaps(e);
            else
                checkCamelCase(e, false);
            return null;
        }

        /**
         * 判断一个变量是不是常量
         */
        private boolean heuristicallyConstant(VariableElement e) {
            if (e.getEnclosingElement().getKind() == INTERFACE)
                return true;
            else if (e.getKind() == FIELD && e.getModifiers().containsAll(EnumSet.of(PUBLIC, STATIC, FINAL)))
                return true;
            else {
                return false;
            }
        }

        /**
         * 检查传入的Element是否符合驼式命名法，若是不符合，则输出警告信息
         */
        private void checkCamelCase(Element e, boolean initialCaps) {
            String name = e.getSimpleName().toString();
            boolean previousUpper = false;
            boolean conventional = true;
            int firstCodePoint = name.codePointAt(0);

            if (Character.isUpperCase(firstCodePoint)) {
                previousUpper = true;
                if (!initialCaps) {
                    messager.printMessage(WARNING, "名称“" + name + "”应当以小写字母开头", e);
                    return;
                }
            } else if (Character.isLowerCase(firstCodePoint)) {
                if (initialCaps) {
                    messager.printMessage(WARNING, "名称“" + name + "”应当以大写字母开头", e);
                    return;
                }
            } else
                conventional = false;

            if (conventional) {
                int cp = firstCodePoint;
                for (int i = Character.charCount(cp); i < name.length(); i += Character.charCount(cp)) {
                    cp = name.codePointAt(i);
                    if (Character.isUpperCase(cp)) {
                        if (previousUpper) {
                            conventional = false;
                            break;
                        }
                        previousUpper = true;
                    } else
                        previousUpper = false;
                }
            }

            if (!conventional)
                messager.printMessage(WARNING, "名称“" + name + "”应当符合驼式命名法（Camel Case Names）", e);
        }

        /**
         * 大写命名检查，要求第一个字母必须是大写的英文字母，其他部分能够是下划线或大写字母
         */
        private void checkAllCaps(Element e) {
            String name = e.getSimpleName().toString();

            boolean conventional = true;
            int firstCodePoint = name.codePointAt(0);

            if (!Character.isUpperCase(firstCodePoint))
                conventional = false;
            else {
                boolean previousUnderscore = false;
                int cp = firstCodePoint;
                for (int i = Character.charCount(cp); i < name.length(); i += Character.charCount(cp)) {
                    cp = name.codePointAt(i);
                    if (cp == (int) '_') {
                        if (previousUnderscore) {
                            conventional = false;
                            break;
                        }
                        previousUnderscore = true;
                    } else {
                        previousUnderscore = false;
                        if (!Character.isUpperCase(cp) && !Character.isDigit(cp)) {
                            conventional = false;
                            break;
                        }
                    }
                }
            }

            if (!conventional)
                messager.printMessage(WARNING, "常量“" + name + "”应当所有以大写字母或下划线命名，而且以字母开头", e);
        }
    }
}

NameChecker的代码看起来有点长，但实际上注释占了很大一部分，其实即便算上注释也不到190行。它经过一个继承于javax.lang.model.util.ElementScanner6的NameCheckScanner类，以Visitor模式来完成对语法树的遍历，分别执行visitType（）、visitVariable（）和visitExecutable（）方法来访问类、字段和方法，这3个visit方法对各自的命名规则作相应的检查，checkCamelCase（）与checkAllCaps（）方法则用于实现驼式命名法和全大写命名规则的检查。

整个注解处理器只需NameCheckProcessor和NameChecker两个类就能够所有完成，为了验证咱们的实战成果，代码清单10-13中提供了一段命名规范的“反面教材”代码，其中的每个类、方法及字段的命名都存在问题，可是使用普通的Javac编译这段代码时不会提示任何一个Warning信息。

代码清单10-13　包含了多处不规范命名的代码样例

public class BADLY_NAMED_CODE {

    enum colors {
        red, blue, green;
    }

    static final int _FORTY_TWO = 42;

    public static int NOT_A_CONSTANT = _FORTY_TWO;

    protected void BADLY_NAMED_CODE() {
        return;
    }

    public void NOTcamelCASEmethodNAME() {
        return;
    }
}

运行与测试

咱们能够经过Javac命令的“-processor”参数来执行编译时须要附带的注解处理器，若是有多个注解处理器的话，用逗号分隔。还可使用-XprintRounds和-XprintProcessorInfo参数来查看注解处理器运做的详细信息，本次实战中的NameCheckProcessor的编译及执行过程如代码清单10-14所示。

代码清单10-14　注解处理器的运行过程

D：\src＞javac org/fenixsoft/compile/NameChecker.java
D：\src＞javac org/fenixsoft/compile/NameCheckProcessor.java
D：\src＞javac-processor org.fenixsoft.compile.NameCheckProcessor org/fenixsoft/compile/BADLY_NAMED_CODE.java
org\fenixsoft\compile\BADLY_NAMED_CODE.java：3：警告：名称"BADLY_NAMED_CODE"应当符合驼式命名法（Camel Case Names）
public class BADLY_NAMED_CODE{
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：5：警告：名称"colors"应当以大写字母开头
enum colors{
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：6：警告：常量"red"应当所有以大写字母或下划线命名，而且以字母开头
red,blue,green；
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：6：警告：常量"blue"应当所有以大写字母或下划线命名，而且以字母开头
red,blue,green；
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：6：警告：常量"green"应当所有以大写字母或下划线命名，而且以字母开头
red,blue,green；
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：9：警告：常量"_FORTY_TWO"应当所有以大写字母或下划线命名，而且以字母开头
static final int_FORTY_TWO=42；
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：11：警告：名称"NOT_A_CONSTANT"应当以小写字母开头
public static int NOT_A_CONSTANT=_FORTY_TWO；
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：13：警告：名称"Test"应当以小写字母开头
protected void Test（）{
^
org\fenixsoft\compile\BADLY_NAMED_CODE.java：17：警告：名称"NOTcamelCASEmethodNAME"应当以小写字母开头
public void NOTcamelCASEmethodNAME（）{
^

其余应用案例

NameCheckProcessor的实战例子只演示了JSR-269嵌入式注解处理器API中的一部分功能，基于这组API支持的项目还有用于校验Hibernate标签使用正确性的Hibernate Validator Annotation Processor（本质上与NameCheckProcessor所作的事情差很少）、自动为字段生成getter和setter方法的Project Lombok（根据已有元素生成新的语法树元素）等，读者有兴趣的话能够参考它们官方站点的相关内容。

《深刻理解Java虚拟机》-----第10章 程序编译与代码优化-早期(编译期)优化

概述