作者：?PATRICK PESCHLOW? ? ?原文地址? ? 譯者：趙峰 校對：許巧輝

在這個系列的第二部分，我來介紹一下HotSpot JVM提供的不同類別的參數(shù)。我同樣會討論一些關(guān)于JIT編譯器診斷的有趣參數(shù)。

JVM 參數(shù)分類

HotSpot JVM 提供了三類參數(shù)。第一類包括了標(biāo)準(zhǔn)參數(shù)。顧名思義，標(biāo)準(zhǔn)參數(shù)中包括功能和輸出的參數(shù)都是很穩(wěn)定的，很可能在將來的JVM版本中不會改變。你可以用java命令（或者是用 java -help）檢索出所有標(biāo)準(zhǔn)參數(shù)。我們在第一部分中已經(jīng)見到過一些標(biāo)準(zhǔn)參數(shù)，例如：-server。

第二類是X參數(shù)，非標(biāo)準(zhǔn)化的參數(shù)在將來的版本中可能會改變。所有的這類參數(shù)都以-X開始，并且可以用java -X來檢索。注意，不能保證所有參數(shù)都可以被檢索出來，其中就沒有-Xcomp。

第三類是包含XX參數(shù)（到目前為止最多的），它們同樣不是標(biāo)準(zhǔn)的，甚至很長一段時間內(nèi)不被列出來（最近，這種情況有改變 ，我們將在本系列的第三部分中討論它們）。然而，在實際情況中X參數(shù)和XX參數(shù)并沒有什么不同。X參數(shù)的功能是十分穩(wěn)定的，然而很多XX參數(shù)仍在實驗當(dāng)中（主要是JVM的開發(fā)者用于debugging和調(diào)優(yōu)JVM自身的實現(xiàn)）。值的一讀的介紹非標(biāo)準(zhǔn)參數(shù)的文檔?HotSpot JVM documentation，其中明確的指出XX參數(shù)不應(yīng)該在不了解的情況下使用。這是真的，并且我認為這個建議同樣適用于X參數(shù)（同樣一些標(biāo)準(zhǔn)參數(shù)也是）。不管類別是什么，在使用參數(shù)之前應(yīng)該先了解它可能產(chǎn)生的影響。

用一句話來說明XX參數(shù)的語法。所有的XX參數(shù)都以”-XX:”開始，但是隨后的語法不同，取決于參數(shù)的類型。

• 對于布爾類型的參數(shù)，我們有”+”或”-“，然后才設(shè)置JVM選項的實際名稱。例如，-XX:+<name>用于激活<name>選項，而-XX:-<name>用于注銷選項。
• 對于需要非布爾值的參數(shù)，如string或者integer，我們先寫參數(shù)的名稱，后面加上”=”，最后賦值。例如， ?-XX:<name>=<value>給<name>賦值<value>。

現(xiàn)在讓我們來看看JIT編譯方面的一些XX參數(shù)。

-XX:+PrintCompilation and -XX:+CITime

當(dāng)一個Java應(yīng)用運行時，非常容易查看JIT編譯工作。通過設(shè)置-XX:+PrintCompilation，我們可以簡單的輸出一些關(guān)于從字節(jié)碼轉(zhuǎn)化成本地代碼的編譯過程。我們來看一個服務(wù)端VM運行的例子：

$ java -server -XX:+PrintCompilation Benchmark1 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)

每當(dāng)一個方法被編譯，就輸出一行-XX:+PrintCompilation。每行都包含順序號（唯一的編譯任務(wù)ID）和已編譯方法的名稱和大小。因此，順序號1，代表編譯String類中的hashCode方法到原生代碼的信息。根據(jù)方法的類型和編譯任務(wù)打印額外的信息。例如，本地的包裝方法前方會有”n”參數(shù)，像上面的System::arraycopy一樣。注意這樣的方法不會包含順序號和方法占用的大小，因為它不需要編譯為本地代碼。同樣可以看到被重復(fù)編譯的方法，例如StringBuilder::append順序號為11和15。輸出在順序號29時停止 ，這表明在這個Java應(yīng)用運行時總共需要編譯29個方法。

沒有官方的文檔關(guān)于-XX:+PrintCompilation，但是這個描述是對于此參數(shù)比較好的。我推薦更深入學(xué)習(xí)一下。

JIT編譯器輸出幫助我們理解客戶端VM與服務(wù)端VM的一些區(qū)別。用服務(wù)端VM，我們的應(yīng)用例子輸出了29行，同樣用客戶端VM，我們會得到55行。這看起來可能很怪，因為服務(wù)端VM應(yīng)該比客戶端VM做了“更多”的編譯。然而，由于它們各自的默認設(shè)置，服務(wù)端VM在判斷方法是不是熱點和需不需要編譯時比客戶端VM觀察方法的時間更長。因此，在使用服務(wù)端VM時，一些潛在的方法會稍后編譯就不奇怪了。

通過另外設(shè)置-XX:+CITime，我們可以在JVM關(guān)閉時得到各種編譯的統(tǒng)計信息。讓我們看一下一個特定部分的統(tǒng)計：

$ java -server -XX:+CITime Benchmark [...] Accumulated compiler times (for compiled methods only) ------------------------------------------------Total compilation time : 0.178 sStandard compilation : 0.129 s, Average : 0.004On stack replacement : 0.049 s, Average : 0.024 [...]

總共用了0.178s（在29個編譯任務(wù)上）。這些，”on stack replacement”占用了0.049s，即編譯的方法目前在堆棧上用去的時間。這種技術(shù)并不是簡單的實現(xiàn)性能顯示，實際上它是非常重要的。沒有”on stack replacement”，方法如果要執(zhí)行很長時間（比如，它們包含了一個長時間運行的循環(huán)），它們運行時將不會被它們編譯過的副本替換。

再一次，客戶端VM與服務(wù)端VM的比較是非常有趣的。客戶端VM相應(yīng)的數(shù)據(jù)表明，即使有55個方法被編譯了，但這些編譯總共用了只有0.021s。服務(wù)端VM做的編譯少但是用的時間卻比客戶端VM多。這個原因是，使用服務(wù)端VM在生成本地代碼時執(zhí)行了更多的優(yōu)化。

在本系列的第一部分，我們已經(jīng)學(xué)了-Xint和-Xcomp參數(shù)。結(jié)合使用-XX:+PrintCompilation和-XX:+CITime，在這兩個情況下（校對者注，客戶端VM與服務(wù)端VM），我們能對JIT編譯器的行為有更好的了解。使用-Xint，-XX:+PrintCompilation在這兩種情況下會產(chǎn)生0行輸出。同樣的，使用-XX:+CITime時，證實在編譯上沒有花費時間。現(xiàn)在換用-Xcomp，輸出就完全不同了。在使用客戶端VM時會產(chǎn)生726行輸出，然后沒有更多的，這是因為每個相關(guān)的方法都被編譯了。使用服務(wù)端VM，我們甚至能得到993行輸出，這告訴我們更積極的優(yōu)化被執(zhí)行了。同樣，JVM 拆機(JVM teardown)時打印出的統(tǒng)計顯示了兩個VM的巨大不同。考慮服務(wù)端VM的運行：

$ java -server -Xcomp -XX:+CITime Benchmark [...] Accumulated compiler times (for compiled methods only) ------------------------------------------------Total compilation time : 1.567 sStandard compilation : 1.567 s, Average : 0.002On stack replacement : 0.000 s, Average : -1.#IO [...]

使用-Xcomp編譯用了1.567s，這是使用默認設(shè)置（即，混合模式）的10倍。同樣，應(yīng)用程序的運行速度要比用混合模式的慢。相比較之下，客戶端VM使用-Xcomp編譯726個方法只用了0.208s，甚至低于使用-Xcomp的服務(wù)端VM。

補充一點，這里沒有”on stack replacement”發(fā)生，因為每一個方法在第一次調(diào)用時被編譯了。損壞的輸出“Average: -1.#IO”（正確的是:0）再一次表明了，非標(biāo)準(zhǔn)化的輸出參數(shù)不是非常可靠。

-XX:+UnlockExperimentalVMOptions

有些時候當(dāng)設(shè)置一個特定的JVM參數(shù)時，JVM會在輸出“Unrecognized VM option”后終止。如果發(fā)生了這種情況，你應(yīng)該首先檢查你是否輸錯了參數(shù)。然而，如果參數(shù)輸入是正確的，并且JVM并不識別，你或許需要設(shè)置-XX:+UnlockExperimentalVMOptions 來解鎖參數(shù)。我不是非常清楚這個安全機制的作用，但我猜想這個參數(shù)如果不正確使用可能會對JVM的穩(wěn)定性有影響（例如，他們可能會過多的寫入debug輸出的一些日志文件）。

有一些參數(shù)只是在JVM開發(fā)時用，并不實際用于Java應(yīng)用。如果一個參數(shù)不能被?-XX:+UnlockExperimentalVMOptions 開啟，但是你真的需要使用它，此時你可以嘗試使用debug版本的JVM。對于Java 6 HotSpot JVM你可以從這里找到。

-XX:+LogCompilation and -XX:+PrintOptoAssembly

如果你在一個場景中發(fā)現(xiàn)使用?-XX:+PrintCompilation，不能夠給你足夠詳細的信息，你可以使用?-XX:+LogCompilation把擴展的編譯輸出寫到“hotspot.log”文件中。除了編譯方法的很多細節(jié)之外，你也可以看到編譯器線程啟動的任務(wù)。注意-XX:+LogCompilation?需要使用-XX:+UnlockExperimentalVMOptions來解鎖。

JVM甚至允許我們看到從字節(jié)碼編譯生成到本地代碼。使用-XX:+PrintOptoAssembly，由編譯器線程生成的本地代碼被輸出并寫到“hotspot.log”文件中。使用這個參數(shù)要求運行的服務(wù)端VM是debug版本。我們可以研究-XX:+PrintOptoAssembly的輸出，以至于了解JVM實際執(zhí)行什么樣的優(yōu)化，例如，關(guān)于死代碼的消除。一個非常有趣的文章提供了一個例子。

關(guān)于XX參數(shù)的更多信息

如果這篇文章勾起了你的興趣，你可以自己看一下HotSpot JVM的XX 參數(shù)。這里是一個很好的起點。

原創(chuàng)文章，轉(zhuǎn)載請注明：?轉(zhuǎn)載自并發(fā)編程網(wǎng) – ifeve.com本文鏈接地址:?JVM實用參數(shù)（二）參數(shù)分類和即時（JIT）編譯器診斷

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的JVM实用参数（二）参数分类和即时（JIT）编译器诊断的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。