即時編譯器概述

• 編譯器在編譯過程中通常會考慮很多因素。比如：彙編指令的順序。假設我們要將兩個暫存器的值進行相加，執行這個操作一般只需要一個CPU週期；但是在相加之前需要將資料從記憶體讀到暫存器中，這個操作是需要多個CPU週期的。編譯器一般可以做到，先啟動資料載入操作，然後執行其它指令，等資料載入完成後，再執行相加操作。由於直譯器在解釋執行的過程中，每次只能看到一行程式碼，所以很難生成上述這樣的高效指令序列。而編譯器可以事先看到所有程式碼，因此，一般來說，解釋性程式碼比編譯性程式碼要慢。不過，解釋性程式碼具有可移植性的優勢。
• Java的實現在解釋性和編譯性之間進行了折中。Java程式碼是編譯性的，它會被編譯成一個平臺獨立的位元組碼程式。
  JVM負責載入、解釋、執行這些位元組碼程式，在這個過程中，還可能會將這些位元組碼實時編譯成目標機器碼，以便提升效能。
• 在本章中，我們主要關注JVM是如何解釋、執行、編譯位元組碼的。

編譯熱點程式碼

• JVM在解釋執行位元組碼的時候，不會立即對它進行編譯。主要原因有兩個：
  • 如果程式碼只執行一次，對程式碼進行編譯得不償失（編譯之後還要執行程式碼）。
  • 程式碼執行的次數越多，JVM可以獲取到的資訊就越多。JVM就可以在編譯程式碼的時候採用更多的優化手段。比如：JVM經常執行equals()方法，b = obj1.equals(obj2)。JVM需要根據obj1找到它的型別，然後才知道應該執行那個equals
    函式。這個過程是比較費時的，為了加快執行速度，編譯程式碼的時候可以將型別查詢的過程優化掉，直接執行String.equals(obj2)。不過，在實際程式碼中，可能不會這麼簡單，obj1的型別會發生變化。但是隻要程式碼執行次數夠多，優化後，效能就會有比較大的提升。

基本調優：Client或Server

• 即時編譯器有兩種型別，client和server。一般情況下，對編譯器進行優化，唯一要做的就是選擇那一類編譯器。
• 可以通過在啟動java的命令中，傳入引數(-client或-server)來選擇編譯器（C1或C2）。這兩種編譯器的最大區別就是，編譯程式碼的時間點不一樣。client編譯器（C1）會更早地對程式碼進行編譯，因此，在程式剛啟動的時候，
  client編譯器比server編譯器執行得更快。而server編譯器會收集更多的資訊，然後才對程式碼進行編譯優化，因此，server編譯器最終可以產生比client編譯器更優秀的程式碼。
• 可能大家都有一個困擾，JVM為什麼要將編譯器分為client和server，為什麼不在程式啟動時，使用client編譯器，在程式執行一段時間後，自動切換為server編譯器？其實，這種技術是存在的，一般稱之為： tiered compilation。Java7 和Java 8可以使用選項-XX:+TieredCompilation來開啟（-server選項也要開啟）。在Java 8中，-XX:+TieredCompilation預設是開啟的。

啟動優化

• 對於不同型別的應用，使用不同編譯器的啟動時間：

                  

可以看到，對於中等大小的GUI應用，使用client編譯器，啟動時間最短，有將近38.5%的提升。對於大型應用，使用各種編譯器的啟動時間差別不大。

批處理應用優化

• 下圖是對第2章中股票應用的效能測試結果，第1列是股票的個數：

                    

觀察上圖，可以得出以下結論：

1）當股票數比較少的時候（1~100），client編譯器完成的最快。

2）當股票數很多的時候，使用server編譯器就變得更快了。

3）tiered compilation總是比server編譯器要快（和client比，即使在股票數很少的情況下，效能相差也不大），這是因為，tieredcompilation會對一些執行次數較少的程式碼也進行編譯（編譯後比解釋執行要快）。

長時間執行的應用優化

• 還是利用第2章的例子，這次使用第2章提供的servlet，下圖是在不同“warm-up period”下（也就是重要的程式碼段都被編譯了）應用的吞吐量（每秒處理請求的數目）。

             

觀察上圖，可以得出以下結論：

        1）由於測試周期是60秒，所以，即使warm-upperiod是0s，server編譯器也有足夠的時間來發現熱點程式碼並進行編譯，所以，server編譯器總是比client編譯器的吞吐量要高。

        2）同樣的tiered compilation總是比server編譯器的吞吐量要高（原因見上文，批處理應用優化）。

Java和JIT編譯器版本

• JIT編譯器主要有以下3大類：
  • 32-bit的client版本(-client)
  • 32-bit的server版本(-server)
  • 64-bit的server版本(-d64)
• 那到底是選擇32bit版本還是64bit版本呢？是不是作業系統是64bit的就選擇64位版本呢？

答案並不是這樣的，而是需要根據情況確定。

使用32bit版本的優點主要有兩個：1）佔用記憶體少，因為對應引用都是32位的 2）效能高，因為CPU操作32位的記憶體引用要比操作64位的記憶體引用要快。缺點也有兩個：1）使用堆記憶體的大小不能超過4GB（windows為3GB，Linux為3.5GB） 2）程式中，如果使用了大量的long和double變數，不能充分使用64位暫存器，不過這種情況比較少見。

一般來說，32bitJVM上的32bit編譯器要比同樣配置的64bit編譯器要快5%~20%。

• 64bit版本的JVM無法使用32bit的編譯器
• 如果在64bitJVM啟動時，使用-client引數，JVM還是會使用server編譯器；如果在32-bitJVM啟動時，使用-server引數，則會報錯，提醒使用者，JVM不支援對應的編譯器。

上圖是對不同平臺下，使用不同引數對應的編譯器。

• 對於JAVA8來說，server編譯器是預設編譯器，tiered compilation也是預設開啟的。
• 對於不同平臺，如果沒有傳入-server或-client引數，則會使用預設的編譯器版本，具體如下圖所示：

編譯器的中間段優化

• 一般情況下，編譯器的優化就是選擇JVM啟動的引數；但是在以下情況還是要進行額外優化的。

CodeCache優化

• JVM在編譯程式碼的時候，會在CodeCache中儲存一些彙編指令。由於CodeCache的大小是固定，一旦它被填充滿了，JVM就無法編譯其它程式碼了。如果CodeCache很小，就會導致部分熱點程式碼沒有被編譯，應用的效能將會急劇下降（執行解釋性程式碼）。
• 如果JVM使用了client或tiered compilation編譯器，更可能會出現問題；因為它們會對很多類都進行編譯。當CodeCache滿了的時候，JVM會列印類似於下面的告警資訊：

Java HotSpot(TM) 64-Bit Server VM warning: CodeCacheis full.

Compiler has been disabled.

Java HotSpot(TM) 64-Bit Server VM warning: Tryincreasing the

code cache size using -XX:ReservedCodeCacheSize=

• 各個版本的JVM，CodeCache的預設大小，如下圖所示：

從上圖可以看到，Java7的CodeCache通常是不夠的，一般都需要進行加大。到底增大到多少，這個比較難給出精確值，一般是預設值的2倍或4倍。

• CodeCache的最大大小，可以通過 -XX:ReservedCodeCacheSize=N來指定，初始大小使用-XX:InitialCodeCacheSize=N來指定。有初始大小是會自動增加的，所以一般不需要設定-XX:InitialCodeCacheSize引數。
• 既然CodeCache大小會有最大值，我們是否可以設定一個很大的值呢？這個主要看系統資源是否足夠。對於32bit的JVM，由於虛擬記憶體總大小為4GB，所以這個值不能設定的太大；對於64bit的JVM，這個值的大小設定一般不受限制的。

編譯閾值

• 是否對程式碼進行編譯受兩個計數器的影響：1）方法的呼叫次數 2）方法內迴圈的次數。當JVM執行一個JAVA方法的時候，它都會檢查這兩個計數器，以便確定是否需要對方法進行編譯。
• 當JVM執行一個JAVA方法的時候，它會檢查這兩個計數器值的總和，然後確定這個方法是否需要進行編譯。如果需要進行編譯，這個方法會放入編譯佇列。這種編譯沒有官方的名字，一般稱之為標準編譯。
• 如果方法裡面是一個迴圈，雖然方法只調用一次，但是迴圈在不停執行。此時，JVM會對這個迴圈的程式碼進行編譯。這種編譯稱之為棧上替換OSR（on-stack replacement)。因為即使迴圈被編譯了，這還不夠，JVM還需要能夠在迴圈正在執行的時候，轉為執行編譯後的程式碼。JVM採用的方式就是將編譯後的程式碼替換當前正在執行的方法位元組碼。由於方法在棧上執行，所以這個操作又稱之為：棧上替換。
• 可以通過配置 -XX:CompileThreshold=N來確定計數器的閾值，從而控制編譯的條件。但是如果降低了這個值，會導致JVM沒有收集到足夠的資訊就進行了編譯，導致編譯的程式碼優化不夠（不過影響會比較小）。
• 如果-XX:CompileThreshold=N配置的兩個值（一個大，一個小）在效能測試方面表現差不多，那麼會推薦使用小一點的配置，主要有兩個原因：
  • 可以減小應用的warm-upperiod。
  • 可以防止某個方法永遠得不到編譯。這是因為JVM會週期（每到安全點的時候）的對計數進行遞減。如果閾值比較大，並且方法週期性呼叫的時間較長，導致計數永遠達不到這個閾值，從而不會進行編譯。

探尋編譯過程

• 選項-XX:+PrintCompilation可以開啟編譯日誌，當JVM對方法進行編譯的時候，都會列印一行資訊，什麼方法被編譯了。具體格式如下：

timestamp compilation_idattributes (tiered_level) method_name size deopt

• timestamp是編譯時相對於JVM啟動的時間戳
• compliation_id是內部編譯任務的ID，一般都是遞增的
• attributes由5個字母組成，用來顯示程式碼被編譯的狀態：
  • %：編譯是OSR
  • s：方法是synchronized的
  • !：方法有異常處理
  • b：編譯執行緒不是後臺執行的，而是同步的（當前版本的JVM應該不會列印這個狀態了）
  • n：表示JVM產生了一些輔助程式碼，以便呼叫native方法
• tiered_level：採用tiered compilation編譯器時才會列印。
• method_name：被編譯的方法名稱，格式是：classname::method
• size: 被編譯的程式碼大小（單位：位元組），這裡的程式碼是Java位元組碼。
• deopt：如果發生了去優化，這裡說明去優化的型別。（見下文的說明）

小技巧：使用jstat來檢視編譯器的行為

% jstat -compiler 5003

Compiled Failed Invalid Time FailedTypeFailedMethod

206 0 01.97 0

5003為JVM的程序

相關推薦