分析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)状态的线程

"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、线程状态是 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)状态的线程

"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)状态的线程

"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)状态的线程

"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 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。
b、“waiting on condition”需要与堆栈中的“parking to wait for <0x00000000e21c58f0>” 结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。

巴特西

分析jvm线程堆栈

最新文章

热门文章