分析jvm線程堆棧

目錄

一、java線程狀態

二、使用jstack生成進程dump文件

三、統計dump文件中處於不同狀態的線程數量

四、舉例分析不同狀態的線程

1、分析BLOCKED (on object monitor)狀態的線程

2、分析TIMED_WAITING (on object monitor)和WAITING (on object monitor)狀態的線程

3、分析TIMED_WAITING (sleeping)狀態的線程

4、分析TIMED_WAITING (parking)和WAITING (parking)狀態的線程

 

正文

一、java線程狀態

二、使用jstack生成進程dump文件

a、先使用ps -ef|grep java找到java進程號

b、jstack pid > /opt/dump/pid.dump

三、統計dump文件中處於不同狀態的線程數量

grep java.lang.Thread.State pid.dump| awk '{print $2$3$4$5}' | sort | uniq -c ，例子如下：

四、舉例分析不同狀態的線程

1、分析BLOCKED (on object monitor)狀態的線程

1. "ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00007fa3a8042800 nid=0x1a3a waiting for monitor entry [0x00007fa3f8764000]
2. java.lang.Thread.State: BLOCKED (on object monitor)
3. at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java: 93)
4. - waiting to lock < 0x00000000e1c9f108> (a weblogic.socket.PosixSocketMuxer$1)
5. at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java: 29)
6. at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java: 42)
7. at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java: 145)
8. at weblogic.kernel.ExecuteThread.run(ExecuteThread.java: 117)

a、線程狀態是 Blocked，阻塞狀態。說明線程等待資源超時！

b、waiting to lock <0x00000000e1c9f108> 線程在等待給這個 0x00000000acf4d0c0 地址上鎖

c、waiting for monitor entry 說明此線程通過 synchronized(obj) {……} 申請進入了臨界區，從而進入了“Entry Set”隊列，但該 obj 對應的 monitor 被其他

線程擁有，所以本線程在 Entry Set 隊列中等待。

d、第一行里，"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'"是 Thread Name。daemon是守護進程。prio是線程優先級。

tid指Java Thread id。nid指native線程的id。[0x00007fa3f8764000]是線程棧起始地址。

2、分析TIMED_WAITING (on object monitor)和WAITING (on object monitor)狀態的線程

 

1. "weblogic.GCMonitor" daemon prio=10 tid=0x00007fa3a4006000 nid=0x1ba4 in Object.wait() [0x00007fa327af9000]
2. java.lang.Thread.State: TIMED_WAITING (on object monitor)
3. at java.lang.Object.wait(Native Method)
4. at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java: 118)
5. - locked < 0x00000000e2241e50> (a java.lang.ref.ReferenceQueue$Lock)
6. at weblogic.platform.GCMonitorThread.waitForNotification(GCMonitorThread.java: 88)
7. at weblogic.platform.GCMonitorThread.run(GCMonitorThread.java: 64)

a、“TIMED_WAITING (on object monitor)”可以看出程序在獲得了“<0x00000000e2241e50>”的鎖之后，調用了lock.wait(timeout)方法在等待其他線程

調用lock.notify()或lock.notifyAll();

b、WAITING (on object monitor)和TIMED_WAITING (on object monitor)在於前者調用了lock.wait()方法

 

3、分析TIMED_WAITING (sleeping)狀態的線程

1. "scheduler_QuartzSchedulerThread" prio=10 tid=0x00007fa3a82f0800 nid=0x1aad waiting on condition [0x00007fa3cc39e000]
2. java.lang.Thread.State: TIMED_WAITING (sleeping)
3. at java.lang.Thread.sleep(Native Method)
4. at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java: 394)

a、“TIMED_WAITING (sleeping)” 可以看出程序調用了Thread.sleep(long millis);

 

4、分析TIMED_WAITING (parking)和WAITING (parking)狀態的線程

1. "Timer runner-1,TICKET_REGISTRY_76ENV,bjxt-kfcs-46159" daemon prio=10 tid=0x00007fa3a8ad6000 nid=0x1a44 waiting on condition [0x00007fa3cd7b2000]
2. java.lang.Thread.State: TIMED_WAITING (parking)
3. at sun.misc.Unsafe.park(Native Method)
4. - parking to wait for <0x00000000e21c58f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
5. at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java: 198)
6. at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java: 2116)
7. at org.jgroups.util.TimeScheduler2.waitUntilNextExecution(TimeScheduler2.java: 328)
8. at org.jgroups.util.TimeScheduler2._run(TimeScheduler2.java: 310)
9. at org.jgroups.util.TimeScheduler2.run(TimeScheduler2.java: 268)
10. at java.lang.Thread.run(Thread.java: 662)

a、“TIMED_WAITING (parking)”中的 timed_waiting 指等待狀態，但這里指定了時間，到達指定的時間后自動退出等待狀態；parking指線程處於掛起中。
b、“waiting on condition”需要與堆棧中的“parking to wait for <0x00000000e21c58f0>” 結合來看。首先，本線程肯定是在等待某個條件的發生，來把自己喚醒。