本文將深入淺出地講解 JIT 編譯器在 JVM 中的運作原理，使讀者能夠更好的理解 Java 底層機制并且為讀者在 Java 性能優化領域打開更廣的視野。

JIT 簡介

JIT 是 just in time 的縮寫, 也就是即時編譯編譯器。使用即時編譯器技術，能夠加速 Java 程序的執行速度。下面，就對該編譯器技術做個簡單的講解。

首先，我們大家都知道，通常通過 javac 將程序源代碼編譯，轉換成 java 字節碼，JVM 通過解釋字節碼將其翻譯成對應的機器指令，逐條讀入，逐條解釋翻譯。很顯然，經過解釋執行，其執行速度必然會比可執行的二進制字節碼程序慢很多。為了提高執行速度，引入了 JIT 技術。

在運行時 JIT 會把翻譯過的機器碼保存起來，以備下次使用，因此從理論上來說，采用該 JIT 技術可以接近以前純編譯技術。下面我們看看，JIT 的工作過程。

JIT 編譯過程

當 JIT 編譯啟用時（默認是啟用的），JVM 讀入.class 文件解釋后，將其發給 JIT 編譯器。JIT 編譯器將字節碼編譯成本機機器代碼，下圖展示了該過程。

圖 1. JIT 工作原理圖

回頁首

Hot Spot 編譯

當 JVM 執行代碼時，它并不立即開始編譯代碼。這主要有兩個原因：

首先，如果這段代碼本身在將來只會被執行一次，那么從本質上看，編譯就是在浪費精力。因為將代碼翻譯成 java 字節碼相對于編譯這段代碼并執行代碼來說，要快很多。

當然，如果一段代碼頻繁的調用方法，或是一個循環，也就是這段代碼被多次執行，那么編譯就非常值得了。因此，編譯器具有的這種權衡能力會首先執行解釋后的代碼，然后再去分辨哪些方法會被頻繁調用來保證其本身的編譯。其實說簡單點，就是 JIT 在起作用，我們知道，對于 Java 代碼，剛開始都是被編譯器編譯成字節碼文件，然后字節碼文件會被交由 JVM 解釋執行，所以可以說 Java 本身是一種半編譯半解釋執行的語言。Hot Spot VM 采用了 JIT compile 技術，將運行頻率很高的字節碼直接編譯為機器指令執行以提高性能，所以當字節碼被 JIT 編譯為機器碼的時候，要說它是編譯執行的也可以。也就是說，運行時，部分代碼可能由 JIT 翻譯為目標機器指令（以 method 為翻譯單位，還會保存起來，第二次執行就不用翻譯了）直接執行。

第二個原因是最優化，當 JVM 執行某一方法或遍歷循環的次數越多，就會更加了解代碼結構，那么 JVM 在編譯代碼的時候就做出相應的優化。

我們將在后面講解這些優化策略，這里，先舉一個簡單的例子：我們知道 equals() 這個方法存在于每一個 Java Object 中（因為是從 Object class 繼承而來）而且經常被覆寫。當解釋器遇到 b = obj1.equals(obj2) 這樣一句代碼，它則會查詢 obj1 的類型從而得知到底運行哪一個 equals() 方法。而這個動態查詢的過程從某種程度上說是很耗時的。

寄存器和主存

其中一個最重要的優化策略是編譯器可以決定何時從主存取值，何時向寄存器存值。考慮下面這段代碼：

清單 1. 主存 or 寄存器測試代碼

public class RegisterTest {  private int sum;   public void calculateSum(int n) {  for (int i = 0; i < n; ++i) {  sum += i;  }  } }

在某些時刻，sum 變量居于主存之中，但是從主存中檢索值是開銷很大的操作，需要多次循環才可以完成操作。正如上面的例子，如果循環的每一次都是從主存取值，性能是非常低的。相反，編譯器加載一個寄存器給 sum 并賦予其初始值，利用寄存器里的值來執行循環，并將最終的結果從寄存器返回給主存。這樣的優化策略則是非常高效的。但是線程的同步對于這種操作來說是至關重要的，因為一個線程無法得知另一個線程所使用的寄存器里變量的值，線程同步可以很好的解決這一問題，有關于線程同步的知識，我們將在后續文章中進行講解。

寄存器的使用是編譯器的一個非常普遍的優化。

回到之前的例子，JVM 注意到每次運行代碼時，obj1 都是 java.lang.String 這種類型，那么 JVM 生成的被編譯后的代碼則是直接調用 String.equals() 方法。這樣代碼的執行將變得非常快，因為不僅它是被編譯過的，而且它會跳過查找該調用哪個方法的步驟。

當然過程并不是上面所述這樣簡單，如果下次執行代碼時，obj1 不再是 String 類型了，JVM 將不得不再生成新的字節碼。盡管如此，之后執行的過程中，還是會變的更快，因為同樣會跳過查找該調用哪個方法的步驟。這種優化只會在代碼被運行和觀察一段時間之后發生。這也就是為什么 JIT 編譯器不會理解編譯代碼而是選擇等待然后再去編譯某些代碼片段的第二個原因。

回頁首

初級調優：客戶模式或服務器模式

JIT 編譯器在運行程序時有兩種編譯模式可以選擇，并且其會在運行時決定使用哪一種以達到最優性能。這兩種編譯模式的命名源自于命令行參數（eg: -client 或者 -server）。JVM Server 模式與 client 模式啟動，最主要的差別在于：-server 模式啟動時，速度較慢，但是一旦運行起來后，性能將會有很大的提升。原因是：當虛擬機運行在-client 模式的時候，使用的是一個代號為 C1 的輕量級編譯器，而-server 模式啟動的虛擬機采用相對重量級代號為 C2 的編譯器。C2 比 C1 編譯器編譯的相對徹底，服務起來之后，性能更高。

通過 java -version 命令行可以直接查看當前系統使用的是 client 還是 server 模式。例如：

圖 2. 查看編譯模式

回頁首

中級編譯器調優

大多數情況下，優化編譯器其實只是選擇合適的 JVM 以及為目標主機選擇合適的編譯器（-cient，-server 或是-xx:+TieredCompilation）。多層編譯經常是長時運行應用程序的最佳選擇，短暫應用程序則選擇毫秒級性能的 client 編譯器。

優化代碼緩存

當 JVM 編譯代碼時，它會將匯編指令集保存在代碼緩存。代碼緩存具有固定的大小，并且一旦它被填滿，JVM 則不能再編譯更多的代碼。

我們可以很容易地看到如果代碼緩存很小所具有的潛在問題。有些熱點代碼將會被編譯，而其他的則不會被編譯，這個應用程序將會以運行大量的解釋代碼來結束。

這是當使用 client 編譯器模式或分層編譯時很頻繁的一個問題。當使用普通 server 編譯器模式時，編譯合格的類的數量將被填入代碼緩存，通常只有少量的類會被編譯。但是當使用 client 編譯器模式時，編譯合格的類的數量將會高很多。

在 Java 7 版本，分層編譯默認的代碼緩存大小經常是不夠的，需要經常提高代碼緩存大小。大型項目若使用 client 編譯器模式，則也需要提高代碼緩存大小。

現在并沒有一個好的機制可以確定一個特定的應用到底需要多大的代碼緩存。因此，當需要提高代碼緩存時，這將是一種湊巧的操作，一個通常的做法是將代碼緩存變成默認大小的兩倍或四倍。

可以通過 –XX:ReservedCodeCacheSize=Nflag（N 就是之前提到的默認大小）來最大化代碼緩存大小。代碼緩存的管理類似于 JVM 中的內存管理：有一個初始大小（用-XX:InitialCodeCacheSize=N 來聲明）。代碼緩存的大小從初始大小開始，隨著緩存被填滿而逐漸擴大。代碼緩存的初始大小是基于芯片架構（例如 Intel 系列機器，client 編譯器模式下代碼緩存大小起始于 160KB，server 編譯器模式下代碼緩存大小則起始于 2496KB）以及使用的編譯器的。重定義代碼緩存的大小并不會真正影響性能，所以設置 ReservedCodeCacheSize 的大小一般是必要的。

再者，如果 JVM 是 32 位的，那么運行過程大小不能超過 4GB。這包括了 Java 堆，JVM 自身所有的代碼空間（包括其本身的庫和線程棧），應用程序分配的任何的本地內存，當然還有代碼緩存。

所以說代碼緩存并不是無限的，很多時候需要為大型應用程序來調優（或者甚至是使用分層編譯的中型應用程序）。比如 64 位機器，為代碼緩存設置一個很大的值并不會對應用程序本身造成影響，應用程序并不會內存溢出，這些額外的內存預定一般都是被操作系統所接受的。

編譯閾值

在 JVM 中，編譯是基于兩個計數器的：一個是方法被調用的次數，另一個是方法中循環被回彈執行的次數。回彈可以有效的被認為是循環被執行完成的次數，不僅因為它是循環的結尾，也可能是因為它執行到了一個分支語句，例如 continue。

當 JVM 執行一個 Java 方法，它會檢查這兩個計數器的總和以決定這個方法是否有資格被編譯。如果有，則這個方法將排隊等待編譯。這種編譯形式并沒有一個官方的名字，但是一般被叫做標準編譯。

但是如果方法里有一個很長的循環或者是一個永遠都不會退出并提供了所有邏輯的程序會怎么樣呢？這種情況下，JVM 需要編譯循環而并不等待方法被調用。所以每執行完一次循環，分支計數器都會自增和自檢。如果分支計數器計數超出其自身閾值，那么這個循環（并不是整個方法）將具有被編譯資格。

這種編譯叫做棧上替換（OSR），因為即使循環被編譯了，這也是不夠的：JVM 必須有能力當循環正在運行時，開始執行此循環已被編譯的版本。換句話說，當循環的代碼被編譯完成，若 JVM 替換了代碼（前棧），那么循環的下個迭代執行最新的被編譯版本則會更加快。

標準編譯是被-XX:CompileThreshold=Nflag 的值所觸發。Client 編譯器模式下，N 默認的值 1500，而 Server 編譯器模式下，N 默認的值則是 10000。改變 CompileThreshold 標志的值將會使編譯器相對正常情況下提前（或推遲）編譯代碼。在性能領域，改變 CompileThreshold 標志是很被推薦且流行的方法。事實上，您可能知道 Java 基準經常使用此標志（比如：對于很多 server 編譯器來說，經常在經過 8000 次迭代后改變次標志）。

我們已經知道 client 編譯器和 server 編譯器在最終的性能上有很大的差別，很大程度上是因為編譯器在編譯一個特定的方法時，對于兩種編譯器可用的信息并不一樣。降低編譯閾值，尤其是對于 server 編譯器，承擔著不能使應用程序運行達到最佳性能的風險，但是經過測試應用程序我們也發現，將閾值從 8000 變成 10000，其實有著非常小的區別和影響。

檢查編譯過程

中級優化的最后一點其實并不是優化本身，而是它們并不能提高應用程序的性能。它們是 JVM（以及其他工具）的各個標志，并可以給出編譯工作的可見性。它們中最重要的就是--XX:+PrintCompilation（默認狀態下是 false）。

如果 PrintCompilation 被啟用，每次一個方法（或循環）被編譯，JVM 都會打印出剛剛編譯過的相關信息。不同的 Java 版本輸出形式不一樣，我們這里所說的是基于 Java 7 版本的。

編譯日志中大部分的行信息都是下面的形式：

清單 2. 日志形式

timestamp compilation_id attributes (tiered_level) method_name size depot

這里 timestamp 是編譯完成時的時間戳，compilation_id 是一個內部的任務 ID，且通常情況下這個數字是單調遞增的，但有時候對于 server 編譯器（或任何增加編譯閾值的時候），您可能會看到失序的編譯 ID。這表明編譯線程之間有些快有些慢，但請不要隨意推斷認為是某個編譯器任務莫名其妙的非常慢。

用 jstat 命令檢查編譯

要想看到編譯日志，則需要程序以-XX:+PrintCompilation flag 啟動。如果程序啟動時沒有 flag，您可以通過 jstat 命令得到有限的可見性信息。

Jstat 有兩個選項可以提供編譯器信息。其中，-compile 選項提供總共有多少方法被編譯的總結信息（下面 6006 是要被檢查的程序的進程 ID）：

清單 3 進程詳情

% jstat -compiler 6006 CompiledFailedInvalid TimeFailedTypeFailedMethod 206 0 0 1.97 0

注意，這里也列出了編譯失敗的方法的個數信息，以及編譯失敗的最后一個方法的名稱。

另一種選擇，您可以使用-printcompilation 選項得到最后一個被編譯的方法的編譯信息。因為 jstat 命令有一個參數選項用來重復其操作，您可以觀察每一次方法被編譯的情況。舉個例子：

Jstat 對 6006 號 ID 進程每 1000 毫秒執行一次： %jstat –printcompilation 6006 1000，具體的輸出信息在此不再描述。

回頁首

高級編譯器調優

這一節我們將介紹編譯工作剩下的細節，并且過程中我們會探討一些額外的調優策略。調優的存在很大程度上幫助了 JVM 工程師診斷 JVM 自身的行為。如果您對編譯器的工作原理很感興趣，這一節您一定會喜歡。

編譯線程

從前文中我們知道，當一個方法（或循環）擁有編譯資格時，它就會排隊并等待編譯。這個隊列是由一個或很多個后臺線程組成。這也就是說編譯是一個異步的過程。它允許程序在代碼正在編譯時被繼續執行。如果一個方法被標準編譯方式所編譯，那么下一個方法調用則會執行已編譯的方法。如果一個循環被棧上替換方式所編譯，那么下一次循環迭代則會執行新編譯的代碼。

這些隊列并不會嚴格的遵守先進先出原則：哪一個方法的調用計數器計數更高，哪一個就擁有優先權。所以即使當一個程序開始執行，并且有大量的代碼需要編譯，這個優先權順序將幫助并保證最重要的代碼被優先編譯（這也是為什么編譯 ID 在 PrintComilation 的輸出結果中有時會失序的另一個原因）。

當使用 client 編譯器時，JVM 啟動一個編譯線程，而 server 編譯器有兩個這樣的線程。當分層編譯生效時，JVM 會基于某些復雜方程式默認啟動多個 client 和 server 線程，涉及雙日志在目標平臺上的 CPU 數量。如下圖所示：

分層編譯下 C1 和 C2 編譯器線程默認數量：

圖 3. C1 和 C2 編譯器默認數量

編譯器線程的數量可以通過-XX:CICompilerCount=N flag 進行調節設置。這個數量是 JVM 將要執行隊列所用的線程總數。對于分層編譯，三分之一的（至少一個）線程被用于執行 client 編譯器隊列，剩下的（也是至少一個）被用來執行 server 編譯器隊列。

在何時我們應該考慮調整這個值呢？如果一個程序被運行在單 CPU 機器上，那么只有一個編譯線程會更好一些：因為對于某個線程來說，其對 CPU 的使用是有限的，并且在很多情況下越少的線程競爭資源會使其運行性能更高。然而，這個優勢僅僅局限于初始預熱階段，之后，這些具有編譯資格的方法并不會真的引起 CPU 爭用。當一個股票批處理應用程序運行在單 CPU 機器上并且編譯器線程被限制成只有一個，那么最初的計算過程將比一般情況下快 10%（因為它沒有被其他線程進行 CPU 爭用）。迭代運行的次數越多，最初的性能收益就相對越少，直到所有的熱點方法被編譯完性能收益也隨之終止。

回頁首

結束語

本文詳細介紹了 JIT 編譯器的工作原理。從優化的角度講，最簡單的選擇就是使用 server 編譯器的分層編譯技術，這將解決大約 90%左右的與編譯器直接相關的性能問題。最后，請保證代碼緩存的大小設置的足夠大，這樣編譯器將會提供最高的編譯性能。

轉載自點擊打開鏈接