有三类编译器

1.前端编译器

把*.java文件转变成*.class文件的过程，Javac等，只编译，对于运行没有丁点优化

好处是：改善编码风格和提高编码效率，即用语法糖，语法特性需要在此编译器中 实现

2.JIT编译器，

把字节码转变成机器码的过程，存在与程序运行期

3.AOT编译器，

直接把*.java文件编译成本地机器代码的过程

Javac编译过程

1.解析与填充符号表过程

parseFiles()方法

解析过程 ：

1）词法分析：

将源代码的字符流转变为标记（Token）集合，由com.sun.tools.javac.parser.Scanner 类来实现

2）语法分析：

根据Token序列构造抽象语法树的过程，由com.sun. tools.javac.parser.Parser类实现，产出的抽象语法树由com.sun.tools.javac.tree.JCTree类表示，后续的操作都建立在抽象语法树之上

3）填充符号表：

符号表（Symbol Table）是由一组符号地址和符号信息构成的表格，符号表中所登记的信息在编译的不同阶段都要用到

语义分析中：符号表所登记的内容将用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码

在目标代码生成阶段：当对符号名进行地址分配时，符号表是地址分配的依据

由com.sun.tools.javac.comp.Enter类实现，出口是一个待处理列表（To Do List），包含了每一个编译单元的抽象语法树的顶级节点

enterTrees()方法

2.插入式注解处理器的注解处理过程

可以把它看做是一组编译器的插件，如lambok，可以读取、修改、添加抽象语法树中的任意元素

处理注解期间对语法树进行了修改，编译器将回到解析及填充符号表的过程重新处理，直到所有插入式注解处理器都没有再对语法树进行修改为止，每一次循环称为一个Round

插入式注解处理器的初始化过程是在initProcessAnnotations()方法中完成的，

它的执行过程则是在processAnnotations()方法中完成的

执行过程中会判断是否还有新的注解处理器需要执行，如果有的话，通过com.sun.tools.javac.processing.JavacProcessingEnvironment类的doProcessing()方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理

3.语义分析与字节码生成过程

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

分为两个步骤

1）标注检查

由attribute()和flow()方法完成

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

代码常量折叠如：int a = 1+2;折叠为字面量“3”

实现类是com.sun.tools.javac.comp.Attr类和com.sun.tools.javac.comp.Check类

2）数据及控制流分析

对程序上下文逻辑更进一步的验证检查

主要检查：

程序局部变量在使用前是否有赋值

方法的每条路径是否都有返回值

是否所有的受查异常都被正确处理了等

与类加载时的数据及控制流分析的目的基本上是一致的，但校验范围有所区别，有一些校验项只有在编译期或运行期才能进行，如final修饰的局部变量，局部变量在常量池中没有CONSTANT_Fieldref_info的符号引用，自然就没有访问标志（Access_Flags）的信息，故将不将局部变量修饰为final，对运行期是没有影响的，变量的不变性仅仅由编译器在编译期间保障

flow()方法由com.sun.tools.javac.comp. Flow类来完成

4.语法糖

对语言的功能并没有影响，提高编程效率，增加程序的可读性，减少程序代码出错的机会

如：泛型，变长参数，自动装箱/拆箱，遍历循环等简化代码的特性，编译阶段解语法糖

由desugar()方法触发，在com.sun.tools.javac.comp. TransTypes类和com.sun.tools.javac.comp.Lower类中完成

语法糖相对于框架，便于编程，简化代码，但隐藏了原本代码的实现

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

内部类、枚举类、断言语句、对枚举和字符串（在JDK 1.7中支持）的switch支持、try语句中定义和关闭资源（在JDK 1.7中支持）等

跟踪Javac源码、反编译Class文件等方式了解语法糖的本质实现

5.字节码生成

由com.sun.tools.javac. jvm.Gen类来完成，

把前面各个步骤所生成的信息（语法树、符号表）转化成字节码写到磁盘中，还进行了少量的代码添加和转换工作，如：实例构造器<init>()方法和类构造器<clinit>()方法,虚拟机会将某些变量的赋值及代码块收敛到<init>()和<clinit>()方法之中，并且保证一定的执行顺序，由Gen.normalizeDefs()方法来实现

其他的一些代码替换工作用于优化程序的实现逻辑，如把字符串的加操作替换为StringBuffer或StringBuilder（取决于目标代码的版本是否大于或等于JDK 1.5）的append()操作等。

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

泛型与类型擦除

泛型：类型参数化，将类型转化异常控制在编译期

泛型类、泛型接口和泛型方法

之前只能通过Object是所有类型的父类和类型强制转换两个特点的配合来实现

Java实现的泛型称为伪泛型：

在编译后的字节码文件中，替换为原来的原生类型（类型擦除）在相应的地方插入了强制转型代码

引入了Signature、LocalVariableTypeTable属性用于解决伴随泛型而来的参数类型的识别问题

仅是对方法的Code属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息

JIT编译器

Java程序最初是通过解释器（Interpreter）进行解释执行的

当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，简称JIT编译器

1.为何HotSpot虚拟机要使用解释器与编译器并存的架构？

当程序需要迅速启动和执行的时候,解释器可以首先发挥作用，省去编译的时间，立即执行

在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率

也可以通过逆优化（Deoptimization）退回到解释状态继续执行

HotSpot虚拟机中内置了两个即时编译器

C1 ClientCompiler

C2 Server Compiler

使用参数“-Xint”强制虚拟机运行于“解释模式”（Interpreted Mode）

使用参数“-Xcomp”强制虚拟机运行于“编译模式”（CompiledMode）

默认采用解释器与其中一个编译器直接配合的方式工作:混合模式”（Mixed Mode）

使用哪个编译器，取决于虚拟机运行的模式

1）.HotSpot虚拟机根据自身版本与宿主机器的硬件性能自动选择运行模式

2）.使用“-client” 或 “-server” 参数强制指定虚拟机运行在Client模式 或 Server模式

2.为何HotSpot虚拟机要实现两个不同的即时编译器？

3.程序何时使用解释器执行？何时使用编译器执行？

4.哪些程序代码会被编译为本地代码？如何编译为本地代码？

5.如何从外部观察即时编译器的编译过程和编译结果？

分层编译策略（Tiered Compilation) ———JDK 1.7的Server模式默认编译策略

编译出优化程度更高的代码，所花费的时间可能更长,解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响

分层为了在程序启动响应速度与运行效率之间达到最佳平衡

第0层:程序解释执行,不开启性能监控,触发第1层编译

第1层:即C1编译，编译为本地代码，进行简单、可靠的优化，有必要将加入性能监控

第2层：即C2编译，编译为本地代码，启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化

用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务

在运行过程中会被即时编译器编译的“热点代码”有两类

1）：被多次调用的方法 由方法调用触发 标准的JIT编译

2）：被多次执行的循环体 由循环体所触发，依然编译整个方法

这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为OSR编译，即方法栈帧还在栈上，方法就被替换了）

热点探测判定方式有两种：

1：基于采样的热点探测

虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是“热点方法”

优点

简单、高效，可以很容易地获取方法调用关系

缺点：因为受到线程阻塞或别的外界因素的影响而扰乱热点探测，很难精确地确认

2：基于计数器的热点探测

为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是“热点方法”

优点

统计结果相对来说更加精确和严谨

缺点：每个方法建立并维护计数器，实现起来麻烦

HotSpot虚拟机中使用的是第二种

为每个方法准备了两类计数器

1：方法调用计数器：

用于统计方法被调用的次数

默认阈值Client模式下是1500次，在Server模式下是10 000次

-XX：CompileThreshold来设定

执行如图：

如果不做任何设置，不会同步等待编译请求完成，

如果不做任何设置，方法调用计数器统计的是一个相对的执行频率，即一段时间之内方法被调用的次数

当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）

进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，

参数-XX：-UseCounterDecay来关闭，让方法计数器统计方法调用的绝对次数

参数-XX：CounterHalfLifeTime参数设置半衰周期的时间，单位是秒

2：回边计数器：

统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边“

此统计的目的就是为了触发OSR编译

参数-XX：BackEdgeThreshold供用户设置，虚拟机实际上并未使用

参数-XX：OnStackReplacePercentage来间接调整回边计数器的阈值

在Client模式下，回边计数器阈值计算公式为

方法调用计数器阈值（CompileThreshold）×OSR比率（OnStackReplacePercentage）/100

OnStackReplacePercentage默认933，都取默认，Client模式虚拟机的回边计数器的阈值为13995

在Server模式下，回边计数器阈值的计算公式为

方法调用计数器阈值（CompileThreshold）×（OSR比率（OnStackReplacePercentage）-解释器监控比率（InterpreterProfilePercentage）/100

OnStackReplacePercentage默认140，InterpreterProfilePercentage默认33，都取默认，Server模式虚拟机的回边计数器的阈值为10700

执行如图：

注：回边计数器没有计数热度衰减的过程，统计的就是该方法循环执行的绝对次数

当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程

可以通过参数-XX：-BackgroundCompilation来禁止后台编译，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码

编译的过程：

对于Client Compiler，它是一个简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段

第一个阶段

一个平台独立的前端将字节码构造成一种高级中间代码表示，方法内联、常量传播在字节码被构造成HIR之前完成

第二个阶段

一个平台相关的后端从HIR中产生低级中间代码表示，空值检查消除、范围检查消除优化

第三个阶段

在平台相关的后端使用线性扫描算法（Linear ScanRegister Allocation）在LIR上分配寄存器，并在LIR上做窥孔（Peephole）优化，然后产生机器代码

流程：

Server Compiler：专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器

经典优化有

无用代码消除（DeadCode Elimination）、

循环展开（Loop Unrolling）、

循环表达式外提（Loop Expression Hoisting）、

消除公共子表达式（Common Subexpression Elimination）、

常量传播（Constant Propagation）、

基本块重排序（Basic BlockReordering）

范围检查消除（Range Check Elimination）、

空值检查消除等

可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如：

守护内联（Guarded Inlining）、分支频率预测（Branch FrequencyPrediction）等

优点：

对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销

缺点：编译比较缓慢

查看及分析即时编译

参数-XX：+PrintCompilation

在即时编译时将被编译成本地代码的方法名称打印出来，带有“%”的输出说明是由回边计数器触发的OSR编译

参数-XX：+PrintInlining

要求虚拟机输出方法内联信息

编译优化技术

解释执行消耗额外时间，集中优化了即时编译

优化基于代码的某种中间表示或机器码之上

方法内联（Method Inlining）

去除方法调用的成本（如建立栈帧等），为其他优化建立良好的基础

冗余访问消除（Redundant LoadsElimination）

复写传播（Copy Propagation）

无用代码消除（Dead Code Elimination）

如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就成为了公共子表达式

数组边界检查消除

类型继承关系分析

逃逸分析 ：为其他优化手段提供依据的分析技术

当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸

如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化

栈上分配（Stack Allocation）

确定一个对象不会逃逸出方法之外,让这个对象在栈上分配内存,大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多

同步消除（Synchronization Elimination）

能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉

标量替换（Scalar Replacement）

如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件

不能保证逃逸分析的性能收益必定高于它的消耗

参数-XX：+DoEscapeAnalysis来手动开启逃逸分析

参数-XX：+PrintEscapeAnalysis来查看分析结果

参数-XX：+EliminateAllocations来开启标量替huan

参数-XX：+PrintEliminateAllocations查看标量的替换情况

+XX：+EliminateLocks来开启同步消除