from:http://www.cnblogs.com/insistence/p/5901457.html

1. 什么是Just In Time編譯器?

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() 方法。而這個動態查詢的過程從某種程度上說是很耗時的。

在主流商用JVM（HotSpot、J9）中，Java程序一開始是通過解釋器（Interpreter）進行解釋執行的。當JVM發現某個方法或代碼塊運行特別頻繁時，就會把這些代碼認定為“熱點代碼（Hot Spot Code）”，然后JVM會把這些代碼編譯成與本地平臺相關的機器碼，并進行各種層次的優化，完成這個任務的編譯器稱為：即時編譯器（Just In Time Compiler，JIT）

JIT編譯器是“動態編譯器”的一種，相對的“靜態編譯器”則是指的比如：C/C++的編譯器

JIT并不是JVM的必須部分，JVM規范并沒有規定JIT必須存在，更沒有限定和指導JIT。但是，JIT性能的好壞、代碼優化程度的高低卻是衡量一款JVM是否優秀的最關鍵指標之一，也是虛擬機中最核心且最能體現虛擬機技術水平的部分。

2. 編譯器與解釋器

首先，不是所有JVM都采用編譯器和解釋器并存的架構，但主流商用虛擬機，都同時包含這兩部分。

2.1 配合過程

  1. 當程序需要迅速啟動然后執行的時候，解釋器可以首先發揮作用，編譯器不運行從而省去編譯時間，立即執行程序

  2. 在程序運行后，隨著時間的推移，編譯器逐漸發揮作用，把越來越多的代碼編譯成本地代碼之后，可以獲得更高的執行效率

  3. 當程序運行環境中內存資源限制較大（如部分嵌入式系統中），可以使用解釋執行來節約內存；反之，則可以使用編譯執行來提升效率。

  4. 同時，解釋器還可以作為編譯器（C2才會激進優化）激進優化時的一個“逃生門”，讓編譯器根據概率選擇一些大多數時候都能提升運行速度的優化手段，當激進優化假設不成立。如：加載了新類后，類型繼承結構出現變化，出現“罕見陷阱（Uncommon Trap）”時，可以通過逆優化（Deoptimization）退回到解釋狀態繼續執行 
    (部分沒有解釋器的虛擬機，也會采用不進行激進優化的C1編譯器擔任“逃生門”的角色)

    這里寫圖片描述

2.2 解釋器 - Interpreter

Interpreter解釋執行class文件，好像JavaScript執行引擎一樣

特殊的例子：

  • 最早的Sun Classic VM只有Interpreter
  • BEA JRockit VM則只有Compiler，但它主要面向服務端應用，部署在其上的應用不重點關注啟動時間

2.3 編譯器 - Compiler

只說HotSpot JVM

1. C1和C2：

HotSpot虛擬機內置了兩個即時編譯器，分別稱為Client Compiler和Server Compiler，習慣上將前者稱為C1，后者稱為C2

2. 使用C1還是C2？

HotSpot默認采用解釋器和其中一個編譯器直接配合的方式工作，使用那個編譯器取決于虛擬機運行的模式，HotSpot會根據自身版本和宿主機器硬件性能自動選擇模式，用戶也可以使用“-client”或”-server”參數去指定

  1. 混合模式（Mixed Mode） 
    默認的模式，如上面描述的這種方式就是mixed mode

  2. 解釋模式（Interpreted Mode） 
    可以使用參數“-Xint”，在此模式下全部代碼解釋執行

  3. 編譯模式（Compiled Mode） 
    參數“-Xcomp”，此模式優先采用編譯，但是無法編譯時也會解釋（在最新的HotSpot中此參數被取消）

    可以看到，我的JVM現在是mixed mode 
    這里寫圖片描述

重要：↓

在JDK1.7（1.7僅包括Server模式）之后，HotSpot就不是默認“采用解釋器和其中一個編譯器”配合的方式了，而是采用了分層編譯，分層編譯時C1和C2有可能同時工作

3. 分層編譯

3.1 為什么要分層編譯？

由于編譯器compile本地代碼需要占用程序時間，要編譯出優化程度更高的代碼所花費的時間可能更長，且此時解釋器還要替編譯器收集性能監控信息，這對解釋執行的速度也有影響

所以，為了在程序啟動響應時間與運行效率之間達到最佳平衡，HotSpot在JDK1.6中出現了分層編譯（Tiered Compilation）的概念并在JDK1.7的Server模式JVM中作為默認策略被開啟

3.2 編譯層 tier（或者叫級別）

分層編譯根據編譯器編譯、優化的規模與耗時，劃分了不同的編譯層次（不只以下3種），包括：

  • 第0層，程序解釋執行（沒有編譯），解釋器不開啟性能監控功能，可觸發第1層編譯。

  • 第1層，也稱C1編譯，將字節碼編譯為本地代碼，進行簡單、可靠的優化，如有必要將加入性能監控的邏輯

  • 第2層（或2層以上），也稱為C2編譯，也是將字節碼編譯為本地代碼，但是會啟用一些編譯耗時較長的優化，甚至會根據性能監控信息進行一些不可靠的激進優化

實施分層編譯后，C1和C2將會同時工作，許多代碼會被多次編譯，用C1獲取更高的編譯速度，用C2來獲取更好的編譯質量，且在解釋執行的時候解釋器也無須再承擔收集性能監控信息的任務

4. 編譯對象與觸發條件

1. 誰被編譯了？

編譯對象就是之前說的“熱點代碼”，它有兩類：

  1. 被多次調用的方法 
    • 一個方法被多次調用，理應稱為熱點代碼，這種編譯也是虛擬機中標準的JIT編譯方式
  2. 被多次執行的循環體 
    • 編譯動作由循環體出發，但編譯對象依然會以整個方法為對象；
    • 這種編譯方式由于編譯發生在方法執行過程中，因此形象的稱為：棧上替換（On Stack Replacement- OSR編譯，即方法棧幀還在棧上，方法就被替換了）

2. 觸發條件

1. 綜述

上面的方法和循環體都說“多次”，那么多少算多？換個說法就是編譯的觸發條件。

判斷一段代碼是不是熱點代碼，是不是需要觸發JIT編譯，這樣的行為稱為：熱點探測（Hot Spot Detection），有幾種主流的探測方式：

  1. 基于計數器的熱點探測（Counter Based Hot Spot Detection） 
    虛擬機會為每個方法（或每個代碼塊）建立計數器，統計執行次數，如果超過閥值那么就是熱點代碼。缺點是維護計數器開銷。

  2. 基于采樣的熱點探測（Sample Based Hot Spot Detection） 
    虛擬機會周期性檢查各個線程的棧頂，如果某個方法經常出現在棧頂，那么就是熱點代碼。缺點是不精確。

  3. 基于蹤跡的熱點探測（Trace Based Hot Spot Detection） 
    Dalvik中的JIT編譯器使用這種方式

2. HotSpot

HotSpot使用的是第1種，因此它為每個方法準備了兩類計數器：方法調用計數器（Invocation Counter）和回邊計數器（Back Edge Counter）

  1. 方法計數器

    • 默認閥值，在Client模式下是1500次，Server是10000次，可以通過參數“-XX:CompileThreshold”來設定

    • 當一個方法被調用時會首先檢查是否存在被JIT編譯過得版本，如果存在則使用此本地代碼來執行；如果不存在，則將方法計數器+1，然后判斷“方法計數器和回邊計數器之和”是否超過閥值，如果是則會向編譯器提交一個方法編譯請求

    • 默認情況下，執行引擎并不會同步等待上面的編譯完成，而是會繼續解釋執行。當編譯完成后，此方法的調用入口地址會被系統自動改寫為新的本地代碼地址

    • 還有一點，熱度是會衰減的，也就是說不是僅僅+，也會-，熱度衰減動作是在虛擬機的GC執行時順便進行的

  2. 回邊計數器

    • 回邊，顧名思義，只有執行到大括號”}”時才算+1

    • 默認閥值，Client下13995，Server下10700

    • 它的調用邏輯和方法計數器差不多，只不過遇到回邊指令時+1、超過閥值時會提交OSR編譯請求以及這里沒有熱度衰減

5. 編譯過程

編譯過程是在后臺線程（daemon）中完成的，可以通過參數“-XX:-BackgroundCompilation”來禁止后臺編譯，但此時執行線程就會同步等待編譯完成才會執行程序

  1. Client Compiler 
    C1編譯器是一個簡單快速的三段式編譯器，主要關注“局部性能優化”，放棄許多耗時較長的全局優化手段 
    過程：class -> 1. 高級中間代碼 -> 2. 低級中間代碼 -> 3. 機器代碼
  2. Server Compiler 
    C2是專門面向服務器應用的編譯器，是一個充分優化過的高級編譯器，幾乎能達到GNU C++編譯器使用-O2參數時的優化強度。

使用參數“-XX:+PrintCompilation”會讓虛擬機在JIT時把方法名稱打印出來，如圖： 
這里寫圖片描述

6. Java和C/C++的編譯器對比

這里不是比Java和C/C++誰快這種大坑問題，只是比較編譯器（我認為開發效率上Java快，執行效率上C/C++快）

這種對比代表了經典的即時編譯器與靜態編譯期的對比，其實總體來說Java編譯器有優有劣。主要就是動態編譯時間壓力大能做的優化少，還要做一些動態校驗。而靜態編譯器無法實現一些開發上很有用的動態特性