看了這篇【JIT編譯器】，你也能說你會java性能優化了！

你們好，我是小菜，一個渴望在互聯網行業作到蔡不菜的小菜。可柔可剛，點贊則柔，白嫖則剛！
死鬼~看完記得給我來個三連哦！

本文主要介紹 java性能分析 之 JIT編譯器
若有須要，能夠參考
若有幫助，不忘 點贊 ❥

創做不易，白嫖無義！

參考書籍：《Java性能權威指南》

做爲Java開發人員，也許在工做中最常常用到的只是 CRUD，解決性能問題 也許不常常接觸到，可是也是須要了解一二的！這篇文章小菜帶你一塊兒探究 Java性能優化之JIT編譯器。

文章大綱

前情概覽

即時 JIT（JUst-In-Time）編譯器是Java虛擬機的核心，對 JVM性能 影響最大的也就是編譯器。

CPU 是計算機的核心，到時只能執行相對少並且特定的指令，例如彙編碼和二進制碼 ，所以 CPU 所執行的程序都必須翻譯成這種指令。

語言結構

• 編譯型語言：會編譯成二進制形式 交付，先寫程序，而後用編譯器靜態生成二進制文件。
• 解釋型語言：只要機器上有合適的解釋器，相同的程序代碼能夠在任何 CPU 上執行，執行程序時，解釋器會將相應代碼轉換爲二進制代碼。

Java試圖走一條中間路線，Java應用會被編譯——但不是編譯成特定 CPU 所專用的二進制編碼，而是被編譯成一種理想化的彙編語言。而後該彙編語言（Java字節碼）能夠用Java運行。所以 Java 是一門 平臺獨立性的解釋型語言。

熱點編譯

JVM 執行代碼時，只會編譯常常被調用的。所以被編譯的代碼須要具有如下特性：

• 代碼是常常被調用的代碼
• 運行不少次迭代的循環

而這些關鍵代碼段被稱爲應用的熱點，代碼執行得越多就被認爲是越熱的。所以編譯器會先解釋執行代碼，而後找出哪一個方法被調用的足夠頻繁，才進行編譯。這也是爲了優化：JVM 執行特定方法或者循環的次數越多，它就會越瞭解這段代碼，這樣可使 JVM 在編譯代碼時進行大量優化。

小結

• Java的設計結合了腳本語言的平臺獨立性和編譯型語言的本地性能
• Java文件被編譯成中間語言（Java字節碼），而後在運行時被JVM進一步編譯成彙編語言
• 字節碼編譯成彙編語言的過程當中有大量的優化，極大地改善了性能

調優入門

1、兩種 「口味」

• Client 編譯器
• Server編譯器

命令行上選擇編譯器類型則採用以上兩個名字：-client和-server。一般這兩個編譯器也稱爲 c1 編譯器（client編譯器） 和 c2 編譯器（server編譯器）

分層編譯器：分層編譯意味着必須使用 server 編譯器

關閉分層編譯： java -client -XX:+TieredCompilation other_args

二者的主要區別：

在於編譯代碼的時機不一樣。client編譯器開啓編譯比server編譯器要早。這意味着；在代碼執行的開始階段，client編譯器比server編譯器要快，由於他編譯代碼相比server編譯器而言要多。

問題來了：

JVM 能不能在啓動的時候用 client 編譯器，而後隨着代碼變熱使用 server 編譯器？

方案：

分層編譯：代碼先由 client 編譯器編譯，隨着代碼變熱， 由 server 編譯器從新編譯。在 Java 1.8 中，分層編譯是默認開啓的。

2、優化啓動

當快速啓動時間是首要目標時了，最常使用 client 編譯器。

當總體性能比啓動性能更重要時，更適合使用 server 編譯器。

小結:

1. 若是應用的啓動時間是首要的性能考量，那 client 編譯器就是最有用的。
2. 分層編譯的啓動時間能夠很是接近於 client 編譯器所得到的啓動時間。

3、優化批處理

處理過程

歸根結底取決於哪一種編譯器使得應用運行的時間最優。

• 分層編譯是批處理任務合理的默認選擇
• 分層編譯是適合全部狀況的很好的備選方案
• 分層編譯老是比標準的 server 編譯器好一些
• 即使應用永遠運行，server 編譯器也不可能編譯它的全部代碼
• 對於計算量固定的任務來講，應該選擇實際執行任務最快的編譯器

4、優化長時間運行的應用

一般來講，在應用 「熱身」 以後，意味着它已經運行了足夠長的時間，重要的代碼都已經被編譯，這個時候即可以測試它處理的吞吐量。一個應用測試結果：

熱身期 (秒)	- client	- server	-XX:+TieredCompilation
0	15.87	23.72	24.23
60	16.00	23.73	24.26
300	16.85	24.42	24.43

相比單獨的 server 編譯器，分層編譯能夠編譯更多代碼，提供更多的性能。

對於長時間運行的應用來講，應該一直使用 server 編譯器，最好配合分層編譯。

編譯器中級調優

大多數狀況下，所謂編譯器調優，其實就只是爲目標機器上的 Java 選擇正確的 JVM和編譯器開關（-client -server -XX:+TieredCompilation）而已。分層編譯一般是長期運行應用的最佳選擇，而對於運行時間短的應用來講，分層編譯與 client 編譯器的性能差異也微乎其微。

1、代碼緩存

JVM 編譯代碼時，會在代碼緩存中保留編譯以後的彙編語言指令集。代碼緩存的大小固定，因此一旦填滿，JVM 就不能編譯更多代碼了。代碼緩存太小會致使只有部分熱點編譯，而應用的大部分代碼都只是解釋運行 —> 運行慢

代碼緩存填滿時，JVM會發出如下警告：

JAVA HotSpot(TM) 64-Bit Server VM warning:CodeCache is full
        Compiler has been disabled
JAVA HotSpot(TM) 64-Bit Server VM warning:Try increasing the
        code cache size using -XX:ReservedCodeCacheSize=
複製代碼

JVM 類型	代碼緩存的默認大小
32 位 client，Java 8	32 MB
32 位 server，分層編譯，Java 8	240 MB
64 位 server，分層編譯，Java 8	240 MB
32 位 client，Java 7	32 MB
32 位 server，Java 7	32 MB
64 位 server，Java 7	48 MB
64 位 server，分層編譯，Java 7	96 MB

設置代碼緩存最大值

-XX:ReservedCodeCacheSize=N

設置代碼緩存初始大小

-XX:InitialCodeCacheSize=N

小結

1. 代碼緩存是一種有最大值的資源，它會影響 JVM 可運行的編譯代碼總量。

2. 分層編譯很容易達到代碼緩存默認配置的上限（特別是在 Java 7）。使用分層編譯時，應該監控代碼緩存，必要時應該增長它的大小。

2、編譯閾值

編譯閾值和 代碼執行的頻度 有關，一旦代碼執行達到必定次數，而且達到了編譯閾值，編譯器就能夠得到足夠多的信息來進行代碼的編譯。

編譯是基於兩種 JVM 計數器

• 方法調用計數器
• 方法中的循環回邊計數器（回邊能夠看作是循環完成執行的次數，所謂循環完成執行，包括達到循環自身的末尾，也包括執行了像 continue 這樣的分支語句）

---

1. 標準編譯

JVM 執行了某個 Java 方法時，會檢查該方法的兩種計數器總數，而後斷定該方法是否適合編譯，若是適合，該方法就會進入編譯隊列。

更改編譯閾值

由-XX:CompileThreshold=N標誌觸發，使用 client 編譯器時，N 的默認值是 1500,使用 server 編譯器時，N 的默認值是 10 000，更改 CompileThreshold 將會使編譯器提升（或延遲）編譯。

問題：

若是循環很長或者永遠不會退出，怎麼計數？

這種狀況下，JVM 不等方法調用完成就會編譯循環，因此循環每完成一輪，回邊計數器就會增長並被檢測。

2. 棧上編譯 (OSR)

因爲僅僅編譯循環還不夠，JVM 必須在循環進行的時候還能編譯循環，在循環代碼編譯結束後，JVM 就會替換還在棧上的代碼，循環的下一次迭代就會執行快得多的編譯代碼。

---

實際上會出現有些重要的方法永遠不會被編譯。由於並非還沒達到編譯閾值，而是永遠都達不到編譯閾值！

這是由於雖然計數器隨着方法和循環的執行而增長，可是它們也會隨時間而減小。這種方法也稱爲 溫熱方法

小結：

1. 當方法和循環執行次數達到某個閾值的時候，就會發生編譯
2. 改變閾值會致使代碼提前或推後編譯
3. 因爲計數器會隨着時間而減小，以致於 "溫熱方法" 可能永遠都打不到編譯的閾值（特別是對 server 編譯器來講）

3、編譯過程

若是咱們想要看到編譯器是如何工做的，可使用 -XX:+PrintCompilation 命令來開啓，默認是 false

若是程序啓動時沒有開啓這個標誌，能夠用 jstat 瞭解編譯器內部的部分工做狀況。例如：jstat -compiler 25 或 jstat -printcompilation 25 1000

• -compiler：提供了關於多少方法被編譯的概要信息
• -printcompilation：獲取最近被編譯的方法
• 25：是被檢測進程的 ID
• 1000：每 1 秒（1000毫秒）輸出一次

小結：

1. 觀察代碼如何被編譯的最好方法是開啓 PrintCompilation
2. PrintCompilation 開啓後所輸出的信息可用來確認編譯是否和預期同樣

編譯器高級調優

1、編譯線程

當方法（或循環）適合編譯時，就會進入到編譯隊列。而後隊列中的任務則由一個或多個後臺線程處理，這意味着編譯過程是異步的。這樣的好處即是：即使代碼正在編譯的時候，程序也能持續執行。

若是是用標準編譯所編譯的方法，那下次調用該方法時就會執行編譯後的方法；若是是用OSR編譯的循環，那下次循環迭代時就會執行編譯後的代碼。

編譯隊列並不嚴格遵照先進先出的原則：調用計數次數多的方法有更高的優先級。因此即使在程序開始執行並有大量代碼須要編譯時，這樣的優先順序仍然有助於確保最重要的代碼優先編譯。

使用client編譯器時，JVM會開啓一個編譯線程；使用server編譯器時，則會開啓兩個線程。而分層編譯器則是一個略複雜的等式而定，以下：

CPU數量	C1的線程數	C2的線程數
1	1	1
2	1	1
4	1	1
8	1	2
16	2	6
32	3	7
64	4	8
128	4	10

小結：

1. 放置在編譯隊列中的方法的編譯會被異步執行。
2. 隊列並非嚴格按照前後順序的；隊列中的熱點方法會在其餘方法以前編譯，這是編譯輸出日誌中的 ID 爲亂序的另外一個緣由。

2、內聯 可好？

有了解過final的小夥伴應該都知道被final修飾的方法，編譯時JVM會嘗試找與其內聯的方法。這是由於編譯器所作的最重要的優化是方法內聯。內聯默認是開啓的。能夠經過-XX:-Inline關閉。

若是你從源代碼編譯 JVM，那能夠用 -XX:+PrintInling生成帶調試信息的版本。方法是否 內聯 取決於它有多熱以及它的大小。JVM 依據內部計算來斷定方法是否熱點（譬如：調用很頻繁）；是不是熱點並不直接與任何調優參數相關。

小結：

1. 內聯是編譯器所能作的最有利的優化，特別是對屬性封裝良好的面向對象的代碼來講。
2. 幾乎用不着調節內聯參數，且提倡這樣作的建議每每忽略了常規內聯和頻繁調用內聯之間的關係。當考察內聯效應時，確保考慮這兩種狀況。

3、逃逸分析

咱們能夠經過-XX:+DoEscapeAnalysis來開啓逃逸分析，默認是true。逃逸分析能夠決定哪些優化是可能的，並決定編譯後的代碼中哪些是必要的改變。

逃逸分析默認開啓，極少數狀況下，它會出錯。在此類狀況下關閉它會變得更快或更穩定。若是你發現了這種狀況，最好的應對行爲就是簡化相關代碼：代碼越簡單越好。

小結：

1. 逃逸分析是編譯器能作得最複雜的優化，此類優化經常會致使微基準測試失敗。
2. 逃逸分析經常會給不正確的同步代碼引入 bug。

何爲逆優化

逆優化意味着編譯器不得不 「撤銷」 以前的某些編譯；結果是應用的性能下降——至少是直到編譯器從新編譯相應代碼爲止。有兩種逆優化的情形：

• 代碼被丟棄（made not entrant）
• 產生殭屍代碼（made zombie）

1、代碼被丟棄了？

有兩種緣由致使代碼被丟棄

• 與類與接口的工做方式有關
• 與分層編譯的細節有關

當server編譯器編譯好代碼以後，JVM 必須替換 client 編譯器所編譯的代碼。它會將老弟阿瑪標記爲廢棄。也用一樣的方法替換新編譯（和更有效）的代碼。

2、「殭屍」 代碼出現

何爲殭屍代碼：當編譯後的代碼，由於後續沒有用到而被GC回收，所有回收以後，編譯器就會注意到，這些代碼如今適合標記爲殭屍代碼了。

從性能角度上看，這是好事。上面咱們提到過代碼緩存，編譯後的代碼會保存在大小固定的代碼緩存中。若是發現殭屍代碼，這意味着這些有問題的代碼能夠從代碼緩存中移除，騰出空間給其餘將被編譯的代碼（或者限制 JVM 以後須要分配的內存量）。

可能產生不足的是，若是代碼被殭屍化之後再次加載而且頻繁使用，JVM 就須要從新編譯和從新優化代碼，那麼這將會影響到性能。

---

小結：

1. 逆優化使得編譯器能夠回到以前版本的編譯代碼
2. 先前的優化再也不有效時（例如，所涉及到的對象類型發生了更改），纔會發生代碼逆優化。
3. 代碼逆優化時，會對性能產生一些小而短暫的影響，不過新編譯的代碼會盡快地再次熱身。
4. 分層編譯時，若是代碼以前由 client 編譯器編譯而如今 server 編譯器優化，就會發生逆優化。

分層編譯級別

程序使用分層編譯時，編譯日誌會輸出所編譯的分層級別。

其中 client 編譯器有 3 種級別，server 編譯器有 2 種編譯級別，所以，編譯級別有如下幾種：

• 0：解釋代碼
• 1：簡單 C1 編譯代碼
• 2：受限的 C1 編譯代碼
• 3：徹底 C1 編譯代碼
• 4：C2 編譯代碼

多數方法第一次編譯的級別是3 ，即徹底 C1 編譯（不過全部方法都從級別0開始）。若是方法運行得足夠頻繁，它就會編譯成級別4（級別3的代碼就會被丟棄）。

若是 server 編譯器隊列滿了，就會從 server 隊列中取出方法， 以級別2進行編譯，在這個級別中，C1編譯器使用方法調用計數器和回邊計數器。這會讓方法編譯得更快，而方法也將在 C1 編譯器收集分析信息以後被編譯爲級別3，最終當 server 編譯器隊列不太忙的時候被編譯爲級別4。

小結：

1. 分層編譯能夠在兩種編譯器和 5 種級別之間進行。
2. 不建議人爲更改級別。

小菜與你小結

1. 不用擔憂小方法，特別是getter和setter，由於它們很容易內聯。
2. 須要編譯的代碼在編譯隊列中，隊列中的代碼越多，程序達到最佳性能的時間越久。
3. 雖然代碼緩存的大小能夠（也應該）調整，但它仍然是有限的資源。
4. 代碼越簡單，優化越多，分析反饋和逃逸分析可使代碼更快，但複雜的循環結構和大方法限制了它的有效性。

看完不讚，都是壞蛋

本文較長，能看到這裏的都是最棒的！成長之路學無止境~
今天的你多努力一點，明天的你就能少說一句求人的話！
好久好久以前，有個傳說，聽說：
看完不讚，都是壞蛋