Java法式員必需曉得的5個JVM敕令行標記。本站提示廣大學習愛好者：（Java法式員必需曉得的5個JVM敕令行標記）文章只能為提供參考，不一定能成為您想要的結果。以下是Java法式員必需曉得的5個JVM敕令行標記正文
本文是Neward & Associates的總裁Ted Neward為developerworks獨家撰稿“你不曉得5個……”系列中的一篇，JVM是多半開辟人員視為天經地義的Java功效和機能面前的重負荷機械。但是，我們很少有人能懂得JVM是若何停止任務的—像義務分派和渣滓搜集、遷移轉變線程、翻開和封閉文件、中止和/或JIT編譯Java字節碼，等等。
不熟習JVM將不只會影呼應用法式機能，並且當JVM出成績時，測驗考試修復也會很艱苦。
本文將引見一些敕令行標記，您可使用它們來診斷和調優您的Java虛擬機機能。
1.DisableExplicitGC
我已記不清有若干次用戶請求我就運用法式機能成績供給征詢了，其實只需跨代碼疾速運轉grep，就會發明清單1所示的成績—原始Java機能反形式：
清單 1. System.gc();
// We just released a bunch of objects, so tell the stupid
// garbage collector to collect them already!
System.gc();
顯式渣滓搜集是一個異常蹩腳的主張——就像將您和一個猖狂的斗牛犬鎖在一個德律風亭裡。雖然挪用的語法是依附完成的，但假如您的JVM正在運轉一個分代的渣滓收受接管器（年夜多半是）System.gc();強制VM履行一個堆的“全體打掃”，固然有的沒有需要。全體打掃比一個慣例GC操作要昂貴好幾個數目級，這只是個簡略數學成績。
您可以不把我的話放在心上—Sun的工程師為這個特別的人工毛病供給一個JVM標記；-XX:+DisableExplicitGC標記主動將System.gc()挪用轉換成一個空操作，為您供給運轉代碼的機遇，您本身看看System.gc()關於全部JVM履行無害照樣有益。
2.HeapDumpOnOutOfMemoryError
您有無閱歷過如許的情形：JVM不克不及應用，赓續拋出OutOfMemoryError，而您又不克不及為本身創立調試器來捕捉它或檢查湧現了甚麼成績？像這類偶發和/或不肯定的成績，平日使開辟人員發狂。
買者自信
其實不是任何VM都支撐一切敕令行標記，Sun/Oracle的VM除外。查明一個標記能否被支撐的最好辦法是試用它，看它能否正常任務。倘使這些標記在技巧上是不支撐的，那末，應用它們您要承當全體義務。假如這些標記中的任何一個使您的代碼、您的數據、您的辦事器或您的一切消逝得無影無蹤，我、Sun/Oracle和IBM都將不擔任任。為以防萬一，建議先在虛擬（異常臨盆）情況中試驗。
在這個時辰您想要的是，在JVM滅亡之際捕捉堆的一個快照——正好-XX:+HeapDumpOnOutOfMemoryError敕令可以完成這一操作。
運轉該敕令告訴JVM拍攝一個“堆轉儲快照”，並將其保留在一個文件中以便處置，平日應用jhat適用對象（我在上一篇文章中引見過）。您可使用響應的-XX:HeapDumpPath標記指定到保留文件的現實途徑。（不論文件保留在哪，務必確保文件體系和/或Java流程必需要有權限設置裝備擺設，可以在個中寫入。）
3.bootclasspath
按期將一個類放入類途徑是很有贊助的，這類途徑與庫存JRE附帶的類途徑或許以某種方法擴大的JRE類途徑略有分歧。（新Java Crypto API供給商就是一個例子）。假如您想要擴大JRE，那末您定制的完成必需可使用引誘法式ClassLoader，該引誘法式可以加載rt.jar中的 java.lang.Object及其一切相干文件。
雖然您可以不法翻開rt.jar並將您的定制完成或新數據包移入個中，但從技巧上您就違背了您下載JDK時贊成的協定了。
相反，應用JVM本身的-Xbootclasspath選項，和皮膚-Xbootclasspath/p和-Xbootclasspath/a。
-Xbootclasspath使您可以設置完全的引誘類途徑（這平日包含一個對rt.jar的援用），和一些其他JDK附帶的（不是 rt.jar的一部門）JAR文件。-Xbootclasspath/p將值前置到現有bootclasspath中，並將 -Xbootclasspath/a附加到個中。
例如，假如您修正了庫中的java.lang.Integer，並將修正放在一個子途徑mods下，那末-Xbootclasspath/amods參數將新Integer放在默許的參數後面。
4.verbose
關於虛擬的或任何類型的Java運用法式，-verbose是一個很有效的一級診斷應用法式。該標記有三個子標記：gc、class和jni。
開辟人員測驗考試尋覓能否 JVM 渣滓搜集器產生毛病或許招致機能低下，平日起首要做的就是履行 gc。不幸的是，說明 gc 輸入很費事 — 足夠寫一本書。更蹩腳的是，在敕令行中打印的輸入在分歧的 Java 版本中或許不在分歧的 JVM 中會產生轉變，這使得准確說明變得更難。
普通來講，假如渣滓搜集器是一個分代搜集器（多半“企業級”VMs都是）。某種虛擬標記將會湧現，來指出一個全體打掃GC通路；在Sun JVM中，標記在GC輸入行的開端以“[FullGC...]”情勢湧現。
想要診斷ClassLoader和/或不婚配的類抵觸，class可以幫上年夜忙。它不只申報類什麼時候加載，還申報類從何處加載，包含到JAR的途徑（假如來自JAR）。
jni很少應用，除應用JNI或當地庫時。翻開時，它將申報各類JNI事宜，好比，當地庫什麼時候加載，辦法什麼時候彈回；再一次強調，在分歧JVM版本中，輸入會產生變更。
5.Command-line-X
我列出了JVM中供給的我愛好的敕令行選項，然則還有一些更多的須要您本身發明，運轉敕令行參數-X，列出JVM供給的一切非尺度（但年夜部門都是平安的）參數—例如：
-Xint，在說明形式下運轉JVM（關於測試JIT編譯器現實上能否對您的代碼起感化或許驗證能否JIT編譯器中有一個bug，這都很有效）。
-Xloggc:，和-verbose:gc做異樣的事，然則記載一個文件而不輸入到敕令行窗口。
JVM敕令行選項經常產生變更，是以，按期檢查是一個好主張。乃至，您深夜盯著監控器和下晝5點回家和老婆孩子吃頓晚餐，（或許在Mass Effect 2中祛除您的仇敵，依據您的愛好），它們都是紛歧樣的。
停止語
在臨盆情況中，敕令行標記不是為永遠應用而設計的——現實上，除您終止用來調優JVM渣滓搜集器的標記，沒有一個非尺度敕令行標志是公用於臨盆應用的。然則，作為對象來探聽在其他方面完整不通明的虛擬機的外部任務，長短常有效的。
