JVM命令行的標(biāo)志介紹

本篇內(nèi)容介紹了“JVM命令行的標(biāo)志介紹”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

　　1.DisableExplicitGC

　　只要跨代碼快速運(yùn)行grep，就會(huì)發(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!  System.gc();

　　顯式垃圾收集是一個(gè)非常糟糕的主意--就像將您和一個(gè)瘋狂的斗牛犬鎖在一個(gè)電話亭里。盡管調(diào)用的語法是依賴實(shí)現(xiàn)的，但如果您的JVM正在運(yùn)行一個(gè)分代的垃圾回收器（大多數(shù)是）System.gc();強(qiáng)迫VM執(zhí)行一個(gè)堆的“全部清掃”，雖然有的沒有必要。全部清掃比一個(gè)常規(guī)GC操作要昂貴好幾個(gè)數(shù)量級(jí)，這只是個(gè)簡(jiǎn)單數(shù)學(xué)問題。

　　您可以不把我的話放在心上--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

　　并不是任何VM都支持所有命令行標(biāo)志，Sun/Oracle的VM除外。查明一個(gè)標(biāo)志是否被支持的最好方法是試用它，看它是否正常工作。倘若這些標(biāo)志在技術(shù)上是不支持的，那么，使用它們您要承擔(dān)全部責(zé)任。如果這些標(biāo)志中的任何一個(gè)使您的代碼、您的數(shù)據(jù)、您的服務(wù)器或您的一切消失得無影無蹤，我、Sun/Oracle和IBM都將不負(fù)責(zé)任。為以防萬一，建議先在虛擬（非常生產(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類路徑略有不同。。如果您想要擴(kuò)展JRE，那么您定制的實(shí)現(xiàn)必須可以使用引導(dǎo)程序ClassLoader，該引導(dǎo)程序可以加載rt.jar中的 java.lang.Object及其所有相關(guān)文件。

　　盡管您可以非法打開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/amods參數(shù)將新Integer放在默認(rèn)的參數(shù)前面。

　　4.verbose

　　對(duì)于虛擬的或任何類型的Java應(yīng)用程序，-verbose是一個(gè)很有用的一級(jí)診斷使用程序。該標(biāo)志有三個(gè)子標(biāo)志：gc、class和jni。

　　開發(fā)人員嘗試尋找是否 JVM 垃圾收集器發(fā)生故障或者導(dǎo)致性能低下，通常首先要做的就是執(zhí)行 gc。不幸的是，解釋 gc 輸出很麻煩 - 足夠?qū)懸槐緯?。更糟糕的是，在命令行中打印的輸出在不同?span lang="EN-US"> Java 版本中或者不在不同的 JVM 中會(huì)發(fā)生改變，這使得正確解釋變得更難。

　　一般來說，如果垃圾收集器是一個(gè)分代收集器（多數(shù)“企業(yè)級(jí)”VMs都是）。某種虛擬標(biāo)志將會(huì)出現(xiàn)，來指出一個(gè)全部清掃GC通路；在Sun JVM中，標(biāo)志在GC輸出行的開始以“[FullGC…]”形式出現(xiàn)。

　　想要診斷ClassLoader和/或不匹配的類沖突，class可以幫上大忙。它不僅報(bào)告類何時(shí)加載，還報(bào)告類從何處加載，包括到JAR的路徑（如果來自JAR）。

　　jni很少使用，除了使用JNI或本地庫(kù)時(shí)。打開時(shí)，它將報(bào)告各種JNI事件，比如，本地庫(kù)何時(shí)加載，方法何時(shí)彈回；再一次強(qiáng)調(diào)，在不同JVM版本中，輸出會(huì)發(fā)生變化。

　　5.Command-line-X

　　-Xint，在解釋模式下運(yùn)行JVM（對(duì)于測(cè)試JIT編譯器實(shí)際上是否對(duì)您的代碼起作用或者驗(yàn)證是否JIT編譯器中有一個(gè)bug，這都很有用）。

　　-Xloggc:，和-verbose:gc做同樣的事，但是記錄一個(gè)文件而不輸出到命令行窗口。

　　JVM命令行選項(xiàng)時(shí)常發(fā)生變化，因此，定期查看是一個(gè)好主意。

“JVM命令行的標(biāo)志介紹”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！