在部分的商用虛擬機器中，Java 程式最初是通過直譯器（ Interpreter ）進行解釋執行的，當虛擬機發現某個方法或程式碼塊的執行特別頻繁的時候，就會把這些程式碼認定為“熱點程式碼”。為了提高熱點程式碼的執行效率，在執行時，即時編譯器（Just In Time Compiler ）會把這些程式碼編譯成與本地平臺相關的機器碼，並進行各種層次的優化。

1、HotSpot 內的即時編譯器

直譯器和編譯器各有各的優點：

直譯器優點：當程式需要迅速啟動的時候，直譯器可以首先發揮作用，省去了編譯的時間，立即執行。解釋執行佔用更小的記憶體空間。同時，當編譯器進行的激進優化失敗的時候，還可以進行逆優化來恢復到解釋執行的狀態。

編譯器優點：在程式執行時，隨著時間的推移，編譯器逐漸發揮作用，把越來越多的程式碼編譯成原生代碼之後，可以獲得更高的執行效率。

因此，整個虛擬機器執行架構中，直譯器與編譯器經常配合工作，如下圖所示。

HotSpot中內建了兩個即時編譯器，分別稱為 Client Compiler和 Server Compiler ，或者簡稱為 C1 編譯器和 C2 編譯器。目前的 HotSpot 編譯器預設的是直譯器和其中一個即時編譯器配合的方式工作，具體是哪一個編譯器，取決於虛擬機器執行的模式，HotSpot 虛擬機器會根據自身版本與計算機的硬體效能自動選擇執行模式，使用者也可以使用 -client 和 -server 引數強制指定虛擬機器執行在 Client 模式或者 Server 模式。這種配合使用的方式稱為“混合模式”（Mixed Mode）

，使用者可以使用引數 -Xint 強制虛擬機器運行於 “解釋模式”（Interpreted Mode），這時候編譯器完全不介入工作。另外，使用 -Xcomp 強制虛擬機器運行於 “編譯模式”（Compiled Mode），這時候將優先採用編譯方式執行，但是直譯器仍然要在編譯無法進行的情況下接入執行過程。通過虛擬機器 -version 命令可以檢視當前預設的執行模式。

2、被編譯物件和觸發條件

在執行過程中會被即時編譯的“熱點程式碼”有兩類，即：

• 被多次呼叫的方法
• 被多次執行的迴圈體

對於第一種，編譯器會將整個方法作為編譯物件，這也是標準的JIT 編譯方式。對於第二種是由迴圈體出發的，但是編譯器依然會以整個方法作為編譯物件，因為發生在方法執行過程中，稱為棧上替換

。

判斷一段程式碼是否是熱點程式碼，是不是需要出發即時編譯，這樣的行為稱為熱點探測（Hot Spot Detection），探測演算法有兩種，分別為。

• 基於取樣的熱點探測（Sample Based Hot Spot Detection）：虛擬機器會週期的對各個執行緒棧頂進行檢查，如果某些方法經常出現在棧頂，這個方法就是“熱點方法”。好處是實現簡單、高效，很容易獲取方法呼叫關係。缺點是很難確認方法的reduce，容易受到執行緒阻塞或其他外因擾亂。
• 基於計數器的熱點探測（Counter Based Hot Spot Detection）：為每個方法（甚至是程式碼塊）建立計數器，執行次數超過閾值就認為是“熱點方法”。優點是統計結果精確嚴謹。缺點是實現麻煩，不能直接獲取方法的呼叫關係。

HotSpot 使用的是第二種-基於技術其的熱點探測，並且有兩類計數器：方法呼叫計數器（Invocation Counter ）和回邊計數器（Back Edge Counter ）。

這兩個計數器都有一個確定的閾值，超過後便會觸發 JIT 編譯。

首先是方法呼叫計數器。Client 模式下預設閾值是 1500 次，在 Server 模式下是 10000次，這個閾值可以通過 -XX：CompileThreadhold 來人為設定。如果不做任何設定，方法呼叫計數器統計的並不是方法被呼叫的絕對次數，而是一個相對的執行頻率，即一段時間之內的方法被呼叫的次數。當超過一定的時間限度，如果方法的呼叫次數仍然不足以讓它提交給即時編譯器編譯，那麼這個方法的呼叫計數器就會被減少一半，這個過程稱為方法呼叫計數器熱度的衰減（Counter Decay），而這段時間就成為此方法的統計的半衰週期（ Counter Half Life Time）。進行熱度衰減的動作是在虛擬機器進行垃圾收集時順便進行的，可以使用虛擬機器引數 -XX：CounterHalfLifeTime 引數設定半衰週期的時間，單位是秒。整個 JIT 編譯的互動過程如下圖。

第二個回邊計數器，作用是統計一個方法中迴圈體程式碼執行的次數，在位元組碼中遇到控制流向後跳轉的指令稱為“回邊”（ Back Edge ）。顯然，建立回邊計數器統計的目的就是為了觸發 OSR 編譯。關於這個計數器的閾值， HotSpot 提供了 -XX：BackEdgeThreshold 供使用者設定，但是當前的虛擬機器實際上使用了 -XX：OnStackReplacePercentage 來簡介調整閾值，計算公式如下：

在 Client 模式下， 公式為 方法呼叫計數器閾值（CompileThreshold）X OSR 比率（OnStackReplacePercentage）/ 100 。其中 OSR 比率預設為 933，那麼，回邊計數器的閾值為 13995。

在 Server 模式下，公式為 方法呼叫計數器閾值（Compile Threashold）X （OSR (OnStackReplacePercentage)- 直譯器監控比率 （InterpreterProfilePercent））/100

其中 onStackReplacePercentage 預設值為 140，InterpreterProfilePercentage 預設值為 33，如果都取預設值，那麼 Server 模式虛擬機器回邊計數器閾值為 10700 。

執行過程，如下圖。

3、編譯過程

預設情況下，無論是方法呼叫產生的即時編譯請求，還是 OSR 請求，虛擬機器在程式碼編譯器還未完成之前，都仍然將按照解釋方式繼續執行，而編譯動作則在後臺的編譯執行緒中進行，使用者可以通過引數 -XX：-BackgroundCompilation 來禁止後臺編譯，這樣，一旦達到 JIT 的編譯條件，執行執行緒向虛擬機器提交便已請求之後便會一直等待，直到編譯過程完成後再開始執行編譯器輸出的原生代碼。

對於 Client 模式而言

它是一個簡單快速的三段式編譯器，主要關注點在於區域性的優化，放棄了許多耗時較長的全域性優化手段。

1. 第一階段，一個平臺獨立的前端將位元組碼構造成一種高階中間程式碼表示（High-Level Intermediate Representaion ， HIR）。在此之前，編譯器會在位元組碼上完成一部分基礎優化，如 方法內聯，常量傳播等優化。
2. 第二階段，一個平臺相關的後端從 HIR 中產生低階中間程式碼表示（Low-Level Intermediate Representation ，LIR），而在此之前會在 HIR 上完成另外一些優化，如空值檢查消除，範圍檢查消除等，讓HIR 更為高效。
3. 第三階段，在平臺相關的後端使用線性掃描演算法（Linear Scan Register Allocation）在 LIR 上分配暫存器，做窺孔（Peephole）優化，然後產生機器碼。 

Client Compiler 的大致執行過程如下圖所示：

對於 Server Compiler 模式而言

它是專門面向服務端的典型應用，併為服務端的效能配置特別調整過的編譯器，也是一個充分優化過的高階編譯器，幾乎能達到 GNU C++ 編譯器使用-O2 引數時的優化強度，它會執行所有的經典的優化動作，如 無用程式碼消除（Dead Code Elimination）、迴圈展開（Loop Unrolling）、迴圈表示式外提（Loop Expression Hoisting）、消除公共子表示式（Common Subexpression Elimination）、常量傳播（Constant Propagation）、基本塊衝排序（Basic Block Reordering）等，還會實施一些與 Java 語言特性密切相關的優化技術，如範圍檢查消除（Range Check Elimination）、空值檢查消除（Null Check Elimination ，不過並非所有的空值檢查消除都是依賴編譯器優化的，有一些是在程式碼執行過程中自動優化 了）等。另外，還可能根據直譯器或Client Compiler 提供的效能監控資訊，進行一些不穩定的激進優化，如 守護內聯（Guarded Inlining）、分支頻率預測（Branch Frequency Prediction）等。

Server Compiler 編譯器可以充分利用某些處理器架構，如（RISC）上的大暫存器集合。從即時編譯的角度來看， Server Compiler 無疑是比較緩慢的，但它的便以速度仍遠遠超過傳統的靜態優化編譯器，而且它相對於 Client Compiler編譯輸出的程式碼質量有所提高，可以減少原生代碼的執行時間，從而抵消了額外的編譯時間開銷，所以也有很多非服務端的應用選擇使用 Server 模式的虛擬機器執行。