13161216443

您所在位置: 首頁> java技術> Java程序員必須知道的5個JVM命令行標志

Java程序員必須知道的5個JVM命令行標志

發布百知教育 來源:java技術 2019-05-10

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/OracleVM除外。查明一個標志是否被支持的最好方法是試用它,看它是否正常工作。倘若這些標志在技術上是不支持的,那么,使用它們您要承擔全部責任。如果這些標志中的任何一個使您的代碼、您的數據、您的服務器或您的一切消失得無影無蹤,我、Sun/OracleIBM都將不負責任。為以防萬一,建議先在虛擬(非常生產)環境中實驗。

在這個時刻您想要的是,在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、classjni。

開發人員嘗試尋找是否 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命令行選項時常發生變化,因此,定期查看是一個好主意。

 

結束語

 

在生產環境中,命令行標志不是為永久使用而設計的——事實上,除了您終止用來調優JVM垃圾收集器的標志,沒有一個非標準命令行標記是專用于生產使用的。但是,作為工具來刺探在其他方面完全不透明的虛擬機的內部工作,是非常有用的。


上一篇:Java講師:一圖讀懂JVM架構解析

下一篇:應屆生去公司找個Java程序員的職位需要什么技能?

相關推薦

www.akpsimsu.com

有位老師想和您聊一聊

關閉

立即申請