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