java虛擬機(jī)監(jiān)控及診斷工具命令行篇

講 深入拆解Java虛擬 文章詳30|Java虛擬機(jī)的及診斷工具（命令行篇2018-09-283030|Java虛擬機(jī)及診斷工具（命令行篇朗讀人 10′59′′|今天，我們來(lái)一起了解一下JDK中用于及診斷工具。本篇中我將使用剛剛發(fā)布的Java11版本你可能用過(guò)ps命令，打印所有正在運(yùn)行的進(jìn)程的相關(guān)信息。JDKjps命令（幫助文檔）沿用了同樣的概念：它將打印所有正在運(yùn)行的Java進(jìn)程的相關(guān)信息。在默認(rèn)情況下，jpsJavaID來(lái)打印額外的信息。例如，-l將打印模塊名以及包名；-v將打印傳遞給Java虛擬機(jī)的參數(shù)（如--代代$jps-18331o18332jdk.jcmd/sun.tools.jps.Jps18332jdk.jcmd/sun.tools.jps.Jps-mlv-UsePerfData），那么jps命令（以及下面介紹的jstat）將無(wú)法探知該Java進(jìn)程。..代$jstat--------- 代#Usage:jstat-outputOptions[-t][-hlines]VMID[interval代#Usage:jstat-outputOptions[-t][-hlines]VMID[interval$jstat-gc22126 417472,017472,017472,017472,0 17472,017472,017472,017472,0 403,9139904,0139538,4 當(dāng)本地環(huán)境的Java進(jìn)程時(shí)，VMID可以簡(jiǎn)單理解為PID。如果需要環(huán)境的Java進(jìn)程，你可以參考jstat的幫助文檔。在上面這個(gè)示例中，22126進(jìn)程是一個(gè)使用了CMS回收器的Java進(jìn)程。我們利用jstat的-gc子命令，來(lái)打印該進(jìn)程回收相關(guān)的數(shù)據(jù)。命令最后的1s4表示每隔1秒打印一次，共打印4區(qū)的容量（Utility）SurvivorSurvivor使用量為0。G1GC 71680,02048,069632,0□代$jstat-gc22208□代$jstat-gc22208你可能已經(jīng)留意到，S0C和S0U0Survivor（S1C）0。這是因?yàn)?，?dāng)使用G1GC時(shí)，Java虛擬機(jī)不再設(shè)置Eden區(qū)、Survivor區(qū)，老年代區(qū)的內(nèi)存邊EdenSurvivorSurvivorSurvivor（CopyingGC），我們只需另外申請(qǐng)一個(gè)或多個(gè)內(nèi)存區(qū)域，作為新的Survivor區(qū)。S1CS1US0CS0U0當(dāng)發(fā)生回收時(shí)，Java虛擬機(jī)可能出現(xiàn)Survivor內(nèi)存區(qū)域內(nèi)的對(duì)象全被回收或晉升的現(xiàn)象堆中可能完全沒(méi)有Survivor內(nèi)存區(qū)域，因而相應(yīng)的S1C和S1U將會(huì)是0。在下面這個(gè)示例中，第一列代表該Java進(jìn)程已經(jīng)啟動(dòng)了10.7秒。代代$jstat-gc-t10,7 55296,0 JavaGC（GCT）GCGC空間，隨時(shí)都可能拋出OOM異常。連續(xù)獲取多行性能數(shù)據(jù)，并取這幾行數(shù)據(jù)中OU列（即已占用的老年代內(nèi)存）的最小值。OU漏掉的CGC和CGCT，它們分別代表并發(fā)GCStop-The-World的次數(shù)和時(shí)間。出馬，分析我們通常會(huì)利用jmapdump:live,format=b,file=filename.bin命令，將堆中所有存活對(duì)這里format=b將使jmap導(dǎo)出與hprof（在Java9中已被移除）、-格式的文件可以被其他GUI工具查看，具體我會(huì)在下一篇中進(jìn)行演示。$-histoclassname[B[Ljava.lang.Object;[Ijava.math.BigIntegerjava.lang.String11代代差。舉個(gè)例子，假設(shè)在編譯生成的機(jī)器碼中，某些對(duì)象的生命周期在兩個(gè)安全點(diǎn)之間，那么:live□□代暫停時(shí)間較長(zhǎng)，約為二三十秒，可酌情調(diào)CTRL+CSIGINT信號(hào)無(wú)法停止，需要SIGKILL。staticdoublesum=0;publicstaticvoidmain(String[]args)for(inti=0;i<;i++){//countedsum+=Math.log(i);//Math.logisan}}jmap（以及接下來(lái)的jinfo、jstack和jcmd）JavaAttachAPI，因此只能本地Java進(jìn)程。一旦開啟Java虛擬機(jī)參數(shù)DisableAttaechanism（即使用參數(shù)-的jvm_args）、-XX參數(shù)（即輸出中的VMFlags），以及可在Java層面通過(guò)System.getProperty獲取的-D參數(shù)（即輸出中的SystemProperties）。代代$jinfoJavaSystemVMVMjvm_args:-Xlog:gc-Xmx1024mmand:org.example.Foojava_class_path(initial):LauncherType:pilerCount=4-XX:ConcGCThreads=3-VMsun.jnu.encoding=UTF-進(jìn)程的舉個(gè)例子，我們可以使用jinfoflag+HeapDumpAfterFullGC<PID>命令，開啟<PID>所指定的Java進(jìn)程的HeapDumpAfterFullGC參數(shù)。"manageableintx=intx=-intx=bool=bool=bool=ccstr=uintx=uintx=bool=bool=javaversion"11"2018-09-Java(TM)SERuntimeEnvironment18.9□代□代$java-XX:+PrintFlagsFinal-version|grepJavaHotSpot(TM)64-BitServerVM18.9(build11+28,mixedjstack的其中一個(gè)應(yīng)用場(chǎng)景便是死鎖檢測(cè)。這里我用jstackJava 代$jstack"Thread-0"#12prio=5os_prio=31cpu=1.32mselapsed=34.24stid=0xjava.lang.Thread.State:BLOCKED(onobjectmonitor)atwaitingtolock ff904c0>(alocked ff904b0>(aatDeadLock$$Lambda$1/0x0000000800060840.run(UnknownSource)atjava.lang.Thread.run(java.base@11/Thread.java:834)"Thread-1"#13prio=5os_prio=31cpu=1.43mselapsed=34.24stid=0xjava.lang.Thread.State:BLOCKED(onobjectmonitor)atwaitingtolock ff904b0>(alocked ff904c0>(aatDeadLock$$Lambda$2/0x0000000800063040.run(UnknownSource)atjava.lang.Thread.run(java.base@11/Thread.java:834)JNIglobalrefs:6,weakrefs:FoundoneJava-level"Thread-waitingtolockmonitor0x00007fb (object0x whichisheldby"Thread-1""Thread-waitingtolockmonitor (object whichiswhichisheldby"Thread-Javastackinformationforthethreadslisted"Thread-at-waitingtolockff904c0>(a-lockedff904b0>(aatDeadLock$$Lambda$1/0x0000000800060840.run(Unknownatjava.lang.Thread.run(java.base@11/Thread.java:834)at-waitingtolockff904b0>(a-lockedff904c0>(aatDeadLock$$Lambda$2/0x0000000800063040.run(UnknownatFound1…）以及正在