jmc线程转储_如何分析线程转储– IBM VM
jmc線程轉(zhuǎn)儲(chǔ)
本文是我們的線程轉(zhuǎn)儲(chǔ)分析系列的第4部分，它將為您提供什么是IBM VM的JVM線程轉(zhuǎn)儲(chǔ)以及您將找到的不同線程和數(shù)據(jù)點(diǎn)的概述。 您將看到和學(xué)習(xí)??到，IBM VM Thread Dump格式是不同的，但是提供了更多現(xiàn)成的故障排除數(shù)據(jù)。在這一點(diǎn)上，您應(yīng)該知道線程如何與Java EE容器交互以及什么是線程轉(zhuǎn)儲(chǔ)。 在深入探究分析模式之前，您還需要了解IBM VM Thread Dump格式，因?yàn)檫@是在IBM VM上使用IBM WAS時(shí)期望的典型Thread Dump數(shù)據(jù)。
IBM VM線程轉(zhuǎn)儲(chǔ)故障概述
為了使您更好地理解，請(qǐng)?jiān)谙旅娴膱D表中向您顯示IBM 1.6 VM線程轉(zhuǎn)儲(chǔ)及其常見數(shù)據(jù)點(diǎn)的可視分類：
您可以從HotSpot VM線程轉(zhuǎn)儲(chǔ)中找到其他多余的運(yùn)行時(shí)數(shù)據(jù)。 請(qǐng)記住，您可能不需要檢查所有這些數(shù)據(jù)點(diǎn)，但是您仍然需要了解根據(jù)問題情況可用的數(shù)據(jù)。 本文的其余部分將更詳細(xì)地介紹每個(gè)線程轉(zhuǎn)儲(chǔ)部分。
＃線程轉(zhuǎn)儲(chǔ)生成事件
第一部分為您提供有關(guān)如何生成此線程轉(zhuǎn)儲(chǔ)的詳細(xì)信息。 IBM Thread Dump可以由“信號(hào)3”或“用戶”生成，例如kill -3 <Java pid>，也可以由嚴(yán)重的JVM條件（例如OutOfMemoryError）自動(dòng)生成。
0SECTION TITLE subcomponent dump routineNULL ===============================1TISIGINFO Dump Event "user" (00004000) received 1TIDATETIME Date: 2012/03/12 at 20:52:131TIFILENAME Javacore filename: /apps/wl11g/domains/app/javacore.20120312.205205.1949928.0004.txt1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt)1TIPREPSTATE Prep State: 0x4 (exclusive_vm_access)0SECTION TITLE subcomponent dump routineNULL ===============================1TISIGINFO OUTOFMEMORY received 1TIDATETIME Date: 2012/06/01 at 09:52:121TIFILENAME Javacore filename: /usr/WebSphere/AppServer/javacore311328.1338524532.txt＃硬件和操作系統(tǒng)環(huán)境詳細(xì)信息
下一部分為您提供了有關(guān)此IBM VM所運(yùn)行的當(dāng)前硬件和操作系統(tǒng)的一些詳細(xì)信息：
0SECTION GPINFO subcomponent dump routineNULL ================================2XHOSLEVEL OS Level : AIX 5.32XHCPUS Processors -3XHCPUARCH Architecture : ppc643XHNUMCPUS How Many : 63XHNUMASUP NUMA is either not supported or has been disabled by user＃JRE詳細(xì)信息和Java啟動(dòng)參數(shù)
本節(jié)非常有用，因?yàn)樗鼮槟峁┝擞嘘P(guān)JRE主版本和補(bǔ)丁程序級(jí)別以及所有JVM啟動(dòng)參數(shù)的完整視圖。
0SECTION ENVINFO subcomponent dump routineNULL =================================1CIJAVAVERSION JRE 1.6.0 IBM J9 2.4 AIX ppc64-64 build jvmap6460sr9-20101124_692951CIVMVERSION VM build 20101124_0692951CIJITVERSION JIT enabled, AOT enabled - r9_20101028_17488ifx21CIGCVERSION GC - 20101027_AA1CIRUNNINGAS Running as a standalone JVM…………………………………………………………………………………………＃用戶和環(huán)境變量
本節(jié)為您提供了當(dāng)前用戶和環(huán)境變量的列表，例如文件描述符限制。
1CIUSERLIMITS User Limits (in bytes except for NOFILE and NPROC)NULL ------------------------------------------------------------------------NULL type soft limit hard limit2CIUSERLIMIT RLIMIT_AS unlimited unlimited2CIUSERLIMIT RLIMIT_CORE 1073741312 unlimited2CIUSERLIMIT RLIMIT_CPU unlimited unlimited2CIUSERLIMIT RLIMIT_DATA unlimited unlimited2CIUSERLIMIT RLIMIT_FSIZE unlimited unlimited2CIUSERLIMIT RLIMIT_NOFILE 4096 40962CIUSERLIMIT RLIMIT_RSS 33554432 unlimited2CIUSERLIMIT RLIMIT_STACK 33554432 4294967296＃Java堆詳細(xì)信息和GC歷史記錄
與HotSpot VM 1.6+相似，IBM VM線程轉(zhuǎn)儲(chǔ)還包含有關(guān)Java堆容量和利用率的信息，以及為Java進(jìn)程的每個(gè)內(nèi)存空間分配的內(nèi)存段。
請(qǐng)記住，更深入的Java Heap分析將需要您按照以下教程分析Heap Dump二進(jìn)制快照。 http://javaeesupportpatterns.blogspot.com/2011/02/ibm-sdk-heap-dump-httpsession-footprint.html
最后，還介紹了垃圾回收過程的歷史。
0SECTION MEMINFO subcomponent dump routineNULL =================================1STHEAPFREE Bytes of Heap Space Free: 51104BC8 1STHEAPALLOC Bytes of Heap Space Allocated: 800000001STSEGTYPE Internal Memory…………………………………………………………………………………………1STSEGTYPE Object Memory…………………………………………………………………………………………1STSEGTYPE Class Memory…………………………………………………………………………………………1STSEGTYPE JIT Code Cache…………………………………………………………………………………………1STSEGTYPE JIT Data Cache…………………………………………………………………………………………STGCHTYPE GC History 3STHSTTYPE 00:52:07:523048405 GMT j9mm.51 - SystemGC end: newspace=466136480/483183616 oldspace=899251600/1610612736 loa=80530432/80530432 3STHSTTYPE 00:52:07:523046694 GMT j9mm.139 - Reference count end: weak=40149 soft=87504 phantom=33 threshold=17 maxThreshold=32 3STHSTTYPE 00:52:07:522164027 GMT j9mm.91 - GlobalGC end: workstackoverflow=0 overflowcount=0 weakrefs=40149 soft=87504 threshold=17 phantom=33 finalizers=4947 newspace=466136480/483183616 oldspace=899251600/1610612736 loa=80530432/80530432 3STHSTTYPE 00:52:07:522152764 GMT j9mm.90 - GlobalGC collect complete＃Java和JVM對(duì)象監(jiān)視器的鎖和死鎖詳細(xì)信息
此線程轉(zhuǎn)儲(chǔ)部分非常重要。 線程問題經(jīng)常涉及線程由于特定對(duì)象監(jiān)視器上的鎖而在彼此之間等待，例如線程B等待獲取線程A持有的對(duì)象監(jiān)視器上的鎖。死鎖條件還可以不時(shí)觸發(fā)；例如， 特別是對(duì)于非線程安全的實(shí)現(xiàn)。
IBM VM線程轉(zhuǎn)儲(chǔ)提供了一個(gè)單獨(dú)的部分，您可以在其中分析每個(gè)線程持有的鎖，包括等待鏈，例如，許多線程正在等待獲取同一對(duì)象監(jiān)視器鎖。
0SECTION LOCKS subcomponent dump routineNULL ===============================NULL 1LKPOOLINFO Monitor pool info:2LKPOOLTOTAL Current total number of monitors: 1034NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors):2LKMONINUSE sys_mon_t:0x0000000115B53060 infl_mon_t: 0x0000000115B530A0:3LKMONOBJECT java/util/Timer$TimerImpl@0x0700000000C92AA0/0x0700000000C92AB8: <unowned>3LKNOTIFYQ Waiting to be notified:3LKWAITNOTIFY "Thread-7" (0x0000000114CAB400)…………………………………………………………………………## Threads waiting chain2LKMONINUSE sys_mon_t:0x000000012462FE00 infl_mon_t: 0x000000012462FE40:3LKMONOBJECT com/inc/server/app/Request@0x07000000142ADF30/0x07000000142ADF48: owner "Thread-30" (0x000000012537F300), entry count 13LKNOTIFYQ Waiting to be notified:3LKWAITNOTIFY "Thread-26" (0x0000000125221F00)3LKWAITNOTIFY "Thread-27" (0x0000000125252000)3LKWAITNOTIFY "Thread-28" (0x000000012527B800)3LKWAITNOTIFY "Thread-29" (0x00000001252DDA00)3LKWAITNOTIFY "Thread-31" (0x0000000125386200)3LKWAITNOTIFY "Thread-32" (0x0000000125423600)3LKWAITNOTIFY "Thread-33" (0x000000012548C500)3LKWAITNOTIFY "Thread-34" (0x00000001255D6000)3LKWAITNOTIFY "Thread-35" (0x00000001255F7900)…………………………………………………………………………＃Java EE中間件，第三方和自定義應(yīng)用程序線程
與HotSpot VM線程轉(zhuǎn)儲(chǔ)格式相似，此部分是線程轉(zhuǎn)儲(chǔ)的核心，通常您將在其中花費(fèi)大部分分析時(shí)間。 找到的線程數(shù)將取決于您使用的中間件軟件，第三方庫（可能具有自己的線程）和您的應(yīng)用程序（ 如果創(chuàng)建任何自定義線程，通常不是最佳實(shí)踐 ）。
在下面的示例中，以下線程處于BLOCK狀態(tài)，這通常意味著它正在等待獲取對(duì)象監(jiān)視器上的鎖。 您將需要在前面的部分中進(jìn)行搜索，并確定哪個(gè)線程持有該鎖，以便您可以查明根本原因。
3XMTHREADINFO "[STUCK] ExecuteThread: '162' for queue: 'weblogic.kernel.Default (self-tuning)'" J9VMThread:0x000000013ACF0800, j9thread_t:0x000000013AC88B20, java/lang/Thread:0x070000001F945798, state:B, prio=13XMTHREADINFO1 (native thread ID:0x1AD0F3, native priority:0x1, native policy:UNKNOWN)3XMTHREADINFO3 Java callstack:4XESTACKTRACE at org/springframework/jms/connection/SingleConnectionFactory.createConnection(SingleConnectionFactory.java:207(Compiled Code))4XESTACKTRACE at org/springframework/jms/connection/SingleConnectionFactory.createQueueConnection(SingleConnectionFactory.java:222(Compiled Code))4XESTACKTRACE at org/springframework/jms/core /JmsTemplate102.createConnection(JmsTemplate102.java:169(Compiled Code))4XESTACKTRACE at org/springframework/jms/core /JmsTemplate.execute(JmsTemplate.java:418(Compiled Code))4XESTACKTRACE at org/springframework/jms /core/JmsTemplate.send(JmsTemplate.java:475(Compiled Code))4XESTACKTRACE at org/springframework/jms /core/JmsTemplate.send(JmsTemplate.java:467(Compiled Code))…………………………………………………………………………………………………………＃JVM類加載器摘要
最后，IBM VM Thread Dump的最后一部分為您提供了詳細(xì)的類加載器摘要。 在處理與Class Loader相關(guān)的問題和泄漏時(shí)，這是非常關(guān)鍵的數(shù)據(jù)。 您將在運(yùn)行的JVM中找到每個(gè)活動(dòng)Class loader的已加載Class的數(shù)量和類型。
我建議您閱讀以下案例研究，以獲取有關(guān)如何在使用IBM VM時(shí)查明此類問題的根本原因的完整教程。
http://javaeesupportpatterns.blogspot.com/2011/04/class-loader-memory-leak-debugging.html
我希望本文有助于理解IBM VM線程轉(zhuǎn)儲(chǔ)的基本視圖。 下一篇文章（第5部分）將通過一步一步的教程和我在過去十年中使用的技術(shù)為您提供有關(guān)如何分析JVM線程轉(zhuǎn)儲(chǔ)的教程。
參考： 如何分析線程轉(zhuǎn)儲(chǔ)–第4部分： Java EE支持模式和Java教程博客上的JCG合作伙伴 Pierre-Hugues Charbonneau提供的IBM VM 。
翻譯自: https://www.javacodegeeks.com/2012/06/how-to-analyze-thread-dump-ibm-vm.html
jmc線程轉(zhuǎn)儲(chǔ)
總結(jié)
以上是生活随笔為你收集整理的jmc线程转储_如何分析线程转储– IBM VM的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 移动级桌面级显卡对比分析
- 下一篇： 哪些电脑店可以修显卡(修显卡的店)