上篇是分析了一下前段編譯器，主要過程完成從java代碼到字節碼的轉變，它的改進頂多是提高程序的編碼速度和效率。本篇嘗試探索JIT編譯器，它能夠完成從字節碼到本地機器碼的轉變，從而真正的影響程序的運行效率。

概念

部分商用虛擬機，程序最初是通過解釋器（Interpreter）進行解釋執行，當發現某個部分代碼頻繁執行的時候，就會將這些代碼認定為「熱點代碼」（即 Hot Spot Code）。為了提高熱點代碼的執行效率，在運行時，虛擬機會把這些代碼編譯成與本地平臺相關的機器碼，并進行各種優化，完成這個任務的編譯器成為即時編譯器（Just In Time Compiler，簡稱JIT編譯器）。（下文所指均為JIT）關于即時編譯器需要知道的幾點：

• 它并不是VM必需的部分，java虛擬機規范并沒有規定它必須存在，所以也沒限定如何去實現。
• 即時編譯器編譯性能的好壞、代碼優化程度高低是衡量商用虛擬機優秀與否最關鍵指標之一。

Hotspot VM的JIT編譯器

解釋器和編譯器

不是所有Java虛擬機均采用二者并存的架構，但是一些主流商用虛擬機如Hotspot、J9都會同時包含二者。關于二者的優勢如下：

程序剛啟動和執行的時候，解釋器可以首先發揮作用，省去編譯的時間，立即執行字節碼。

程序運行之后，經過一段時間，編譯器可以逐漸發揮作用，把更多的代碼編譯為本地機器碼，獲得更高的執行效率。

在整個虛擬機執行架構中，解釋器和編譯器經常配合工作，如下圖所示：

上圖中內置了兩個JIT編譯器，分別稱Client Compiler和Server Compiler，簡稱為C1編譯器和C2編譯器。目前主流的Hotspot VM（jdk1.7及以前版本虛擬機），默認采用與其中一個編譯器直接配合，程序用哪個，取決于虛擬機運行模式，用戶可以使用-client和-server參數強制指定虛擬機運行在client和server模式。
另外，通過下圖的三種命令可以強制虛擬機運行的模式，分別為：Mixed Mode（混合模式，默認情況下解釋器和編譯器搭配使用）、Interpreter Mode（解釋模式）、Compiled Mode（編譯模式）。

了解完解釋器和編譯器之后，我們想知道那些代碼會被編譯？在什么情況下會觸發編譯？基于這兩個問題，來了解編譯對象和觸發條件。

編譯對象

在運行過程中會被即時編譯器編譯的「熱點代碼」有兩類，如下：

• 被多次調用的方法
• 被多次執行的循環體

關于這兩種情況，有兩點解釋：對于第一種情況，是由方法調用觸發的編譯，理所當然的會以整個方法體作為編譯對象，這種編譯是虛擬機中標準的JIT編譯。對于第二種情況，編譯動作由循環體觸發，但是編譯器仍舊會以整個方法作為編譯對象，由于這種方法發生在方法執行過程中，所以稱為棧上替換（On Stack Replacement，簡稱OSR編譯，因為方法棧幀還在棧上）。

觸發條件

正如上面所說的“多次”并不夠嚴謹和具體，那么如何才算是“多次”呢？以及怎么樣去統計一個方法和一段代碼被執行多少次呢？回答了這兩個問題就是回答了觸發條件。判斷一段代碼是不是熱點代碼，是不是需要觸發即時編譯，這樣的行為叫「熱點探測」。關于熱點探測有兩種方式，如下：

• 基于采樣的熱點探測
  虛擬機會周期性檢查各個線程的棧頂，如果發現某些方法長期占據棧頂，那么會被認為是「熱點代碼」。簡單、高效，但是不夠精確，因為某些方法會因為線程阻塞或其他原因擾亂熱點探測。
• 基于計數器的熱點探測（Hotspot VM采用）
  虛擬機為每個方法或者代碼塊建立計數器，統計執行次數，超過一定閥值會被認為是「熱點代碼」。

Hotspot VM使用第二種，并且為每個方法準備了兩種計數器：方法調用計數器和回邊計數器（在字節碼中遇到控制流向后跳轉的指令稱為“回邊 ”）。在確定虛擬運行參數的情況下，這兩個計數器都有一個確定的閥值，超過這個閥值就會觸發JIT編譯。方法調用計數器觸發即時編譯的交互過程如下圖：

注意：方法調用計數器統計的并不是被調用的絕對次數，而是一個相對的執行頻率，即一段時間被被調用的次數。

編譯過程

在默認設置下，無論是方法調用產生的即時編譯請求，還是OSR編譯請求，虛擬機在代碼編譯還未完成之前，都仍然按照解釋方式執行，而編譯動作則在后臺編譯線程中進行。至于在后臺如何執行編譯過程，Client Compiler和Server Compiler的編譯過程是不同的。二者大致區別如下：

• Client Compiler：主要關注點在局部優化，而放棄了耗時較長的全局優化手段。
• Server Compiler：是專門面向服務器端的典型應用并為服務端的性能配置特別調整過。

從即時編譯的角度看，Server Compiler是比較慢，但其編譯速度又遠遠超過「靜態優化編譯器」，而且比Client Compiler輸出的代碼質量高，可以減少本地代碼執行時間，從而抵消額外的編譯時間。

編譯優化技術

之所以有編譯方式執行本地代碼比解釋方式更快這樣的共識，原因很簡單，是因為虛擬機設計團隊幾乎把對代碼所有的優化措施集中在了即時編譯器之中，因此一般來說，即時編譯器產生的本地代碼會比Javac產生的字節碼更優秀。常用優化技術如下：

公共子表達式消除

語言無關，比如像：b乘c、c乘b這樣的表達式值都是一樣的可以直接替換。

數組范圍消除

語言相關，主要思路就是盡可能把運行期檢查提任務前到編譯器進行，以至于在循環遍歷的時候不需要每次都要判斷變量大小是否超過數組范圍，帶來隱式開銷，只要在編譯期根據數據流獲得數組的length，并且判斷下標沒有越界，執行的時候就無需判斷了。

方法內聯

為了消除方法調用的成本，同時為其他優化手段建立好的基礎。因為很多方法分開看是有意義的，如果不做方法內聯，即使進行了無用代碼消除，也無法發現任何“Dead Code”。

逃逸分析

并不是直接的優化手段，而是為其他優化手段提供分析技術。逃逸分析的基本行為就是分析對象的作用域，比如一個對象在一個方法中被定義，可能被外部方法所引用，例如作為方法參數傳遞到其他方法中，這被稱為方法逃逸。甚至可能被其他線程訪問，例如賦值給類變量或其他線程訪問的實例變量，就是線程逃逸。

因此，如果能證明一個不會發生方法或者線程逃逸，則可以為這個變量進行一些高效優化。優化措施如下：

• 棧上分配
  將確定不會逃逸的對象在在棧幀上進行創建分配內存，這樣方法結束時，對象就會隨著棧幀出棧而銷毀，減少堆內存垃圾回收的壓力。
• 同步消除
  如果確定一個變量不會線程逃逸，也就說明該變量不會發生線程競爭，從而消除掉該變量的同步措施。
• 標量替換
  像java中的原始數據類型如int、long均稱為標量（表示無法分解為更小的數據來表示了），如果一個數據可以繼續分解，則為聚合量，而java中的對象則為典型的聚合量。如果一個對象不會被外部訪問，而這個對象可以被拆散分解，那么就不去創建這個對象，而是直接創建被使用到的成員變量。而這些成員變量除了被分配在棧上（棧上的數據很容易會被虛擬機分配到物理高速寄存器）進行讀和寫，還為后續優化創造基礎條件。

本篇主要了解解釋器和編譯器的特點和各自優勢、然后總結了編譯對象和編譯條件，最后介紹了編譯過程以及用到的一些主要的編譯優化技術，算是對即時編譯器有個基本的理解了。

from:http://zouzls.github.io/2016/09/07/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3JVM%E4%B9%8BJIT%E7%BC%96%E8%AF%91%E5%99%A8%EF%BC%88%E4%BA%8C%EF%BC%89/?

總結

以上是生活随笔為你收集整理的深入理解JVM之JIT编译器（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。