JVM - 从源码到机器码

转载JVM基础系列第4讲：从源代码到机器码，发生了什么？

1. JVM的整体结构

java虚拟机是用来解释jvm字节码文件的(为什么我不说java字节码，因为多语言*编程的支持，只要被解释成符合标准的字节码文件的语言都能在jvm虚拟机上运行)

2. 前端编译器: 从源代码到字节码

对于 Java 虚拟机来说，输入的是字节码文件，而不是 Java 文件。那么对于 Java 语言而言，其实怎么将 Java 代码转化成字节码文件的呢？我们知道在 JDK 的安装目录里有一个 javac 工具，就是它将 Java 代码翻译成字节码，这个工具我们叫做编译器。相对于后面要讲的其他编译器，其因为处于编译的前期，因此又被成为前端编译器

通过 javac 编译器，我们可以很方便地将 java 源文件翻译成字节码文件。就拿我们最熟悉的 Hello World 作为例子：

public class Demo{
   public static void main(String args[]){
		System.out.println("Hello World!");
   }
}

我们使用 javac 命令编译上面这个类，便会生成一个 Demo.class 文件：

> javac Demo.java
> ls 
Demo.java Demo.class

我们运行 javac 命令的过程，其实就是 javac 编译器解析 Java 源代码，并生成字节码文件的过程。说白了，其实就是使用 javac 编译器把 Java 语言规范转化为字节码语言规范。javac 编译器的处理过程可以分为下面四个阶段：

① 词法/语法分析:
在这个阶段，JVM 会对源代码的字符进行一次扫描，最终生成一个抽象的语法树。简单地说，在这个阶段 JVM 会搞懂我们的代码到底想要干嘛。就像我们分析一个句子一样，我们会对句子划分主谓宾，弄清楚这个句子要表达的意思一样。

② 填充符号表:
我们知道类之间是会互相引用的，但在编译阶段，我们无法确定其具体的地址，所以我们会使用一个符号来替代。在这个阶段做的就是类似的事情，即对抽象的类或接口进行符号填充。等到类加载阶段，JVM 会将符号替换成具体的内存地址。

③ 注解处理:
我们知道 Java 是支持注解的，因此在这个阶段会对注解进行分析，根据注解的作用将其还原成具体的指令集。

**④ 分析与字节码生成: **
到了这个阶段，JVM 便会根据上面几个阶段分析出来的结果，进行字节码的生成，最终输出为 class 文件

我们一般称 javac 编译器为前端编译器，因为其发生在整个编译的前期。常见的前端编译器有 Sun 的 javac，Eclipse JDT 的增量式编译器（ECJ）

3. JIT 编译器: 从字节码到机器码

当源代码转化为字节码之后，其实要运行程序，有两种选择。一种是使用 Java 解释器解释执行字节码，另一种则是使用 JIT 编译器将字节码转化为本地机器代码

这两种方式的区别在于，前者启动速度快但运行速度慢，而后者启动速度慢但运行速度快。至于为什么会这样，其原因很简单。因为解释器不需要像 JIT 编译器一样，将所有字节码都转化为机器码，自然就少去了优化的时间。而当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。所以在实际情况中，为了运行速度以及效率，我们通常采用两者相结合的方式进行 Java 代码的编译执行

4. AOT 编译器: 源代码到机器码

AOT 编译器的基本思想是：在程序执行前生成 Java 方法的本地代码，以便在程序运行时直接使用本地代码。

但是 Java 语言本身的动态特性带来了额外的复杂性，影响了 Java 程序静态编译代码的质量。例如 Java 语言中的动态类加载，因为 AOT 是在程序运行前编译的，所以无法获知这一信息，所以会导致一些问题的产生。类似的问题还有很多，这里就不一一举例了。

总的来说，AOT 编译器从编译质量上来看，肯定比不上 JIT 编译器。其存在的目的在于避免 JIT 编译器的运行时性能消耗或内存消耗，或者避免解释程序的早期性能开销。

在运行速度上来说，AOT 编译器编译出来的代码比 JIT 编译出来的慢，但是比解释执行的快。而编译时间上，AOT 也是一个始终的速度。所以说，AOT 编译器的存在是 JVM 牺牲质量换取性能的一种策略。就如 JVM 其运行模式中选择 Mixed 混合模式一样，使用 C1 编译模式只进行简单的优化，而 C2 编译模式则进行较为激进的优化。充分利用两种模式的优点，从而达到最优的运行效率