早期（编译期）优化

一、概述

JVM的编译器分类：

• 前端编译器：把.java转变为.class的过程。如Sun的Javac、Eclipse JDT中的增量式编译器（ECJ）。

• JIT编译器：把字节码转变为机器码的过程，如HotSpot VM的C1、C2编译器。

• AOT编译器：静态提前编译器，直接将*.java文件编译本地机器代码的过程。

  虚拟机设计团队把对性能的优化集中到了后端的即时编译器中，这样可以让那些不是由 Javac 产生的 Class 文件（如 JRuby、Groovy 等语言的 Class 文件）也同样能享受到编译器优化所带来的好处。但是 Javac 做了许多针对 Java 语言编码过程的优化措施来改善程序员的编码风格和提高编码效率。相当多新生的 Java 语法特性，都是靠编译器的 “语法糖” 来实现，而不是依赖虚拟机的底层改进来支持，可以说，Java 中即时编译器在运行期的优化过程对于程序运行来说更重要，而前端编译器在编译期的优化过程对于程序编码来说关系更加密切。

二、Javac编译器

2.1 Javac的源码

javac的源码地址：JDK_SRC_HOME/langtools/src/share/slasses/com/sun/tools/javac

编译过程大致可以分为3个过程：
　　　　1、解析与填充符号表过程
　　　　2、插入式注解处理器的注解处理过程
　　　　3、分析与字节码生成过程

这3个步骤之间的关系与交互顺序如下图：

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

2.2 解析与填充符号表

  解析步骤由parseFiles（）方法完成，解析步骤包括了 词法分析 和 语法分析 两个过程。

2.2.1 词法、语法分析

• 词法分析
    将源代码的字符流转变为 标记（Token）集合，单个字符是程序编写过程的最小元素，而标记则是编译过程的最小元素，关键字、变量名、字面量、运算符都可以成为标记，在Javac的源码中，词法分析过程由com.sun.tools.javac.parser.Scanner类来实现。

如 “int a=b+2” 这句代码包含了 6 个标记，分别是 int、a、=、b、+、2，虽然关键字 int 由 3个字符构成，但是它只是一个 Token，不可再拆分。

• 语法分析
    根据 Token 序列构造抽象语法树的过程， 抽象语法树 是一种用来描述程序代码语法结构的树形表述方式。语法树的每一个节点都代表着程序代码中的一个语法结构，例如包、类型、修饰符、接口、返回值甚至代码注释都可以是一个语法结构。语法分析过程由com.sun.tools.javac.parser.Parser类实现，这个阶段产出的抽象语法树由com.sun.tools.javac.tree.JCTree类表示，经过这个步骤之后，编译器就基本不会再对源码文件进行操作了，后续的操作都是建立在抽象语法树之上的。

• 抽象语法树结构视图
  

2.2.2 填充符号表

  完成语法分析和词法分析之后，下一步就是填充符号表的过程，即enterTrees()方法。 符号表 是由一组符号地址和符号信息构成的表格，类似于哈希表中K-V值对的形式（实际上符号表不一定是哈希表实现，可以是有序符号表、树状符号表、栈结构符号表等）。符号表中所登记的信息在编译的不同阶段都要用到：

• 语义分析中
  符号表所登记的内容将用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码。
• 目标代码生成阶段
  当对符号名进行地址分配时，符号表是地址分配的依据。

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

2.3 注解处理器

  JDK1.5之后，Java提供了对注解的支持，这些注解与普通的Java代码一样，在运行期间发挥作用。 在 JDK 1.6 中实现了 JSR-269 规范（JSR-269：Pluggable Annotations Processing API（插入式注解处理 API）），提供了一组 插入式注解处理器 的标准 API 在编译期间对注解进行处理，我们可以把它看做是一组编译器的插件，在这些插件里面，可以读取、修改、添加抽象语法树中的任意元素。如果这些插件在处理注解期间对语法树进行了修改，编译器将回到解析及填充符号表的过程重新处理，直到所有插入式注解处理器都没有再对语法树进行修改为止，每一次循环称为一个 Round，也就是编译过程图中的回环过程。
　　
  有了编译器注解处理的标准API后，我们的代码才有可能干涉编译器的行为，由于语法树中的任意元素，甚至包括代码注释都可以在插件之中访问到，所以使用插入式注解处理器在功能上有很大的发挥空间。

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

2.4 语义分析与字节码生成

  语法分析之后，编译器获得了程序代码的抽象语法树表示，语法树能表示一个结构正确的源程序的抽象，但无法保证源程序是符合逻辑的。而 语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查，如进行类型审查。

举个例子，假设有如下的 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 种写法都是可以正确编译）。

  在Javac编译过程中，语法分析过程分为 标注检查 以及 数据及控制流分析 两个步骤，分别对应着attribute()和flow()方法完成。

2.4.1 标注检查

标注检查步骤检查的内容包括诸如：

• 变量使用前是否已被声明
• 变量与赋值之间的数据类型是否能够匹配等。

此外，这个过程中还有一个重要的步骤称为常量折叠。

如果我们在代码中写了如下定义：
java int a = 1 + 2;
那么在语法树上仍然能看到字面量 “1”、“2” 以及操作符 “+”，但是在经过常量折叠之后，它们将会被折叠为字面量 “3”，如图所示，这个插入式表达式（Infix Expression）的值已经在语法树上标注出来了（ConstantExpressionValue：3）。由于编译期间进行了常量折叠，所以在代码里面定义 “a=1+2” 比起直接定义 “a=3”，并不会增加程序运行期哪怕仅仅一个 CPU 指令的运算量。

  标注检查步骤在Javac源码中的实现类是com.xun.tools.javac.comp.Attr和com.sun.tools.javac.comp.Check类。

2.4.2 数据及控制流分析

  数据及控制流分析是对程序上下文逻辑更进一步的验证，它可以查出诸如：

• 程序局部变量在使用前是否有赋值
• 方法的每条路径是否都有返回值
• 是否所有的受查异常都被正确处理了

等问题。编译期的数据及控制流分析与类加载时的数据及数据流分析的目的基本上是一致的，但校验范围有所区别，有一些校验项只有在编译期或者运行期才能进行。

下面举一个关于 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 的源码中，数据及控制流分析的入口是 flow() 方法，具体操作由 com.sun.tools.javac.comp.Flow 类来完成。

2.4.3 解语法糖

  语法糖是指在计算机语言中添加某种语法，这种语法对语言的功能并没有影响，但是更方便程序员使用。 通常来说，使用语法糖能够增加程序的可读性，从而减少程序代码出错的机会。
  Java是一种“低糖语言”，常用的语法糖主要是之前提到的泛型、变长参数、自动装箱/拆箱等。虚拟机运行时不支持这些语法，它们在编译期还原回简单的基础语法结构，这个过程称为解语法糖。解语法糖的过程是由desuger()方法触发的。

2.4.4 字节码生成

  字节码生成是Javac编译过程的最后一个阶段，由 com.sun.tools.javac.jvm,Gen 类来完成，字节码生成阶段不仅仅是把前面各个步骤所生成的信息（语法树、符号表）转化为字节码写入磁盘中，编译器还进行了少量代码添加和转换工作。
  完成对语法树的遍历与调整之后，就会把填充了所有所需信息的符号表交给com.sun.tools.javac.jvm.ClassWriter类，由这个类的wrtieClass()方法输出字节码，生成最终的Class文件。

三、Java 语法糖的味道

3.1 泛型和类型擦除

  泛型是JDK1.5新增的特性，它的本质是参数化类型的应用，也就是说所操作的数据类型被指定为一个参数，这种参数类型可以用于类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。

  泛型思想早在 C++ 语言的模板（Template）中就开始生根发芽，在 Java 语言处于还没有出现泛型的版本时，只能通过 Object 是所有类型的父类和类型强制转换两个特点的配合来实现类型泛化。例如，在哈希表的存取中，JDK 1.5 之前使用 HashMap 的 get()方法，返回值就是一个 Object 对象，由于 Java 语言里面所有的类型都继承于 java.lang.Object，所以 Object 转型成任何对象都是有可能的。但是也因为有无限的可能性，就只有程序员和运行期的虚拟机才知道这个 Object 到底是什么类型的对象。在编译期间，编译器无法检查这个 Object 的强制转型是否成功，如果仅仅依赖程序员去保障这项操作的正确性，许多 ClassCastException 的风险就会转嫁到程序运行期之中。

3.1.1 泛型技术在 C# 和 Java之中的使用方式区别

  C# 里面泛型无论是在程序源码中、编译后的 IL 中（Intermediate Language，中间语言，这时候泛型是一个占位符），或是运行期的 CLR 中，都是切实存在的，List< int > 与 List< String > 就是两个不同的类型，它们在系统运行期生成，有自己的虚方法表和类型数据，这种实现称为类型膨胀，基于这种方法实现的泛型称为真实泛型。

  与C#的泛型不一样的是，Java的泛型只存在于程序源码中，在编译后的字节码文件中，就已经替换成原来的原生类型（Raw Type，也称为裸类型）了，并且在相应的地方插入了强制转型代码。因此，对于运行期的Java语言来说，ArrayList< int >与ArrayList< String >就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。

3.1.2 Java泛型举例

泛型擦除前的例子：

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 文件，然后再用字节码反编译工具进行反编译后，将会发现泛型都不见了（用jd-gui 查看发现声明的时候泛型还在，其他地方就变成了强制类型转换），程序又变回了 Java 泛型出现之前的写法，泛型类型都变回了原生类型

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

3.1.3 当泛型遇见重载

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< String > 编译之后都被擦除了，变成了一样的原生类型 List< E >，擦除动作导致这两种方法的特征签名变得一模一样。初步看来，无法重载的原因已经找到了，但真的就是如此吗？只能说，泛型擦除成相同的原生类型只是无法重载的其中一部分原因，请再接着看下面代码清单中的内容。

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)  

  该段代码清单与前面的差别是两个 method 方法添加了不同的返回值，由于这两个返回值的加入，方法重载居然成功了，即这段代码可以被编译和执行（注：测试的时候请使用 Sun JDK 1.6(1.7 和 1.8 也无法进行编译) 进行编译，其他编译器，如 Eclipse JDT 的 ECJ 编译器，仍然可能会拒绝这段代码）了。这是对 Java 语言中返回值不参与重载选择的基本认知的挑战吗？
  代码清单中的重载当然不是根据返回值来确定的，之所以这次能编译和执行成功，是因为两个 method() 方法加入了不同的返回值后才能共存在一个 Class 文件之中。前面介绍 Class 文件方法表（method_info）的数据结构时曾经提到过，方法重载要求方法具备不同的特征签名，返回值并不包含在方法的特征签名之中，所以返回值不参与重载选择，但是 在 Class 文件格式之中，只要描述符不是完全一致的两个方法就可以共存。也就是说，两个方法如果有相同的名称和特征签名，但返回值不同，那它们也是可以合法地共存于一个 Class 文件中的。

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

  从上面的例子可以看到擦除法对实际编码带来的影响，由于 List 和 List 擦除后是同一个类型，我们只能添加两个并不需要实际使用到的返回值才能完成重载，这是一种毫无优雅和美感可言的解决方案，并且存在一定语意上的混乱。

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

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

  从纯技术的角度来讲，自动装箱、自动拆箱与遍历循环（Foreach 循环）这些语法糖，无论是实现上还是思想上都不能和上文介绍的泛型相比，两者的难度和深度都有很大差距。专门拿出一节来讲解它们只有一个理由：毫无疑问，它们是 Java 语言里使用得最多的语法糖。

• 代码清单：自动装箱、拆箱与遍历循环

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

• 代码清单：自动装箱、拆箱与遍历循环编译之后

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

  泛型就不必说了，自动装箱、拆箱在编译之后被转换成了对应的包装和还原方法，如本例中的 Integer.valueOf() 与 Integer.intValue() 方法，而遍历循环则把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现Iterable接口的原因。最后再看看变长参数，它在调用的时候变成了一个数组类型的参数，在变长参数出现之前，程序员就是使用数组来完成类似功能的。

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

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

输出结果：

true
false
true
true
true
false

反编译后代码：

public static void main(String[] args) {
		Integer a = Integer.valueOf(1);
		Integer b = Integer.valueOf(2);
		Integer c = Integer.valueOf(3);
		Integer d = Integer.valueOf(3);
		Integer e = Integer.valueOf(321);
		Integer f = Integer.valueOf(321);
		Long g = Long.valueOf(3L);
		System.out.println(c == d);
		System.out.println(e == f);
		System.out.println(c.intValue() == a.intValue() + b.intValue());
		System.out.println(c.equals(Integer.valueOf(a.intValue() + b.intValue())));
		System.out.println(g.longValue() == (long) (a.intValue() + b.intValue()));
		System.out.println(g.equals(Integer.valueOf(a.intValue() + b.intValue())));
	}

结论：包装类的“==” 运算在不遇到算术运算的情况下不会自动拆箱，以及它们 equals() 方法不处理数据转型的关系

3.3 条件编译

  许多程序设计语言都提供了条件编译的途径，如 C、C++ 中使用预处理器指示符（#ifdef）来完成条件编译。C、C++ 的预处理其最初的任务是解决编译时的代码依赖关系（如非常常用的 #include 预处理命令），而在 Java 语言之中并没有使用预处理器，因为 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");
	}
}

反编译结果：

public static void main(String[] args) {
	System.out.println("block 1");
}

  只能使用条件为常量的 if 语句才能达到上述效果，如果使用常量与其他带有条件判断能力的语句搭配，则可能在控制流分析中提示错误，被拒绝编译

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

  Java语言中条件编译的实现，也是Java语言的一颗语法糖，根据布尔常量值的真假，编译器将会把分支中不成立的代码块消除掉，这是在解语法糖阶段实现的。

  Java语言中还有不少的其他语言糖，如内部类、枚举类、断言语句、对枚举和字符串的switch支持、try语句中定义和关闭资源等等。