在上篇文章我們聊到，無論什么語言寫的代碼，其到最后都是通過機器碼運行的，無一例外。那么對于 Java 語言來說，其從源代碼到機器碼，這中間到底發生了什么呢？這就是今天我們要聊的。

如下圖所示，編譯器可以分為：前端編譯器、JIT 編譯器和AOT編譯器。下面我們逐個講解。

前端編譯器：源代碼到字節碼

之前我們說到：對于 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

我們使用純文本編輯器打開 Demo.class 文件，我們會發現是一連串的 16 進制二進制流。

我們運行 javac 命令的過程，其實就是 javac 編譯器解析 Java 源代碼，并生成字節碼文件的過程。說白了，其實就是使用 javac 編譯器把 Java 語言規范轉化為字節碼語言規范。javac 編譯器的處理過程可以分為下面四個階段：

第一個階段：詞法、語法分析。在這個階段，JVM 會對源代碼的字符進行一次掃描，最終生成一個抽象的語法樹。簡單地說，在這個階段 JVM 會搞懂我們的代碼到底想要干嘛。就像我們分析一個句子一樣，我們會對句子劃分主謂賓，弄清楚這個句子要表達的意思一樣。

第二個階段：填充符號表。我們知道類之間是會互相引用的，但在編譯階段，我們無法確定其具體的地址，所以我們會使用一個符號來替代。在這個階段做的就是類似的事情，即對抽象的類或接口進行符號填充。等到類加載階段，JVM 會將符號替換成具體的內存地址。

第三個階段：注解處理。我們知道 Java 是支持注解的，因此在這個階段會對注解進行分析，根據注解的作用將其還原成具體的指令集。

第四個階段：分析與字節碼生成。到了這個階段，JVM 便會根據上面幾個階段分析出來的結果，進行字節碼的生成，最終輸出為 class 文件。

我們一般稱 javac 編譯器為前端編譯器，因為其發生在整個編譯的前期。常見的前端編譯器有 Sun 的 javac，Eclipse JDT 的增量式編譯器(ECJ)。

JIT 編譯器：從字節碼到機器碼

當源代碼轉化為字節碼之后，其實要運行程序，有兩種選擇。一種是使用 Java 解釋器解釋執行字節碼，另一種則是使用 JIT 編譯器將字節碼轉化為本地機器代碼。

這兩種方式的區別在于，前者啟動速度快但運行速度慢，而后者啟動速度慢但運行速度快。至于為什么會這樣，其原因很簡單。因為解釋器不需要像 JIT 編譯器一樣，將所有字節碼都轉化為機器碼，自然就少去了優化的時間。而當 JIT 編譯器完成第一次編譯后，其會將字節碼對應的機器碼保存下來，下次可以直接使用。而我們知道，機器碼的運行效率肯定是高于 Java 解釋器的。所以在實際情況中，為了運行速度以及效率，我們通常采用兩者相結合的方式進行 Java 代碼的編譯執行。

在 HotSpot 虛擬機內置了兩個即時編譯器，分別稱為 Client Compiler 和Server Compiler。這兩種不同的編譯器衍生出兩種不同的編譯模式，我們分別稱之為：C1 編譯模式，C2 編譯模式。

注意：現在許多人習慣上將 Client Compiler 稱為 C1 編譯器，將 Server Compiler 稱為 C2 編譯器，但在 Oracle 官方文檔中將其描述為 compiler mode(編譯模式)。所以說 C1 編譯器、C2 編譯器只是我們自己的習慣性稱呼，并不是官方的說法。這點需要特別注意。

那么 C1 編譯模式和 C2 編譯模式有什么區別呢？

C1 編譯模式會將字節碼編譯為本地代碼，進行簡單、可靠的優化，如有必要將加入性能監控的邏輯。而 C2 編譯模式，也是將字節碼編譯為本地代碼，但是會啟用一些編譯耗時較長的優化，甚至會根據性能監控信息進行一些不可靠的激進優化。

簡單地說 C1 編譯模式做的優化相對比較保守，其編譯速度相比 C2 較快。而 C2 編譯模式會做一些激進的優化，并且會根據性能監控做針對性優化，所以其編譯質量相對較好，但是耗時更長。

那么到底應該選擇 C1 編譯模式還是 C2 編譯模式呢？

實際上對于 HotSpot 虛擬機來說，其一共有三種運行模式可選，分別是：

混合模式(Mixed Mode) 。即 C1 和 C2 兩種模式混合起來使用，這是默認的運行模式。如果你想單獨使用 C1 模式或 C2 模式，使用 -client 或 -server 打開即可。

解釋模式(Interpreted Mode)。即所有代碼都解釋執行，使用 -Xint 參數可以打開這個模式。

編譯模式(Compiled Mode)。 此模式優先采用編譯，但是無法編譯時也會解釋執行，使用 -Xcomp 打開這種模式。

在命令行中輸入 java -version 可以看到，我機器上的虛擬機使用 Mixed Mode 運行模式。

寫到這里，我們了解了從 Java 源代碼到字節碼，再從字節碼到機器碼的全過程。本來到這里就應該結束了，但在我們 Java 中還有一個 AOT 編譯器，它能直接將源代碼轉化為機器碼。

AOT 編譯器：源代碼到機器碼

AOT 編譯器的基本思想是：在程序執行前生成 Java 方法的本地代碼，以便在程序運行時直接使用本地代碼。

但是 Java 語言本身的動態特性帶來了額外的復雜性，影響了 Java 程序靜態編譯代碼的質量。例如 Java 語言中的動態類加載，因為 AOT 是在程序運行前編譯的，所以無法獲知這一信息，所以會導致一些問題的產生。類似的問題還有很多，這里就不一一舉例了。

總的來說，AOT 編譯器從編譯質量上來看，肯定比不上 JIT 編譯器。其存在的目的在于避免 JIT 編譯器的運行時性能消耗或內存消耗，或者避免解釋程序的早期性能開銷。

在運行速度上來說，AOT 編譯器編譯出來的代碼比 JIT 編譯出來的慢，但是比解釋執行的快。而編譯時間上，AOT 也是一個始終的速度。所以說，AOT 編譯器的存在是 JVM 犧牲質量換取性能的一種策略。就如 JVM 其運行模式中選擇 Mixed 混合模式一樣，使用 C1 編譯模式只進行簡單的優化，而 C2 編譯模式則進行較為激進的優化。充分利用兩種模式的優點，從而達到最優的運行效率。

總結

在 JVM 中有三個非常重要的編譯器，它們分別是：前端編譯器、JIT 編譯器、AOT 編譯器。

前端編譯器，最常見的就是我們的 javac 編譯器，其將 Java 源代碼編譯為 Java 字節碼文件。JIT 即時編譯器，最常見的是 HotSpot 虛擬機中的 Client Compiler 和 Server Compiler，其將 Java 字節碼編譯為本地機器代碼。而 AOT 編譯器則能將源代碼直接編譯為本地機器碼。這三種編譯器的編譯速度和編譯質量如下：

編譯速度上，解釋執行 > AOT 編譯器 > JIT 編譯器。

編譯質量上，JIT 編譯器 > AOT 編譯器 > 解釋執行。

而在 JVM 中，通過這幾種不同方式的配合，使得 JVM 的編譯質量和運行速度達到最優的狀態。

參考資料

深入理解JVM之前端編譯器(一) | Gs Chen’s blog

深入淺出 JIT 編譯器

如何通俗易懂地介紹「即時編譯」(JIT)，它的優點和缺點是什么？ - 知乎

做一個 Hello World 級別的 JIT 編譯器

JIT中的C1和C2編譯器 - 簡書

Understanding Java JIT Compilation with JITWatch, Part 1 Oracle 官方文檔

HotSpot VM 想研究HotSpot C2編譯器編譯過程，請教如何入手？ - 討論 - 高級語言虛擬機 - ITeye群組 深入研究 HotSpot C2 的編譯過程

總結

以上是生活随笔為你收集整理的java虚拟机源码怎么看_java虚拟机JVM第4讲：从源代码到机器码，发生了什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。