JVM 命令行標(biāo)志您不知道的5件事
JVM 是多數(shù)開(kāi)發(fā)人員視為理所當(dāng)然的 Java 功能和性能背后的重負(fù)荷機(jī)器。然而，我們很少有人能理解 JVM 是如何進(jìn)行工作的 — 像任務(wù)分配和垃圾收集、轉(zhuǎn)動(dòng)線程、打開(kāi)和關(guān)閉文件、中斷和/或 JIT 編譯 Java 字節(jié)碼，等等。不熟悉 JVM 將不僅會(huì)影響應(yīng)用程序性能，而且當(dāng) JVM 出問(wèn)題時(shí)，嘗試修復(fù)也會(huì)很困難。本文將介紹一些命令行標(biāo)志，您可以使用它們來(lái)診斷和調(diào)優(yōu)您的 Java 虛擬機(jī)性能。
1. DisableExplicitGC
我已記不清有多少次用戶要求我就應(yīng)用程序性能問(wèn)題提供咨詢了，其實(shí)只要跨代碼快速運(yùn)行 grep，就會(huì)發(fā)現(xiàn)清單 1 所示的問(wèn)題 — 原始 java 性能反模式：
清單 1. System.gc();
- // We just released a bunch of objects, so tell the stupid
- // garbage collector to collect them already!
- System.gc();
顯式垃圾收集是一個(gè)非常糟糕的主意 — 就像將您和一個(gè)瘋狂的斗牛犬鎖在一個(gè)電話亭里。盡管調(diào)用的語(yǔ)法是依賴實(shí)現(xiàn)的，但如果您的 JVM 正在運(yùn)行一個(gè)分代的垃圾回收器(大多數(shù)是)System.gc(); 強(qiáng)迫 VM 執(zhí)行一個(gè)堆的 “全部清掃”，雖然有的沒(méi)有必要。全部清掃比一個(gè)常規(guī) GC 操作要昂貴好幾個(gè)數(shù)量級(jí)，這只是個(gè)簡(jiǎn)單數(shù)學(xué)問(wèn)題。
您可以不把我的話放在心上 — Sun 的工程師為這個(gè)特殊的人工錯(cuò)誤提供一個(gè) JVM 標(biāo)志; -XX:+DisableExplicitGC 標(biāo)志自動(dòng)將 System.gc() 調(diào)用轉(zhuǎn)換成一個(gè)空操作，為您提供運(yùn)行代碼的機(jī)會(huì)，您自己看看 System.gc() 對(duì)于整個(gè) JVM 執(zhí)行有害還是有利。
2. HeapDumpOnOutOfMemoryError
您有沒(méi)有經(jīng)歷過(guò)這樣的情況：JVM 不能使用，不斷拋出 OutOfMemoryError，而您又不能為自己創(chuàng)建調(diào)試器來(lái)捕獲它或查看出現(xiàn)了什么問(wèn)題?像這類偶發(fā)和/或不確定的問(wèn)題，通常使開(kāi)發(fā)人員發(fā)瘋。
買者自負(fù)并不是任何 VM 都支持所有命令行標(biāo)志，Sun/Oracle 的 VM 除外。查明一個(gè)標(biāo)志是否被支持的最好方法是試用它，看它是否正常工作。倘若這些標(biāo)志在技術(shù)上是不支持的，那么，使用它們您要承擔(dān)全部責(zé)任。如果這些標(biāo)志中的任何一個(gè)使您的代碼、您的數(shù)據(jù)、您的服務(wù)器或您的一切消失得無(wú)影無(wú)蹤，我、Sun/Oracle 和 IBM® 都將不負(fù)責(zé)任。為以防萬(wàn)一，建議先在虛擬(非常生產(chǎn))環(huán)境中實(shí)驗(yàn)。
在這個(gè)時(shí)刻您想要的是，在 JVM 消亡之際捕獲堆的一個(gè)快照 — 正好 -XX:+HeapDumpOnOutOfMemoryError 命令可以完成這一操作。
運(yùn)行該命令通知 JVM 拍攝一個(gè) “堆轉(zhuǎn)儲(chǔ)快照”，并將其保存在一個(gè)文件中以便處理，通常使用 jhat 實(shí)用工具。您可以使用相應(yīng)的 -XX:HeapDumpPath 標(biāo)志指定到保存文件的實(shí)際路徑。(不管文件保存在哪，務(wù)必確保文件系統(tǒng)和/或 Java 流程必須要有權(quán)限配置，可以在其中寫入。)
3. bootclasspath
定期將一個(gè)類放入類路徑是很有幫助的，這類路徑與庫(kù)存 JRE 附帶的類路徑或者以某種方式擴(kuò)展的 JRE 類路徑略有不同。(新 Java Crypto API 提供商就是一個(gè)例子)。如果您想要擴(kuò)展 JRE ，那么您定制的實(shí)現(xiàn)必須可以使用引導(dǎo)程序 ClassLoader，該引導(dǎo)程序可以加載 rt.jar 中的 java.lang.Object 及其所有相關(guān)文件。
盡管您可以 非法打開(kāi) rt.jar 并將您的定制實(shí)現(xiàn)或新數(shù)據(jù)包移入其中，但從技術(shù)上您就違反了您下載 JDK 時(shí)同意的協(xié)議了。
相反，使用 JVM 自己的 -Xbootclasspath 選項(xiàng)，以及皮膚 -Xbootclasspath/p 和 -Xbootclasspath/a。
-Xbootclasspath 使您可以設(shè)置完整的引導(dǎo)類路徑(這通常包括一個(gè)對(duì) rt.jar 的引用)，以及一些其他 JDK 附帶的(不是 rt.jar 的一部分)JAR 文件。-Xbootclasspath/p 將值前置到現(xiàn)有 bootclasspath 中，并將 -Xbootclasspath/a 附加到其中。
例如，如果您修改了庫(kù)中的 java.lang.Integer，并將修改放在一個(gè)子路徑 mods 下，那么 -Xbootclasspath/a mods 參數(shù)將新 Integer 放在默認(rèn)的參數(shù)前面。
4. verbose
對(duì)于虛擬的或任何類型的 Java 應(yīng)用程序，-verbose 是一個(gè)很有用的一級(jí)診斷使用程序。該標(biāo)志有三個(gè)子標(biāo)志：gc、class 和 jni。
開(kāi)發(fā)人員嘗試尋找是否 JVM 垃圾收集器發(fā)生故障或者導(dǎo)致性能低下，通常首先要做的就是執(zhí)行 gc。不幸的是，解釋 gc 輸出很麻煩 — 足夠?qū)懸槐緯８愀獾氖牵诿钚兄写蛴〉妮敵鲈诓煌?Java 版本中或者不在不同的 JVM 中會(huì)發(fā)生改變，這使得正確解釋變得更難。
一般來(lái)說(shuō)，如果垃圾收集器是一個(gè)分代收集器(多數(shù) “企業(yè)級(jí)” VMs 都是)。某種虛擬標(biāo)志將會(huì)出現(xiàn)，來(lái)指出一個(gè)全部清掃 GC 通路;在 Sun JVM 中，標(biāo)志在 GC 輸出行的開(kāi)始以 “[Full GC ...]” 形式出現(xiàn)。
想要診斷 ClassLoader 和/或不匹配的類沖突，class 可以幫上大忙。它不僅報(bào)告類何時(shí)加載，還報(bào)告類從何處加載，包括到 JAR 的路徑(如果來(lái)自 JAR)。
jni 很少使用，除了使用 JNI 或本地庫(kù)時(shí)。打開(kāi)時(shí)，它將報(bào)告各種 JNI 事件，比如，本地庫(kù)何時(shí)加載，方法何時(shí)彈回;再一次強(qiáng)調(diào)，在不同 JVM 版本中，輸出會(huì)發(fā)生變化。
5. Command-line -X
我列出了 JVM 中提供的我喜歡的命令行選項(xiàng)，但是還有一些更多的需要您自己發(fā)現(xiàn)，運(yùn)行命令行參數(shù) -X，列出 JVM 提供的所有非標(biāo)準(zhǔn)(但大部分都是安全的)參數(shù) — 例如：
- -Xint，在解釋模式下運(yùn)行 JVM(對(duì)于測(cè)試 JIT 編譯器實(shí)際上是否對(duì)您的代碼起作用或者驗(yàn)證是否 JIT 編譯器中有一個(gè) bug，這都很有用)。
- -Xloggc:，和 -verbose:gc 做同樣的事，但是記錄一個(gè)文件而不輸出到命令行窗口。
JVM 命令行選項(xiàng)時(shí)常發(fā)生變化，因此，定期查看是一個(gè)好主意。甚至，您深夜盯著監(jiān)控器和下午 5 點(diǎn)回家和妻子孩子吃頓晚飯，(或者在 Mass Effect 2 中消滅您的敵人，根據(jù)您的喜好)，它們都是不一樣的。
結(jié)束語(yǔ)
在生產(chǎn)環(huán)境中，命令行標(biāo)志不是為永久使用而設(shè)計(jì)的 — 事實(shí)上，除了您終止用來(lái)調(diào)優(yōu) JVM 垃圾收集器的標(biāo)志，沒(méi)有一個(gè)非標(biāo)準(zhǔn)命令行標(biāo)記是專用于生產(chǎn)使用的。但是，作為工具來(lái)刺探在其他方面完全不透明的虛擬機(jī)的內(nèi)部工作，是非常有用的。
【編輯推薦】
