在這個系列的第二部分，我來介紹一下HotSpot JVM提供的不同類別的參數。我同樣會討論一些關于JIT編譯器診斷的有趣參數。 JVM 參數分類 HotSpot JVM 提供了三類參數。第一類包括了標準參數。顧名思義，標準參數中包括功能和輸出的參數都是很穩定的，很可能在將來的JVM版本中不會改變。你可以用java命令（或者是用 java -help）檢索出所有標準參數。我們在第一部分中已經見到過一些標準參數，例如：-server。 第二類是X參數，非標準化的參數在將來的版本中可能會改變。所有的這類參數都以-X開始，并且可以用java -X來檢索。注意，不能保證所有參數都可以被檢索出來，其中就沒有-Xcomp。 第三類是包含XX參數（到目前為止最多的），它們同樣不是標準的，甚至很長一段時間內不被列出來（最近，這種情況有改變 ，我們將在本系列的第三部分中討論它們）。然而，在實際情況中X參數和XX參數并沒有什么不同。X參數的功能是十分穩定的，然而很多XX參數仍在實驗當中（主要是JVM的開發者用于debugging和調優JVM自身的實現）。值的一讀的介紹非標準參數的文檔 HotSpot JVM documentation，其中明確的指出XX參數不應該在不了解的情況下使用。這是真的，并且我認為這個建議同樣適用于X參數（同樣一些標準參數也是）。不管類別是什么，在使用參數之前應該先了解它可能產生的影響。 用一句話來說明XX參數的語法。所有的XX參數都以”-XX:”開始，但是隨后的語法不同，取決于參數的類型。 對于布爾類型的參數，我們有”+”或”-“，然后才設置JVM選項的實際名稱。例如，-XX:+<name>用于激活<name>選項，而-XX:-<name>用于注銷選項。 對于需要非布爾值的參數，如string或者integer，我們先寫參數的名稱，后面加上”=”，最后賦值。例如， -XX:<name>=<value>給<name>賦值<value>。 現在讓我們來看看JIT編譯方面的一些XX參數。 -XX:+PrintCompilation and -XX:+CITime 當一個Java應用運行時，非常容易查看JIT編譯工作。通過設置-XX:+PrintCompilation，我們可以簡單的輸出一些關于從字節碼轉化成本地代碼的編譯過程。我們來看一個服務端VM運行的例子： $ java -server -XX:+PrintCompilation Benchmark 1 java.lang.String::hashCode (64 bytes) 2 java.lang.AbstractStringBuilder::stringSizeOfInt (21 bytes) 3 java.lang.Integer::getChars (131 bytes) 4 java.lang.Object::<init> (1 bytes) --- n java.lang.System::arraycopy (static) 5 java.util.HashMap::indexFor (6 bytes) 6 java.lang.Math::min (11 bytes) 7 java.lang.String::getChars (66 bytes) 8 java.lang.AbstractStringBuilder::append (60 bytes) 9 java.lang.String::<init> (72 bytes) 10 java.util.Arrays::copyOfRange (63 bytes) 11 java.lang.StringBuilder::append (8 bytes) 12 java.lang.AbstractStringBuilder::<init> (12 bytes) 13 java.lang.StringBuilder::toString (17 bytes) 14 java.lang.StringBuilder::<init> (18 bytes) 15 java.lang.StringBuilder::append (8 bytes) [...] 29 java.util.regex.Matcher::reset (83 bytes) 每當一個方法被編譯，就輸出一行-XX:+PrintCompilation。每行都包含順序號（唯一的編譯任務ID）和已編譯方法的名稱和大小。因此，順序號1，代表編譯String類中的hashCode方法到原生代碼的信息。根據方法的類型和編譯任務打印額外的信息。例如，本地的包裝方法前方會有”n”參數，像上面的System::arraycopy一樣。注意這樣的方法不會包含順序號和方法占用的大小，因為它不需要編譯為本地代碼。同樣可以看到被重復編譯的方法，例如StringBuilder::append順序號為11和15。輸出在順序號29時停止 ，這表明在這個Java應用運行時總共需要編譯29個方法。 沒有官方的文檔關于-XX:+PrintCompilation，但是這個描述是對于此參數比較好的。我推薦更深入學習一下。 JIT編譯器輸出幫助我們理解客戶端VM與服務端VM的一些區別。用服務端VM，我們的應用例子輸出了29行，同樣用客戶端VM，我們會得到55行。這看起來可能很怪，因為服務端VM應該比客戶端VM做了“更多”的編譯。然而，由于它們各自的默認設置，服務端VM在判斷方法是不是熱點和需不需要編譯時比客戶端VM觀察方法的時間更長。因此，在使用服務端VM時，一些潛在的方法會稍后編譯就不奇怪了。 通過另外設置-XX:+CITime，我們可以在JVM關閉時得到各種編譯的統計信息。讓我們看一下一個特定部分的統計： $ java -server -XX:+CITime Benchmark [...] Accumulated compiler times (for compiled methods only) ------------------------------------------------ Total compilation time : 0.178 s Standard compilation : 0.129 s, Average : 0.004 On stack replacement : 0.049 s, Average : 0.024 [...] 總共用了0.178s（在29個編譯任務上）。這些，”on stack replacement”占用了0.049s，即編譯的方法目前在堆棧上用去的時間。這種技術并不是簡單的實現性能顯示，實際上它是非常重要的。沒有”on stack replacement”，方法如果要執行很長時間（比如，它們包含了一個長時間運行的循環），它們運行時將不會被它們編譯過的副本替換。 再一次，客戶端VM與服務端VM的比較是非常有趣的。客戶端VM相應的數據表明，即使有55個方法被編譯了，但這些編譯總共用了只有0.021s。服務端VM做的編譯少但是用的時間卻比客戶端VM多。這個原因是，使用服務端VM在生成本地代碼時執行了更多的優化。 在本系列的第一部分，我們已經學了-Xint和-Xcomp參數。結合使用-XX:+PrintCompilation和-XX:+CITime，在這兩個情況下（校對者注，客戶端VM與服務端VM），我們能對JIT編譯器的行為有更好的了解。使用-Xint，-XX:+PrintCompilation在這兩種情況下會產生0行輸出。同樣的，使用-XX:+CITime時，證實在編譯上沒有花費時間。現在換用-Xcomp，輸出就完全不同了。在使用客戶端VM時會產生726行輸出，然后沒有更多的，這是因為每個相關的方法都被編譯了。使用服務端VM，我們甚至能得到993行輸出，這告訴我們更積極的優化被執行了。同樣，JVM 拆機(JVM teardown)時打印出的統計顯示了兩個VM的巨大不同。考慮服務端VM的運行： $ java -server -Xcomp -XX:+CITime Benchmark [...] Accumulated compiler times (for compiled methods only) ------------------------------------------------ Total compilation time : 1.567 s Standard compilation : 1.567 s, Average : 0.002 On stack replacement : 0.000 s, Average : -1.#IO [...] 使用-Xcomp編譯用了1.567s，這是使用默認設置（即，混合模式）的10倍。同樣，應用程序的運行速度要比用混合模式的慢。相比較之下，客戶端VM使用-Xcomp編譯726個方法只用了0.208s，甚至低于使用-Xcomp的服務端VM。 補充一點，這里沒有”on stack replacement”發生，因為每一個方法在第一次調用時被編譯了。損壞的輸出“Average: -1.#IO”（正確的是:0）再一次表明了，非標準化的輸出參數不是非常可靠。 -XX:+UnlockExperimentalVMOptions 有些時候當設置一個特定的JVM參數時，JVM會在輸出“Unrecognized VM option”后終止。如果發生了這種情況，你應該首先檢查你是否輸錯了參數。然而，如果參數輸入是正確的，并且JVM并不識別，你或許需要設置-XX:+UnlockExperimentalVMOptions 來解鎖參數。我不是非常清楚這個安全機制的作用，但我猜想這個參數如果不正確使用可能會對JVM的穩定性有影響（例如，他們可能會過多的寫入debug輸出的一些日志文件）。 有一些參數只是在JVM開發時用，并不實際用于Java應用。如果一個參數不能被 -XX:+UnlockExperimentalVMOptions 開啟，但是你真的需要使用它，此時你可以嘗試使用debug版本的JVM。對于Java 6 HotSpot JVM你可以從這里找到。 -XX:+LogCompilation and -XX:+PrintOptoAssembly 如果你在一個場景中發現使用 -XX:+PrintCompilation，不能夠給你足夠詳細的信息，你可以使用 -XX:+LogCompilation把擴展的編譯輸出寫到“hotspot.log”文件中。除了編譯方法的很多細節之外，你也可以看到編譯器線程啟動的任務。注意-XX:+LogCompilation 需要使用-XX:+UnlockExperimentalVMOptions來解鎖。 JVM甚至允許我們看到從字節碼編譯生成到本地代碼。使用-XX:+PrintOptoAssembly，由編譯器線程生成的本地代碼被輸出并寫到“hotspot.log”文件中。使用這個參數要求運行的服務端VM是debug版本。我們可以研究-XX:+PrintOptoAssembly的輸出，以至于了解JVM實際執行什么樣的優化，例如，關于死代碼的消除。一個非常有趣的文章提供了一個例子。