深入理解JVM学习笔记——第十章 早期（编译期）优化

注：本系列文章均摘录自《深入理解Java虚拟机：JVM高级特性与最佳实践》，作者周志明，我看的是第一版，现在第二版已经出了，

第十章 早期（编译期）优化

    1.Java语言的”编译期“是一段”不确定“的操作过程，因为它可能是指一个前端编译器吧*.java文件转变成*.class文件的过程；也可能是指虚拟机后端运行期编译器（JIT编译器，Just In Time Compiler）把字节码转变成机器码的过程；还可能是指使用静态提前编译器（AOT编译器，Ahead Of Time Compiler）直接把*.java文件编译成本地机器代码的过程。

    2.虚拟机规范严格定义了Class文件的格式，但是对如何把Java源码文件转变为Class文件的编译过程未作任何定义，所以这部分内容是与具体JDK实现相关的。从Sun Javac的代码来看，编译过程大致可以分为三个过程：

    （1）解析与填充符号表过程。

    （2）插入式注解处理器的注解处理过程。

    （3）分析与字节码生成过程。

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

    4.语法分析是根据Token序列来构造抽象语法树的过程，抽象语法树（AST，Abstract Syntax Tree）是一种用来描述程序代码语法结构的树形表示方式，语法树的每一个节点都代表着程序代码中的一个语法结构（Construct），例如包、类型、修饰符、运算符、接口、返回值甚至连代码注释都可以是一个语法结构。

    在Javac的源码中，语法分析过程由com.sun.tools.javac.parser.Parser类来实现，这个阶段产出的抽象语法树由com.sun.javac.tree.JCTree来表示，经过这个步骤之后，编译器就基本不会再对源码文件进行操作了，后续的操作都建立在抽象语法树之上。

    5.符号表（Symbol Table）是由一组符号地址和符号信息构成的表格。符号表中所登记的信息在编译的不同阶段都要用到。在语义分析中，符号表所登记的内容将用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码。在目标代码生成阶段，当对符号名进行地址分配时，符号表是地质分配的依据。

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

    6.JDK1.5之后，Java语言提供了对注解的支持，这些注解与普通的Java代码一样，是在运行期间发挥作用的。在JDK1.6中实现了JSR-269规范，提供了一组插入式注解处理器的标准API在编译期间对注解进行处理，我们可以把它看做是一组编译器的插件，在这些插件里面，可以读取、修改、添加抽象语法树中的任意元素。如果这些插件在处理注解期间对语法树进行了修改，那么编译器将回到解析及填充符号表的过程重新处理，直到所有的插入式注解处理器都没有再对语法树进行修改位置，每一次循环称为一个Round。

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

    7.语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查。

    8.Javac的编译过程中，语义分析过程分为标注检查和数据及控制流分析两个步骤，分别由attribute()和flow()完成。

    标注检查步骤检查的内容包括诸如变量使用前是否已被声明、变量与赋值之间的数据类型是否能够匹配等等。标注检查步骤在Javac源码中的实现类是 com.sun.tools.javac.comp.Attr类和com.sun.tools.javac.comp.Check类。

    9.数据及控制流分析是对程序上下文逻辑更进一步的验证，它可以检查出诸如程序局部变量在使用前是否有赋值、方法的每条路径是否都有返回值、是否所有的受查异常都被正确处理了等问题。

    将局部变量声明为final，对运行期是没有影响的，变量的不变性仅仅由编译器在编译期间保障。在Javac的源码中，数据及控制流分析的入口是flow()方法，具体操作由com.sun.tools.javac.comp.Flow类来完成。

    10.语法糖（Syntactic Sugar），也称糖衣语法，是由英国计算机科学家彼得-约翰-兰达（Peter J.landin）发明的一个术语，指在计算机语言中添加的某种语法，这种语法对语言的功能并没有影响，但是更方便程序员使用。通常来说使用语法糖能够增加程序的可读性，从而减少程序代码出错的机会。

    Java中最常用的语法糖主要是泛型、变长参数、自动装箱拆箱等等，虚拟机运行时不支持这些语法，它们在编译阶段被还原回简单的基础语法结构，这个过程称为解语法糖。

    在Javac的源码中，解语法糖的过程由desugar（）方法触发，在com.sun.tools.javac.comp.TransTypes类和com.sun.tools.javac.comp.Lower类中完成。

    11.字节码生成是Javac编译过程的最后一个阶段，在Javac源码里面有com.sun.tools.javac.jvm.Gen类来完成。字节码生成阶段不仅仅是把前面各个步骤所生成的信息（语法树、符号表）转化成字节码写到磁盘中，编译器还进行了少量的代码添加和转换工作。

    除了生成构造器以外，还有其他的一些代码替换工作用于优化程序的实现逻辑，如把字符串的加操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK1.5）的append（）操作。

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

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

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

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

    15.擦除法所谓的擦除，仅仅是对方法的Code属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息，这也是能通过反射手段取得参数化类型的根本依据。

    16.Java语言中没有使用预处理器，因为Java语言天然的编译方式（编译器并非一个一个地编译Java文件，而是将所有的编译单元的语法树顶级节点输入到待处理列表后再进行编译，因此各个文件之间能够互相提供符号信息）无须使用预处理器。

    Java语言当然也可以进行条件编译，方法就是使用条件为常量的if语句。

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

    18.可以通过javac命令的“-processor”参数来执行编译时需要附带的注解处理器，如果有多个注解处理器的话，用逗号分隔。还可以使用-XprintRounds和-XprintProcessorInfo参数来查看注解处理器的运作的详细信息。

评论

2 楼 bsr1983 2013-09-03  

sessionsong 写道

你好！ 我最近也在看这本书， 其中有个疑问  想请教您一下 !
就是在看到 “把字符串的加操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK1.5）的append（）操作。”这句话是  有些理解不了
字面意思是说在编译期 把 + 替换成了append（）方法，如果真是这样 那么当我在对字符串进行频繁的加的操作是，那是不是使用+ 和append一样呢 ？  但最后结果肯定不是这样的 使用+耗时明显多于append方法 。这是为什么呢 ？

下面是我做的100000次字符串相加的操作的结果
+: 19975 ms
------------------------------------------------
StringBuffer.append(): 9 ms
------------------------------------------------
StringBuilder.append(): 5 ms

我写了一篇分析这个问题的文章，你参考一下，看看能不能解决你的疑问，链接http://bsr1983.iteye.com/blog/1935856

1 楼 sessionsong 2013-09-02  

你好！ 我最近也在看这本书， 其中有个疑问  想请教您一下 !
就是在看到 “把字符串的加操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK1.5）的append（）操作。”这句话是  有些理解不了
字面意思是说在编译期 把 + 替换成了append（）方法，如果真是这样 那么当我在对字符串进行频繁的加的操作是，那是不是使用+ 和append一样呢 ？  但最后结果肯定不是这样的 使用+耗时明显多于append方法 。这是为什么呢 ？

下面是我做的100000次字符串相加的操作的结果
+: 19975 ms
------------------------------------------------
StringBuffer.append(): 9 ms
------------------------------------------------
StringBuilder.append(): 5 ms