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

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

Hot Spot 編譯

當(dāng) JVM 執(zhí)行代碼時(shí)，它并不立即開(kāi)始編譯代碼。這主要有兩個(gè)原因：

首先，如果這段代碼本身在將來(lái)只會(huì)被執(zhí)行一次，那么從本質(zhì)上看，編譯就是在浪費(fèi)精力。因?yàn)閷⒋a翻譯成 java 字節(jié)碼相對(duì)于編譯這段代碼并執(zhí)行代碼來(lái)說(shuō)，要快很多。

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

第二個(gè)原因是最優(yōu)化，當(dāng) JVM 執(zhí)行某一方法或遍歷循環(huán)的次數(shù)越多，就會(huì)更加了解代碼結(jié)構(gòu)，那么 JVM 在編譯代碼的時(shí)候就做出相應(yīng)的優(yōu)化。

我 們將在后面講解這些優(yōu)化策略，這里，先舉一個(gè)簡(jiǎn)單的例子：我們知道 equals() 這個(gè)方法存在于每一個(gè) Java Object 中（因?yàn)槭菑?Object class 繼承而來(lái)）而且經(jīng)常被覆寫(xiě)。當(dāng)解釋器遇到 b = obj1.equals(obj2) 這樣一句代碼，它則會(huì)查詢 obj1 的類(lèi)型從而得知到底運(yùn)行哪一個(gè) equals() 方法。而這個(gè)動(dòng)態(tài)查詢的過(guò)程從某種程度上說(shuō)是很耗時(shí)的。

在主流商用JVM（HotSpot、J9）中，Java程序一開(kāi)始是通過(guò)解釋器（Interpreter）進(jìn)行解釋執(zhí)行的。當(dāng)JVM發(fā)現(xiàn)某個(gè)方法或代碼塊運(yùn)行特別頻繁時(shí)，就會(huì)把這些代碼認(rèn)定為“熱點(diǎn)代碼（Hot Spot Code）”，然后JVM會(huì)把這些代碼編譯成與本地平臺(tái)相關(guān)的機(jī)器碼，并進(jìn)行各種層次的優(yōu)化，完成這個(gè)任務(wù)的編譯器稱為：即時(shí)編譯器（Just In Time Compiler，JIT）

JIT編譯器是“動(dòng)態(tài)編譯器”的一種，相對(duì)的“靜態(tài)編譯器”則是指的比如：C/C++的編譯器

JIT并不是JVM的必須部分，JVM規(guī)范并沒(méi)有規(guī)定JIT必須存在，更沒(méi)有限定和指導(dǎo)JIT。但是，JIT性能的好壞、代碼優(yōu)化程度的高低卻是衡量一款JVM是否優(yōu)秀的最關(guān)鍵指標(biāo)之一，也是虛擬機(jī)中最核心且最能體現(xiàn)虛擬機(jī)技術(shù)水平的部分。

2. 編譯器與解釋器

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

2.1 配合過(guò)程

1. 當(dāng)程序需要迅速啟動(dòng)然后執(zhí)行的時(shí)候，解釋器可以首先發(fā)揮作用，編譯器不運(yùn)行從而省去編譯時(shí)間，立即執(zhí)行程序

2. 在程序運(yùn)行后，隨著時(shí)間的推移，編譯器逐漸發(fā)揮作用，把越來(lái)越多的代碼編譯成本地代碼之后，可以獲得更高的執(zhí)行效率

3. 當(dāng)程序運(yùn)行環(huán)境中內(nèi)存資源限制較大（如部分嵌入式系統(tǒng)中），可以使用解釋執(zhí)行來(lái)節(jié)約內(nèi)存；反之，則可以使用編譯執(zhí)行來(lái)提升效率。

4. 同時(shí)，解釋器還可以作為編譯器（C2才會(huì)激進(jìn)優(yōu)化）激進(jìn)優(yōu)化時(shí)的一個(gè)“逃生門(mén)”，讓編譯器根據(jù)概率選擇一些大多數(shù)時(shí)候都能提升運(yùn)行速度的優(yōu)化手段，當(dāng)激進(jìn)優(yōu)化假設(shè)不成立。如：加載了新類(lèi)后，類(lèi)型繼承結(jié)構(gòu)出現(xiàn)變化，出現(xiàn)“罕見(jiàn)陷阱（Uncommon Trap）”時(shí)，可以通過(guò)逆優(yōu)化（Deoptimization）退回到解釋狀態(tài)繼續(xù)執(zhí)行 
   (部分沒(méi)有解釋器的虛擬機(jī)，也會(huì)采用不進(jìn)行激進(jìn)優(yōu)化的C1編譯器擔(dān)任“逃生門(mén)”的角色)

   

2.2 解釋器 - Interpreter

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

特殊的例子：

• 最早的Sun Classic VM只有Interpreter
• BEA JRockit VM則只有Compiler，但它主要面向服務(wù)端應(yīng)用，部署在其上的應(yīng)用不重點(diǎn)關(guān)注啟動(dòng)時(shí)間

2.3 編譯器 - Compiler

只說(shuō)HotSpot JVM

1. C1和C2：

HotSpot虛擬機(jī)內(nèi)置了兩個(gè)即時(shí)編譯器，分別稱為Client Compiler和Server Compiler，習(xí)慣上將前者稱為C1，后者稱為C2

2. 使用C1還是C2？

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

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

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

3. 編譯模式（Compiled Mode） 
   參數(shù)“-Xcomp”，此模式優(yōu)先采用編譯，但是無(wú)法編譯時(shí)也會(huì)解釋（在最新的HotSpot中此參數(shù)被取消）

   可以看到，我的JVM現(xiàn)在是mixed mode 
   

重要：↓

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

3. 分層編譯

3.1 為什么要分層編譯？

由于編譯器compile本地代碼需要占用程序時(shí)間，要編譯出優(yōu)化程度更高的代碼所花費(fèi)的時(shí)間可能更長(zhǎng)，且此時(shí)解釋器還要替編譯器收集性能監(jiān)控信息，這對(duì)解釋執(zhí)行的速度也有影響

所以，為了在程序啟動(dòng)響應(yīng)時(shí)間與運(yùn)行效率之間達(dá)到最佳平衡，HotSpot在JDK1.6中出現(xiàn)了分層編譯（Tiered Compilation）的概念并在JDK1.7的Server模式JVM中作為默認(rèn)策略被開(kāi)啟

3.2 編譯層 tier（或者叫級(jí)別）

分層編譯根據(jù)編譯器編譯、優(yōu)化的規(guī)模與耗時(shí)，劃分了不同的編譯層次（不只以下3種），包括：

• 第0層，程序解釋執(zhí)行（沒(méi)有編譯），解釋器不開(kāi)啟性能監(jiān)控功能，可觸發(fā)第1層編譯。

• 第1層，也稱C1編譯，將字節(jié)碼編譯為本地代碼，進(jìn)行簡(jiǎn)單、可靠的優(yōu)化，如有必要將加入性能監(jiān)控的邏輯

• 第2層（或2層以上），也稱為C2編譯，也是將字節(jié)碼編譯為本地代碼，但是會(huì)啟用一些編譯耗時(shí)較長(zhǎng)的優(yōu)化，甚至?xí)?/strong>根據(jù)性能監(jiān)控信息進(jìn)行一些不可靠的激進(jìn)優(yōu)化

實(shí)施分層編譯后，C1和C2將會(huì)同時(shí)工作，許多代碼會(huì)被多次編譯，用C1獲取更高的編譯速度，用C2來(lái)獲取更好的編譯質(zhì)量，且在解釋執(zhí)行的時(shí)候解釋器也無(wú)須再承擔(dān)收集性能監(jiān)控信息的任務(wù)

4. 編譯對(duì)象與觸發(fā)條件

1. 誰(shuí)被編譯了？

編譯對(duì)象就是之前說(shuō)的“熱點(diǎn)代碼”，它有兩類(lèi)：

1. 被多次調(diào)用的方法 
   
   • 一個(gè)方法被多次調(diào)用，理應(yīng)稱為熱點(diǎn)代碼，這種編譯也是虛擬機(jī)中標(biāo)準(zhǔn)的JIT編譯方式
2. 被多次執(zhí)行的循環(huán)體 
   
   • 編譯動(dòng)作由循環(huán)體出發(fā)，但編譯對(duì)象依然會(huì)以整個(gè)方法為對(duì)象；
   • 這種編譯方式由于編譯發(fā)生在方法執(zhí)行過(guò)程中，因此形象的稱為：棧上替換（On Stack Replacement- OSR編譯，即方法棧幀還在棧上，方法就被替換了）

2. 觸發(fā)條件

1. 綜述

上面的方法和循環(huán)體都說(shuō)“多次”，那么多少算多？換個(gè)說(shuō)法就是編譯的觸發(fā)條件。

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

1. 基于計(jì)數(shù)器的熱點(diǎn)探測(cè)（Counter Based Hot Spot Detection） 
   虛擬機(jī)會(huì)為每個(gè)方法（或每個(gè)代碼塊）建立計(jì)數(shù)器，統(tǒng)計(jì)執(zhí)行次數(shù)，如果超過(guò)閥值那么就是熱點(diǎn)代碼。缺點(diǎn)是維護(hù)計(jì)數(shù)器開(kāi)銷(xiāo)。

2. 基于采樣的熱點(diǎn)探測(cè)（Sample Based Hot Spot Detection） 
   虛擬機(jī)會(huì)周期性檢查各個(gè)線程的棧頂，如果某個(gè)方法經(jīng)常出現(xiàn)在棧頂，那么就是熱點(diǎn)代碼。缺點(diǎn)是不精確。

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

2. HotSpot

HotSpot使用的是第1種，因此它為每個(gè)方法準(zhǔn)備了兩類(lèi)計(jì)數(shù)器：方法調(diào)用計(jì)數(shù)器（Invocation Counter）和回邊計(jì)數(shù)器（Back Edge Counter）

1. 方法計(jì)數(shù)器

   • 默認(rèn)閥值，在Client模式下是1500次，Server是10000次，可以通過(guò)參數(shù)“-XX:CompileThreshold”來(lái)設(shè)定

   • 當(dāng)一個(gè)方法被調(diào)用時(shí)會(huì)首先檢查是否存在被JIT編譯過(guò)得版本，如果存在則使用此本地代碼來(lái)執(zhí)行；如果不存在，則將方法計(jì)數(shù)器+1，然后判斷“方法計(jì)數(shù)器和回邊計(jì)數(shù)器之和”是否超過(guò)閥值，如果是則會(huì)向編譯器提交一個(gè)方法編譯請(qǐng)求

   • 默認(rèn)情況下，執(zhí)行引擎并不會(huì)同步等待上面的編譯完成，而是會(huì)繼續(xù)解釋執(zhí)行。當(dāng)編譯完成后，此方法的調(diào)用入口地址會(huì)被系統(tǒng)自動(dòng)改寫(xiě)為新的本地代碼地址

   • 還有一點(diǎn)，熱度是會(huì)衰減的，也就是說(shuō)不是僅僅+，也會(huì)-，熱度衰減動(dòng)作是在虛擬機(jī)的GC執(zhí)行時(shí)順便進(jìn)行的

2. 回邊計(jì)數(shù)器

   • 回邊，顧名思義，只有執(zhí)行到大括號(hào)”}”時(shí)才算+1

   • 默認(rèn)閥值，Client下13995，Server下10700

   • 它的調(diào)用邏輯和方法計(jì)數(shù)器差不多，只不過(guò)遇到回邊指令時(shí)+1、超過(guò)閥值時(shí)會(huì)提交OSR編譯請(qǐng)求以及這里沒(méi)有熱度衰減

5. 編譯過(guò)程

編譯過(guò)程是在后臺(tái)線程（daemon）中完成的，可以通過(guò)參數(shù)“-XX:-BackgroundCompilation”來(lái)禁止后臺(tái)編譯，但此時(shí)執(zhí)行線程就會(huì)同步等待編譯完成才會(huì)執(zhí)行程序

1. Client Compiler 
   C1編譯器是一個(gè)簡(jiǎn)單快速的三段式編譯器，主要關(guān)注“局部性能優(yōu)化”，放棄許多耗時(shí)較長(zhǎng)的全局優(yōu)化手段 
   過(guò)程：class -> 1. 高級(jí)中間代碼 -> 2. 低級(jí)中間代碼 -> 3. 機(jī)器代碼
2. Server Compiler 
   C2是專(zhuān)門(mén)面向服務(wù)器應(yīng)用的編譯器，是一個(gè)充分優(yōu)化過(guò)的高級(jí)編譯器，幾乎能達(dá)到GNU C++編譯器使用-O2參數(shù)時(shí)的優(yōu)化強(qiáng)度。

使用參數(shù)“-XX:+PrintCompilation”會(huì)讓虛擬機(jī)在JIT時(shí)把方法名稱打印出來(lái)，如圖： 

6. Java和C/C++的編譯器對(duì)比

這里不是比Java和C/C++誰(shuí)快這種大坑問(wèn)題，只是比較編譯器（我認(rèn)為開(kāi)發(fā)效率上Java快，執(zhí)行效率上C/C++快）

這種對(duì)比代表了經(jīng)典的即時(shí)編譯器與靜態(tài)編譯期的對(duì)比，其實(shí)總體來(lái)說(shuō)Java編譯器有優(yōu)有劣。主要就是動(dòng)態(tài)編譯時(shí)間壓力大能做的優(yōu)化少，還要做一些動(dòng)態(tài)校驗(yàn)。而靜態(tài)編譯器無(wú)法實(shí)現(xiàn)一些開(kāi)發(fā)上很有用的動(dòng)態(tài)特性