Java线程Dump分析工具--jstack
(转http://www.cnblogs.com/nexiyi/p/java_thread_jstack.html)
jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式:
jstack [-l][F] pid
如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外,jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态,jstack是非常有用的。进程处于hung死状态可以用-F强制打出stack。
dump 文件里,值得关注的线程状态有:
死锁,Deadlock(重点关注)
执行中,Runnable
等待资源,Waiting on condition(重点关注)
等待获取监视器,Waiting on monitor entry(重点关注)
暂停,Suspended
对象等待中,Object.wait() 或 TIMED_WAITING
阻塞,Blocked(重点关注)
停止,Parked
在摘了另一篇博客的三种场景:
实例一:Waiting to lock 和 Blocked
"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234) at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)
说明:
1)线程状态是 Blocked,阻塞状态。说明线程等待资源超时!
2)“ waiting to lock <0x00000000acf4d0c0>”指,线程在等待给这个 0x00000000acf4d0c0 地址上锁(英文可描述为:trying to obtain 0x00000000acf4d0c0 lock)。
3)在 dump 日志里查找字符串 0x00000000acf4d0c0,发现有大量线程都在等待给这个地址上锁。如果能在日志里找到谁获得了这个锁(如locked < 0x00000000acf4d0c0 >),就可以顺藤摸瓜了。
4)“waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申请进入了临界区,从而进入了下图1中的“Entry Set”队列,但该 obj 对应的 monitor 被其他线程拥有,所以本线程在 Entry Set 队列中等待。
5)第一行里,"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00007fd4f8684000]是线程栈起始地址。
实例二:Waiting on condition 和 TIMED_WAITING
"RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x00007fd4f1a59000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:662)
说明:
1)“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态,但这里指定了时间,到达指定的时间后自动退出等待状态;parking指线程处于挂起中。
2)“waiting on condition”需要与堆栈中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先,本线程肯定是在等待某个条件的发生,来把自己唤醒。其次,SynchronousQueue 并不是一个队列,只是线程之间移交信息的机制,当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务,因此这就是本线程在等待的条件。
3)别的就看不出来了。
实例三:in Obejct.wait() 和 TIMED_WAITING
"RMI RenewClean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09 in Object.wait() [0x00007f34f4bd0000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516) at java.lang.Thread.run(Thread.java:662)
说明:
1)“TIMED_WAITING (on object monitor)”,对于本例而言,是因为本线程调用了 java.lang.Object.wait(long timeout) 而进入等待状态。
2)“Wait Set”中等待的线程状态就是“ in Object.wait() ”。当线程获得了 Monitor,进入了临界区之后,如果发现线程继续运行的条件没有满足,它则调用对象(一般就是被 synchronized 的对象)的 wait() 方法,放弃了 Monitor,进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ,“ Wait Set”队列中线程才得到机会去竞争,但是只有一个线程获得对象的 Monitor,恢复到运行态。
3)RMI RenewClean 是 DGCClient 的一部分。DGC 指的是 Distributed GC,即分布式垃圾回收。
4)请注意,是先 locked <0x00000000aa672478>,后 waiting on <0x00000000aa672478>,之所以先锁再等同一个对象,请看下面它的代码实现:
static private class Lock { };
private Lock lock = new Lock();
public Reference<? extends T> remove(long timeout)
{
synchronized (lock) {
Reference<? extends T> r = reallyPoll();
if (r != null) return r;
for (;;) {
lock.wait(timeout);
r = reallyPoll();
……
}
}
即,线程的执行中,先用 synchronized 获得了这个对象的 Monitor(对应于 locked <0x00000000aa672478> );当执行到 lock.wait(timeout);,线程就放弃了 Monitor 的所有权,进入“Wait Set”队列(对应于 waiting on <0x00000000aa672478> )。
5)从堆栈信息看,是正在清理 remote references to remote objects ,引用的租约到了,分布式垃圾回收在逐一清理呢。
参考:
命令汇总:http://blog.csdn.net/fenglibing/article/details/6411940
三种实例:http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
相关推荐
Java线程Dump分析工具jstack是Java开发人员和运维人员常用的诊断工具,它能够帮助我们了解Java应用程序中线程的状态,以及线程的执行轨迹。本文将深入解析jstack的使用方法及其在不同场景下的应用。 jstack命令的...
TDA(Thread Dump Analyzer)是一款强大的Java线程分析工具,它能够帮助开发者深入理解应用在运行时的线程状态,包括线程的阻塞情况、等待资源、死锁等问题。下面将详细介绍TDA的使用方法、功能以及它如何帮助我们...
1. 使用JDK自带的`jstack`命令,通过进程ID来生成线程Dump。 2. 在应用服务器如Tomcat的管理界面中,如果有提供,可以直接触发线程Dump的生成。 3. 如果应用支持,也可以通过发送特定信号(如Linux下的`SIGQUIT`)给...
`TDA(ZIP)`,全称为Thread Dump Analyzer,是一个专门用于分析Java线程Dump文件的强大工具,能够帮助开发者更有效地定位并解决线程相关的问题。 首先,我们需要理解什么是线程Dump。线程Dump是Java虚拟机当前所有...
需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析。
`jstack`则是用来打印Java线程堆栈的工具,它能帮助我们了解程序的执行状态,查看是否有死锁、线程阻塞等问题。通过`jstack <pid>`命令,我们可以得到每个线程的调用栈信息,从而分析出哪些代码段可能导致了CPU过高...
Java Thread Dump 分析是 Java 应用程序性能优化的重要工具之一。Thread Dump 是 JVM 的一个快照,记录了当前所有线程的状态,包括线程的 ID、名称、状态、锁信息等。通过分析 Thread Dump,可以找到导致 CPU 高的...
本文将详细介绍`JStack`的使用方法及其在分析Java线程堆栈中的应用。 #### 二、JStack简介 `JStack`是Java Development Kit (JDK)的一部分,用于生成正在运行的Java应用程序的线程快照。这些快照提供了关于每个...
TDA(Thread Dump Analyzer)是一个专门用于解析和分析Java线程Dump的日志文件的工具,它可以帮助开发者快速定位线程阻塞、死锁等问题,从而优化应用程序的性能。 **一、什么是线程Dump** 线程Dump是Java虚拟机在...
Java内存dump分析和Thread Dump(Java Core)是Java性能调优中的重要环节,它们能帮助开发者定位和解决系统中的各种问题,如内存泄漏、线程阻塞等。下面将详细介绍这两个概念及其分析工具。 首先,Java堆内存dump,...
Java线程转储分析器 这是用Java编写的Java线程转储分析器。 它基于的。 有关用法的其他信息,请参见 。 执照 Java Thread Dump Analyzer是根据。 版权所有2014-2016 Spotify AB 版权所有2016-2018 MP Objects BV...
对于线程dump,除了jstack之外,还可以使用jvisualvm等工具进行图形化分析,这为开发者提供了更为直观的线程状态视图。 总而言之,jstack是一个功能强大的工具,可以协助开发者深入理解Java应用程序的运行状态,...
Thread Dump Analyzer(简称TDA)正是这样一款用于分析Java线程转储(Thread Dump)的专业工具,它能够帮助我们深入了解应用的运行状态,识别出潜在的性能问题。 TDA 2.2版本是其重要的迭代,提供了更强大的功能和...
这是一个专门用于解析Java线程和监视器转储的工具,它能够帮助开发者识别和解决多线程应用程序中的死锁、阻塞和其他并发问题。该工具可以分析线程堆栈信息,展示每个线程的状态,包括运行、等待、阻塞等,并提供详细...
`jstack`命令是Java开发中用于诊断线程堆栈信息的重要工具,它可以帮助开发者了解Java应用程序的线程状态,包括运行、等待、阻塞等,以及是否存在死锁等问题。当遇到性能问题或者线程卡住不前时,`jstack`能提供关键...
Java线程 Dump(Thread Dump)是Java应用程序在特定时间点的线程状态快照,它包含每个线程的详细信息,如线程ID、线程名称、线程状态以及调用堆栈。当Java应用程序出现性能问题、死锁或者线程阻塞等情况时,Thread ...
总之,Thread Dump Analyzer是一款强大的故障排查工具,它简化了Java线程问题的诊断过程,对于提升Java应用的性能和稳定性具有重要意义。通过深入理解和熟练运用TDA,开发者能更高效地定位并解决多线程问题,从而...
通过`jstack`命令(Java堆栈跟踪工具),我们可以获取到应用的线程快照,即dump线程,从而分析是否存在死锁。`jstack`命令可以显示所有线程的状态,包括它们的堆栈跟踪,这对于定位死锁非常有帮助。 3. **使用...