Java可以說(shuō)是目前最流行的開(kāi)發(fā)語(yǔ)言,尤其是在移動(dòng)互聯(lián)網(wǎng)軟件開(kāi)發(fā)方面當(dāng)中的廣泛應(yīng)用,更大大加快了其行業(yè)的發(fā)展前景。
中培偉業(yè)《高級(jí)Java開(kāi)發(fā)最佳實(shí)踐》培訓(xùn)專家臧老師在這里向大家介紹了五個(gè)命令行標(biāo)志,臧老師表示,了解這個(gè)命令行標(biāo)志,能夠?qū)ava開(kāi)發(fā)工作帶來(lái)極大的幫助。以下是這個(gè)命令行標(biāo)志的詳細(xì)介紹:
1.DisableExplicitGC
我已記不清有多少次用戶要求我就應(yīng)用程序性能問(wèn)題提供咨詢了,其實(shí)只要跨代碼快速運(yùn)行g(shù)rep,就會(huì)發(fā)現(xiàn)清單所示的問(wèn)題—原始Java性能反模式:
清單 1. System.gc(); // We just released a bunch of objects, so tell the stupid // garbage collector to collect them already!
顯式垃圾收集是一個(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/OracleVM除外。查明一個(gè)標(biāo)志是否被支持的最好方法是試用它,看它是否正常工作。倘若這些標(biāo)志在技術(shù)上是不支持的,那么,使用它們您要承擔(dān)全部責(zé)任。如果這些標(biāo)志中的任何一個(gè)使您的代碼、您的數(shù)據(jù)、您的服務(wù)器或您的一切消失得無(wú)影無(wú)蹤,我、Sun/OracleIBM都將不負(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í)用工具我在上一篇文章中介紹過(guò)。您可以使用 相應(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/amods參數(shù)將新Integer放在默認(rèn)的參數(shù)前面。
4.verbose
對(duì)于虛擬的或任何類型的Java應(yīng)用程序,-verbose是一個(gè)很有用的一級(jí)診斷使用程序。該標(biāo)志有三個(gè)子標(biāo)志:gcclassjni
開(kāi)發(fā)人員嘗試尋找是否 JVM 垃圾收集器發(fā)生故障或者導(dǎo)致性能低下,通常首先要做的就是執(zhí)行 gc。不幸的是,解釋 gc 輸出很麻煩 — 足夠?qū)懸槐緯?shū)。更糟糕的是,在命令行中打印的輸出在不同的 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)始以“[FullGC...]”形式出現(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)控器和下午點(diǎn)回家和妻子孩子吃頓晚飯,或者在Mass Effect 2中消滅您的敵人,根據(jù)您的喜好,它們都是不一樣的。
臧老師最后總結(jié)道,在生產(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)部工作,是非常有價(jià)值的