JVM運行狀態(tài)監(jiān)控及分析TITLE技術(shù)方案技術(shù)方案簡介目的背景應用系統(tǒng)運行時出現(xiàn)內(nèi)存溢出問題，需要定位及解決。定義、首字母縮寫詞和縮略語暫無。參考資料本方案的參考資料如下：周志明，《深入理解Java虛擬機：JVM高級特性與最佳實踐》MAT，/mat從轉(zhuǎn)儲(Dump)文件中調(diào)試并除錯，/question/129540%5f23220……約束本文描述的工具，只在JDK6以上版本中進行驗證?？赡懿糠止ぞ咴贘DK1.4.2_14和JDK1.5.0_06以上也能夠執(zhí)行，但并未實際測試驗證，僅供參考。常見JVM內(nèi)存相關(guān)問題現(xiàn)象通常內(nèi)存溢出時JVM會提示具體的內(nèi)存溢出原因，下面是幾種常見的情況及簡要的原因說明及相關(guān)的JVM配置。棧溢出：StackOverflowErrorJVM輸出信息：“java.lang.StackOverflowError”。JVM相關(guān)機制：JVM在執(zhí)行Java方法調(diào)用時需要使用棧傳遞調(diào)用參數(shù)、返回值以及保存局部變量表，通常組織為棧幀（StackFrame）結(jié)構(gòu)。從概念上說，每次Java方法調(diào)用都會消耗一定的棧內(nèi)存，當這個方法調(diào)用結(jié)束返回后釋放這部分內(nèi)存。而每個Java線程對應的棧內(nèi)存是有限的（通常JVM啟動后就固定了），因此當方法嵌套層數(shù)過多或者棧幀內(nèi)的數(shù)據(jù)結(jié)構(gòu)（如局部變量表）過大時，可能出現(xiàn)StackOverflowError。JVM控制參數(shù)：可以通過-Xss1024K設置線程棧大小為1024K。通常無需設置此參數(shù)，在不同OS下的JVM均有自己的默認值設置，一般在256K-1024K之間。常見原因分析建議：出現(xiàn)此問題通常應該先分析應用系統(tǒng)的原因，而不是考慮增大“-Xss”參數(shù)設置值。因為出現(xiàn)此問題的最可能原因是過深的方法調(diào)用（比如錯誤的遞歸調(diào)用造成方法調(diào)用層次過深），即應用程序中的編程錯誤造成棧溢出。當出現(xiàn)StackOverflowError時，根據(jù)此異常的詳細信息通常可以比較明確地找到錯誤代碼的可能位置，通常不需要復雜的工具支持。堆溢出JVM輸出信息：“java.lang.OutOfMemoryError:Javaheapspace”，或者類似輸出信息，視JVM廠商及版本略有區(qū)別，但關(guān)鍵字都是“heap”或者“堆”。JVM相關(guān)機制：從概念上說，Heap是存儲Java類實例和數(shù)組的內(nèi)存區(qū)。比如任何“obj=newXClass();”的調(diào)用都是在Heap中進行內(nèi)存分配，當不能成功進行這種內(nèi)存分配時，JVM將拋出“java.lang.OutOfMemoryError:Javaheapspace”。JVM控制參數(shù)：-Xms512m：設置Heap最小值為512m；-Xmx1024m：設置Heap最大值為1024m；JVM控制參數(shù)設置相關(guān)知識及建議：在生產(chǎn)環(huán)境中可以將-Xms和-Xmx設為相同大小，避免JVM動態(tài)調(diào)整Heap大小；在32位系統(tǒng)上（無論是Windows還是Unix/Linux），-Xmx參數(shù)通常無法設置到大于1500m，且此值在不同的系統(tǒng)上并不相同；在32位系統(tǒng)上，并不建議將-Xmx設到最大（如1500m）。因為32位系統(tǒng)中JVM進程的可用的內(nèi)存是有限的（一個32為系統(tǒng)上的進程的地址空間最大為4G，能使用的內(nèi)存最大為4G，實際上OS核心會占據(jù)1～2G地址空間，而留給應用層的地址空間通常不超過3G，應用層真正能夠使用的通常在2G以內(nèi)），這些內(nèi)存除了JavaHeap使用，JVM進程本身、NativeThread都需要使用。因此過大的JavaHeap可能增大其他溢出的可能；常見原因分析建議：Java堆內(nèi)存溢出是較為常見的情況，有可能是因為：應用系統(tǒng)的錯誤導致的問題，即應用系統(tǒng)錯誤地生成了太多的新Object，JVM中用來存儲對象的堆（heap）中無法容納新Object。此時需要通過分析HeapDump（堆轉(zhuǎn)儲文件）定位并修正問題；也有可能并非程序錯誤，而是業(yè)務場景或者并發(fā)程度確實需要更大的Heap來支持。此時有多種可能的解決方案：分析HeapDump（堆轉(zhuǎn)儲文件），確定應用中內(nèi)存使用情況，更改應用的實現(xiàn)邏輯，減少新Object的創(chuàng)建。其本質(zhì)是以時間換空間的策略，即增加應用邏輯執(zhí)行時間，來換取更少的內(nèi)存需求；增大Heap，即設置更大的-Xmx參數(shù)。32位系統(tǒng)上余地并不大，并可能增大Thread相關(guān)內(nèi)存溢出的可能性；更換為使用64位系統(tǒng)，64位系統(tǒng)才能支持更大的Heap，但增大Heap帶來的不僅是好處，也可能造成GC時間增加，應用系統(tǒng)“停頓”的感覺更明顯；堆內(nèi)存溢出較為常見，準確地定位及分析需要借助工具，后文將詳細描述如何借助工具進行分析。持久區(qū)（方法區(qū)）溢出JVM輸出信息：“java.lang.OutOfMemoryError:PermGenspace”。JVM相關(guān)機制：概念上說，JVM持久區(qū)（方法區(qū)）是用來存儲類型相關(guān)的信息,如該類型的常量池，字段或方法信息，而且類型中的類(靜態(tài))變量同樣也是存儲在方法區(qū)中（如到ClassLoader的引用和到Class類的引用）。當持久區(qū)不足以容納需要加載的Class時JVM將拋出此異常，異常中明確指出是持久區(qū)內(nèi)存不足。JVM控制參數(shù)：-XX:PermSize=64m：設置初始持久區(qū)大小為64m；-XX:MaxPermSize=256m：設置持久區(qū)最大為256m；常見原因分析建議：此問題通常是太多的Class需要加載造成的，Class的數(shù)量和應用系統(tǒng)的代碼規(guī)模相關(guān)，較大的應用系統(tǒng)需要較大的MaxPermSize設置。需要注意的是，JavaEE應用中的jsp最終會被編譯成Class并加載，因此可能在大量使用jsp的JavaEE應用系統(tǒng)中需要設置較大的MaxPermSize，但通常不應該超過256m。另外，對于使用了ASM/CGLib等字節(jié)碼工具動態(tài)生成Class的系統(tǒng)，編程錯誤導致的運行時大量生成Class也可能導致此異常。此異常明確地說明了問題，且除了編程錯誤一般都能夠通過加大MaxPermSize參數(shù)值來解決，通常不需要復雜的工具進行分析定位。無法創(chuàng)建OS本地線程JVM輸出信息：“java.lang.OutOfMemoryError:unabletocreatenewnativethread”。JVM相關(guān)機制：概念上說，JVM中啟動一個Thread，通常會在OS中創(chuàng)建并啟動一個本地線程（NativeThread），而無論是因為內(nèi)存問題還是本地線程數(shù)量問題，都有可能導致此異常。NativeThread內(nèi)存問題：OS在創(chuàng)建本地線程時同樣需要使用內(nèi)存，但這個內(nèi)存不在JVM的堆內(nèi)存范圍內(nèi)，而是在JVM進程之內(nèi)、JavaHeap/方法區(qū)等內(nèi)存之外。因此完全有可能JavaHeap越大，剩余的用來創(chuàng)建NativeThread的內(nèi)存越小，從而可創(chuàng)建的NativeThread越少，出現(xiàn)此異常的可能性越大；NativeThread數(shù)量問題：OS對于進程允許創(chuàng)建的線程數(shù)量通常有限制，因此JVM能夠啟動的Thread數(shù)量也有限，當JVM中啟動的Thread超出此限制時將出現(xiàn)此異常。通常JVM中已經(jīng)啟動的Thread數(shù)量應該是有限的，除非是程序錯誤啟動了大量的Thread。JVM控制參數(shù)：無，但通常減少-Xmx的值能夠保留更多的內(nèi)存給OS線程。常見原因分析建議：出現(xiàn)此問題時，只要獲取JVM當時的ThreadDump（線程轉(zhuǎn)儲信息），并對ThreadDump進行分析即可。分析ThreadDump信息很容易獲取JVM線程相關(guān)的信息，判斷JVM中是否存在預料之外的線程，或者線程所處的狀態(tài)和正在執(zhí)行的調(diào)用是否符合預期。內(nèi)存泄漏嚴格意義上來說，我們一般遇到的JVM中的內(nèi)存泄漏其實不是內(nèi)存泄漏，因為嚴格地說內(nèi)存泄漏指的是已經(jīng)分配的內(nèi)存無法被應用系統(tǒng)正確回收。而我們通常說的JVM中的內(nèi)存泄漏只是部分對象被其他對象持有引用，因此不能被GC過程回收；同時，這些不能回收的對象被應用系統(tǒng)“遺忘”了，不再有任何用處的同時還占據(jù)著大量內(nèi)存。在應用系統(tǒng)看來這部分內(nèi)存像是丟失了（或者泄露了）。我們解決內(nèi)存泄漏問題就是要找到的是這些應用程序中的錯誤。舉個簡單的例子：MapglobalMap=newHashMap<String,List<SomeObject>>();globalMap在整個應用系統(tǒng)生命周期內(nèi)都會被引用，因此不能被GC回收。因而任何globalMap.put(aString,aList)的操作將在globalMap中引用aString和aList兩個對象，直到被明確清除出globalMap后aString和aList才有可能被GC回收，否則此兩個對象將永遠占據(jù)JVM內(nèi)存。如果應用系統(tǒng)是“忘了”從globalMap中remove(aString)，則對應用系統(tǒng)來說就像是aString和aList所占的內(nèi)存“泄漏”了。JVM異常退出JVM運行過程中有可能異常退出，即JVM進程忽然消失，此時通常不是JavaStack或者JavaHeap出現(xiàn)異常，而是與OS本地堆棧有關(guān)。JVM中運行的應用系統(tǒng)通常難以處理此問題，但如果應用系統(tǒng)中使用了JNI，則有可能與此部分代碼相關(guān)。在Windows上，JVM異常退出時通常會生成“hs_err_pidXXXX.log”文件，此文件位于JVM進程的“當前路徑”下（如Tomcat的bin/），可以從此文件中得到異常退出時的現(xiàn)象。遺憾的是，應用系統(tǒng)開發(fā)人員很難分析此文件，但可以根據(jù)此文件得到一些信息，或者將此文件反饋給能夠分析的技術(shù)社區(qū)。下面列舉幾種HotSpotJVM異常退出時產(chǎn)生的“hs_err_pidXXXX.log”文件中的信息：#AnunexpectederrorhasbeendetectedbyJavaRuntimeEnvironment:#EXCEPTION#AnunexpectederrorhasbeendetectedbyJavaRuntimeEnvironment:#EXCEPTION_STACK_OVERFLOW(0xc00000fd)atpc=0x6da3a7fd,pid=3012,tid=3108#JavaVM:JavaHotSpot(TM)ClientVM(11.0-b15mixedmodewindows-x86)#Problematicframe:#V[jvm.dll+0x18a7fd]#Ifyouwouldliketosubmitabugreport,pleasevisit:#/webapps/bugreport/crash.jsp##AnunexpectederrorhasbeendetectedbyJavaRuntimeEnvironment:#AnunexpectederrorhasbeendetectedbyJavaRuntimeEnvironment:#java.lang.OutOfMemoryError:requested1024000bytesforGrETinC:\BUILD_AREA\jdk6_10\hotspot\src\share\vm\utilities\growableArray.cpp.Outofswapspace?#InternalError(allocation.inline.hpp:42),pid=4060,tid=3816#Error:GrETinC:\BUILD_AREA\jdk6_10\hotspot\src\share\vm\utilities\growableArray.cpp#JavaVM:JavaHotSpot(TM)ClientVM(11.0-b15mixedmodewindows-x86)#Ifyouwouldliketosubmitabugreport,pleasevisit:#/webapps/bugreport/crash.jsp注：上面列舉的JVM異常只包含部分總結(jié)性的信息，log文件中還有更多的詳細信息。HotSpotJVM之外的其他JVM是否有類似信息尚未確定，但此類問題通常應用層開發(fā)者難以解決（JNI相關(guān)應用的開發(fā)者除外）。JVM運行時信息收集ThreadDump/線程轉(zhuǎn)儲ThreadDump中包含下列信息：所有JVM中啟動了但是未結(jié)束的Thread列表；每個Thread當前所處的狀態(tài)及其調(diào)用棧（StackTrace）；JVM內(nèi)部是否出現(xiàn)死鎖（Deadlock）；基于ThreadDump信息可以確認JVM當前的執(zhí)行狀態(tài)，ThreadDump信息常見的收集方法包括：使用jvisualvm：在所有平臺上，當可以通過jvisualvm監(jiān)控JVM運行時，可以直接在jvisualvm中進行ThreadDump，請參見jvisualvm的說明；Windows平臺：在JVMConsole（比如Tomcat啟動時的后臺窗口）下按下組合鍵Ctrl-Break，Console中將打印ThreadDump信息。當Console的緩沖區(qū)不夠大時可能無法顯示全部信息，需要增大Console的緩沖區(qū)；Unix/Linux平臺：先找到對應的JVM進程號（pid）：ps–ef|grepjavakill-3(JVM進程號)：此時ThreadDump信息將輸出到JVMConsole中。此命令不會終止JVM運行，只是輸出ThreadDump信息；JavaHeapDump/堆轉(zhuǎn)儲JVMHeapDump的方法與JVM密切相關(guān)，因此后面的描述基于不同運行環(huán)境的JVM分別描述。SUN/OracleHotSpotJava6+版本的SUN/OracleHotSpotJVM支持下列方式生成HeapDump：基于JVM事件：當JVM運行過程中出現(xiàn)OutOfMemoryError時自動HeapDump，這也是生產(chǎn)系統(tǒng)中最可行的HeapDump生成方法。涉及參數(shù)包括：-XX:+HeapDumpOnOutOfMemoryError：當內(nèi)存溢出時進行HeapDump，默認在Java進程的“當前目錄”下生成類似于“java_pid1340.hprof”形式的文件?？梢杂?XX:HeapDumpPath控制生成文件的位置；-XX:HeapDumpPath=path：設置OutOfMemoryError時JVM生成HeapDump文件的位置。此參數(shù)默認值為“./java_pid%p.hprof”，其中“%p”代表Java進程的PID（ProcessID，進程標識），所以會在Java進程的當前目錄下生成包含PID的.hprof文件；交互式HeapDump：在JVM運行中，以交互式方式獲取HeapDump，通常用于開發(fā)調(diào)試階段定位問題，生產(chǎn)環(huán)境還是建議基于JVM事件進行HeapDump，方式包括：使用jvisualvm：在所有平臺上，當可以通過jvisualvm監(jiān)控JVM運行時，可以直接在jvisualvm中進行HeapDump，請參見jvisualvm的說明；使用JDK中的jmap工具：jmap-dump[live,]format=b,file=filenamepid使用OS功能：在Linux中，使用“無害”的gcore命令或破壞性的“kill-6”或“kill-11”命令來生成一個內(nèi)核文件。然后，使用jmap從內(nèi)核文件中提取一個堆轉(zhuǎn)儲文件：jmap-dump:format=b,file=heap.hprofpath_to_java_executable_core；使用Ctrl+Break：如果運行的應用程序設置了-XX:+HeapDumpOnCtrlBreak命令行選項，那么在通過控制臺發(fā)出Ctrl+Break事件或SIGQUIT（通常通過kill-3生成），那么會生成一個HPROF格式的轉(zhuǎn)儲文件和一個線程Dump。有一些版本不支持這個選項，那么在遇到這些情況時可以嘗試使用：-Xrunhprof:format=b,file=heapdump.hprof。并不推薦使用這種方式，一些HotSpot版本不支持此參數(shù)，建議使用上述其他交互式方式。IBMAIX+J9JVM此環(huán)境下可以通過下列方式獲取HeapDump：基于JVM事件：當JVM運行過程中出現(xiàn)OutOfMemoryError時自動HeapDump，這也是生產(chǎn)系統(tǒng)中最可行的HeapDump生成方法。涉及參數(shù)包括：設置JVM啟動時的環(huán)境變量：exportIBM_HEAP_DUMP=trueexportIBM_HEAPDUMP=trueexportIBM_HEAPDUMP_OUTOFMEMORY=trueexportIBM_JAVADUMP_OUTOFMEMORY=trueexportIBM_JAVACORE_OUTOFMEMORY=true設置JVM啟動參數(shù)：-XX:+HeapDumpOnOutOfMemoryError-Xdump:java+system:events=systhrow,filter=java/lang/OutOfMemoryError,range=1..4,request=exclusive+compact+prepwalk：設置在前4個OutOfMemoryError時進行HeapDump；基于OS和JDK命令：通過OS命令gencore生成進程COREDUMP，然后通過JDK命令工具jextract獲取HeapDump；此方法較為復雜，并不建議用于生產(chǎn)環(huán)境；建議基于JVM事件獲取HeapDump。GC信息GC參數(shù)在不同JVM的或不同JVM版本中均有不同，但一般能夠支持下列參數(shù)，系統(tǒng)運行時可以設置GC日志文件以收集GC信息供后續(xù)分析：-Xloggc:gc.log：指定將gc的信息輸出到gc.log中；-verbose:gc：輸出詳盡的GC信息，通常verbose都只能用于開發(fā)調(diào)試環(huán)境，而不應該用于生產(chǎn)環(huán)境；-XX:+PrintGC：輸出GC的簡要信息；-XX:+PrintGCDetails：GC的詳細信息；-XX:+PrintGCTimeStamps：GC的時間信息；-XX:+PrintGCApplicationStoppedTime：GC造成的應用暫停的時間；-XX:+PrintTenuringDistribution：GC信息可以提供簡要的GC運行過程信息，但不太容易基于GC信息判斷JVM有什么異常狀態(tài)，因此GC信息收集方法僅供參考。JVM遠程監(jiān)測jvisualvm只能遠程連接啟用了JMX遠程監(jiān)測的JVM，JVM啟動時需要設置一些系統(tǒng)屬性來啟用JMX遠程監(jiān)測。JVM中JMX相關(guān)的配置文件及說明位于固定位置，一般位于“JDK/jre/lib/management”，其中有JMX配置的模板文件。因為一般JDK在服務器上是公用的，因此不應該直接在此位置更改JMX配置，而應該復制其中的文件后更改，并在JVM的啟動參數(shù)中指定使用更改后的文件。在JVM啟動參數(shù)中指定JMX配置文件的方式為：-Dcom.sun.management.config.file=<somewhere>.perties，JMX的配置信息在此文件中設置，下面描述JMX配置文件中的典型配置。無認證方式啟用JMX并且不進行認證，此時任何JMX客戶端都可以遠程連接到此JVM進行遠程監(jiān)測，因此安全性很差，但在開發(fā)調(diào)試和測試環(huán)境中較為方便。在JVM啟動參數(shù)中設置“-Dcom.sun.management.config.file=C:\JMXRemote\perties”，同時在JMX配置文件（C:\JMXRemote\perties）中設置下面的值：#設置JMX端口號，JMX客戶端連接時使用此端口com.sun.management.jmxremote.port=9999#設置JMX不使用SSL連接com.sun.management.jmxremote.ssl=false#設置JMX客戶端連接本JVM時無需身份認證com.sun.management.jmxremote.authenticate=false上述設置后啟動JVM，則任何JMX客戶端均可以連接此JVM并進行JVM運行狀態(tài)監(jiān)測。認證方式啟用JMX且需要身份認證，只有認證通過的JMX客戶端才能夠連接到此JVM進行監(jiān)測。在JVM啟動參數(shù)中設置“-Dcom.sun.management.config.file=C:\TEMP\JMXRemote\auth\perties”，并在此文件中設置下列值：#設置JMX端口號，JMX客戶端連接時使用此端口com.sun.management.jmxremote.port=9999#設置JMX不使用SSL連接com.sun.management.jmxremote.ssl=false#設置JMX客戶端連接本JVM時需要身份認證com.sun.management.jmxremote.authenticate=true#設置身份認證文件地址com.sun.management.jmxremote.password.file=C:/TEMP/JMXRemote/auth/jmxremote.password#設置角色文件地址com.sun.management.jmxremote.access.file=C:/TEMP/JMXRemote/auth/jmxremote.access注意：access和password文件必須正確設置才能生效，建議只改動password文件中的口令以避免其他錯誤。而且jmxremote.password文件必須正確設定其在文件系統(tǒng)中的權(quán)限，否則JVM無法啟動，通常需要設置為此文件只有所有者能夠訪問。如果需要設置JMXServer的監(jiān)聽地址，可以設置下列參數(shù)：-Djava.rmi.server.hostname=x.x.x.x"上述設置后啟動JVM，則任何JMX客戶端均可以連接此JVM并進行JVM運行狀態(tài)監(jiān)測。常用工具簡述Java相關(guān)的常用工具及參考位置。jvisualvmjvisualvm是SUN/OracleJDK自帶的JVM運行狀態(tài)監(jiān)測工具，能夠獲取JVM運行狀態(tài)的各種信息，包括ThreadDump和HeapDump，在可以使用的情況下建議使用此工具監(jiān)測JVM運行狀態(tài)。連接遠程JVM當設置了JMX遠程監(jiān)測后啟動JVM（如啟動Tomcat）后，可以在其他機器上用jvisualvm遠程監(jiān)測此JVM（如Tomcat），過程如下：啟動jvisualvm，增加遠程主機（即配置了JMX的JVM所在的主機），如下圖：輸入遠程主機地址，如下圖：確定后，增加JMX連接，如下圖：輸入JMX連接信息，JMX端口信息即是com.sun.management.jmxremote.port=9999中設定的端口號，如下圖：確定后，如果JMX配置為無認證需求，則連接完成；否則將要求輸入JMX連接用戶名和口令，即在文件com.sun.management.jmxremote.password.file=<password_file>中設置的用戶名和口令。如下圖：用戶名和口令驗證成功后連接完成，如下圖：獲取ThreadDump直接在jvisualvm中獲取ThreadDump，如下圖：ThreadDump的結(jié)果如下圖：在其中進行ThreadDump分析即可。獲取HeapDump直接在jvisualvm中獲取HeapDump，如下圖：執(zhí)行HeapDump后將提示HeapDump創(chuàng)建位置，如下圖：確定后將創(chuàng)建HeapDump文件，之后在MAT中分析此文件即可。EclipseMemoryAnalyzerTool，MATMAT是JavaHeapDump文件的分析工具，在出現(xiàn)OutOfMemoryError的情況下，通過MAT可以幫助準確定位內(nèi)存溢出原因。IDMAIX環(huán)境中生成的COREDUMP文件不是MAT默認識別的.hprof文件格式，需要在MAT中安裝IBMDTFJ插件才能夠打開并分析IBMDUMP文件。由于完整的JavaHEAPDUMP文件通常較大（1G以上），因此MAT通常在64位機器和JDK上才足夠進行分析，因此應該使用64位MAT并在MemoryAnalyzer.ini配置文件中設置足夠大的-Xmx參數(shù)。后文的內(nèi)存溢出場景分析全部基于MAT。MAT本身的幫助信息簡短扼要，下面簡單介紹幾個常用的功能。打開HeapDump及LeakSuspectsReportsMAT中打開HeapDump文件后，將提示是否進行內(nèi)存泄漏分析并產(chǎn)生報告，一般這個分析都能發(fā)現(xiàn)可能的泄漏點，建議進行分析，如下圖：分析結(jié)果如下圖，其中描述了可能的泄漏點：如果報告中提示“ThestacktraceofthisThreadisavailable.Seestacktrace.”，則說明疑似泄漏點有ThreadStack信息，這是最理想的情況，幾乎可以立刻發(fā)現(xiàn)可能的內(nèi)存泄漏點代碼位置，如下圖：上面紅線位置的jsp應該就是泄漏點。但HeapDump中不一定都包含ThreadStack信息，比如IBM的.phd格式的HeapDump中就不包含ThreadStack。通常JDK6+HotSpotJVM的HeapDump（.hprof）和IBMJ9生成的COREDUMP文件中會包含ThreadStack，因此建議獲取最完整的HeapDump文件進行分析。查看Heap中的對象Heap中的對象是HeapDump中的主要內(nèi)容，可以查看HeapDump中的全部對象，如下圖：查看結(jié)果如下圖：可以在其中查詢?nèi)我釩lass，如下圖：可以查看某個類型的對象集合，如下圖：實例信息如下圖：之后可以查看每個對象的內(nèi)容，并判斷是否是應該存在的對象。查看DominatorTree簡單地說，DominatorTree是對象引用關(guān)系圖的子集，通過DominatorTree可以很清晰地發(fā)現(xiàn)“大對象”，即從此“大對象”開始占用大量內(nèi)存的對象集合。查看DominatorTree，如下圖：DominatorTree數(shù)據(jù)如下圖，可以清楚地看見占用內(nèi)存最大的對象子集：之后分析這個對象包含的其他對象關(guān)系，如下圖：通常DominatorTree有助于找到這些占用大量內(nèi)存的對象子集并進行分析。查看線程信息如果ThreadDump中線程信息可用，可以直接查看線程相關(guān)信息，如下圖：線程相關(guān)信息如下圖：圖中紅線標識的部分是線程對象及其引用其他對象共占用的內(nèi)存，可以看出此值過大，可以對此線程對象進行分析以找到占用這些內(nèi)存的原因。場景分析示例下面列舉一些場景并分析其可能存在的問題。JVM內(nèi)的Deadlock與ThreadDumpJVM可以檢測到synchronized導致的死鎖，考慮下面的代碼：publicclassClassA{ publicclassClassA{ publicstaticStringmonitor1="monitor1"; publicstaticStringmonitor2="monitor2"; publicstaticvoidmain(String[]args){ Threadthread1=newThread(newRunnable(){ publicvoidrun(){ try{ synchronized(monitor1){ System.out.println(Thread.currentThread().getName()+":gotmonitor1"); Thread.sleep(5000); synchronized(monitor2){ System.out.println(Thread.currentThread().getName()+":gotmonitor2"); }