目錄

一、java線程狀態(tài)

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

三、統(tǒng)計dump文件中處于不同狀態(tài)的線程數(shù)量

四、舉例分析不同狀態(tài)的線程

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

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

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

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

正文

一、java線程狀態(tài)

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

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

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

三、統(tǒng)計dump文件中處于不同狀態(tài)的線程數(shù)量

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

四、舉例分析不同狀態(tài)的線程

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

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00007fa3a8042800 nid=0x1a3a waiting for monitor entry [0x00007fa3f8764000]   java.lang.Thread.State: BLOCKED (on object monitor)	at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:93)	- waiting to lock <0x00000000e1c9f108> (a weblogic.socket.PosixSocketMuxer$1)	at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)	at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
a、線程狀態(tài)是 Blocked，阻塞狀態(tài)。說明線程等待資源超時！
b、waiting to lock <0x00000000e1c9f108> 線程在等待給這個 0x00000000acf4d0c0 地址上鎖
c、waiting for monitor entry 說明此線程通過 synchronized(obj) {……} 申請進入了臨界區(qū)，從而進入了“Entry Set”隊列，但該 obj 對應的 monitor 被其他
線程擁有，所以本線程在 Entry Set 隊列中等待。
d、第一行里，"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'"是 Thread Name。daemon是守護進程。prio是線程優(yōu)先級。
tid指Java Thread id。nid指native線程的id。[0x00007fa3f8764000]是線程棧起始地址。
2、分析TIMED_WAITING (on object monitor)和WAITING (on object monitor)狀態(tài)的線程
"weblogic.GCMonitor" daemon prio=10 tid=0x00007fa3a4006000 nid=0x1ba4 in Object.wait() [0x00007fa327af9000]   java.lang.Thread.State: TIMED_WAITING (on object monitor)	at java.lang.Object.wait(Native Method)	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)	- locked <0x00000000e2241e50> (a java.lang.ref.ReferenceQueue$Lock)	at weblogic.platform.GCMonitorThread.waitForNotification(GCMonitorThread.java:88)	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)狀態(tài)的線程
"scheduler_QuartzSchedulerThread" prio=10 tid=0x00007fa3a82f0800 nid=0x1aad waiting on condition [0x00007fa3cc39e000]   java.lang.Thread.State: TIMED_WAITING (sleeping)	at java.lang.Thread.sleep(Native Method)	at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:394)
a、“TIMED_WAITING (sleeping)” 可以看出程序調用了Thread.sleep(long millis);
4、分析TIMED_WAITING (parking)和WAITING (parking)狀態(tài)的線程
"Timer runner-1,TICKET_REGISTRY_76ENV,bjxt-kfcs-46159" daemon prio=10 tid=0x00007fa3a8ad6000 nid=0x1a44 waiting on condition [0x00007fa3cd7b2000]   java.lang.Thread.State: TIMED_WAITING (parking)	at sun.misc.Unsafe.park(Native Method)	- parking to wait for  <0x00000000e21c58f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2116)	at org.jgroups.util.TimeScheduler2.waitUntilNextExecution(TimeScheduler2.java:328)	at org.jgroups.util.TimeScheduler2._run(TimeScheduler2.java:310)	at org.jgroups.util.TimeScheduler2.run(TimeScheduler2.java:268)	at java.lang.Thread.run(Thread.java:662)
a、“TIMED_WAITING (parking)”中的 timed_waiting 指等待狀態(tài)，但這里指定了時間，到達指定的時間后自動退出等待狀態(tài)；parking指線程處于掛起中。b、“waiting on condition”需要與堆棧中的“parking to wait for <0x00000000e21c58f0>” 結合來看。首先，本線程肯定是在等待某個條件的發(fā)生，來把自己喚醒。