原文：https://insistence.cnblogs.com/p/5901457.html

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

Hot Spot 編譯

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

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

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

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

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

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

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

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

2. 編譯器與解釋器

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

2.1 配合過程

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

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

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

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

2.3 編譯器 - Compiler

只說HotSpot JVM

1. C1和C2：

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

2. 使用C1還是C2台盯？

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

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

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

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

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

   
   
   這里寫圖片描述

重要：↓

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

3. 分層編譯

3.1 為什么要分層編譯施绎？

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

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

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

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

• 第0層遇八，程序解釋執(zhí)行（沒有編譯）矛绘，解釋器不開啟性能監(jiān)控功能，可觸發(fā)第1層編譯刃永。

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

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