Java的Thread Dump应用诊断

摘自 http://www.blogjava.net/toucao01/archive/2011/03/30.html

由于原地址访问出错，在百度快照里找到了，就转了过来备用。。

 

 

 

Thread Dump是非常有用的诊断Java应用问题的工具，每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力。虽然各个 Java虚拟机thread dump打印输出格式上略微有一些不同，但是Thread dumps出来的信息包含线程；线程的运行状态、标识和调用的堆栈；调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。

Thread Dump特点：

能在各种操作系统下使用
能在各种Java应用服务器下使用
可以在生产环境下使用而不影响系统的性能
可以将问题直接定位到应用程序的代码行上
Thread Dump能诊断的问题包括：

查找内存泄露，常见的是程序里load大量的数据到缓存
发现死锁线程
Sun的JVM用下列方法可以产生Thread Dump堆栈信息：

1，Solaris OS
<ctrl>-’"’ (Control-Backslash)
 kill -QUIT <pid>

2, HP-UX/UNIX/Linux
Kill -3 PID
PID通过下面方法获取
ps -efHl | grep 'java' **. **

3，Windows
直接对MSDOS窗口的程序按Ctrl-break

有些Java应用服务器是在控制台上运行，如Weblogic，为了方便获取threaddump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件，用"nohup sh startWebLogic.sh > start.log &"命令，执行"kill -3 <pid>"，Stack trace就会输出到start.log里。Tomcat的Thread Dump会输出到命令行控制台或者logs的catalina.out文件里。为了反映线程状态的动态变化，需要接连多次做thread dump，每次间隔10-20sJava大代码错误整理 ?。

IBM JVM下产生Thread Dump：

在AIX上用IBM的JVM，内存溢出时默认地会产生javacore文件（关于cpu的）和heapdump文件(关于内存的)。如果没有参照下列方法：
1 choose one cluster member, set the following before this server start:
在was启动前设置下面环境变量（可以加在启动脚本中）
export IBM_HEAPDUMP=true
export IBM_HEAP_DUMP=true
export IBM_HEAPDUMP_OUTOFMEMORY=true
export IBM_HEAPDUMPDIR=<directory path>

2 please use set command to make sure you do not have DISABLE_JAVADUMP parameter
then start this cluster member.
用set命令检查参数设置，确保没有设置DISABLE_JAVADUMP，然后启动server

3 when you find free memory < 50% when no heavy access, please run kill -3 <pid>
执行kill -3 <pid>命令可以生成javacore文件和heapdump文件（pid为was java进程的id号，可以用ps -ef|grep java 查到），可以多执行几次，按照下面操作进行

ps -ef > psef1.txt
ps aux > psaux1.txt
vmstat 5 10 > vmstat.txt
kill -3 <app server id>
wait for 2 mins
kill -3 <app server id>
wait for 2 mins
kill -3 <app server id>
netstat -an> netstat2.txt
ps -ef > psef2.txt
ps aux > psaux2.txt
将上面产生的 txt 文件和/usr/WebSphere/AppServer/javacore*文件和heapdump文件拷贝到本地，然后删除这些文件，因为这些文件会占用较大的文件系统空间。
将/usr/WebSphere/AppServer/logs/wlmserver1(或2)目录下当天产生的日志拷贝出来


在IBM JVM产生的javacore或者Threaddump文件中应用服务器Web容器的常见线程状态：

Idle线程：一个已经准备好接受请求的线程，但是没有和插件或者客户端建立连接
Keep-Alive线程：是一个已经准备好接受请求的线程，并且已经和插件或者客户端建立连接
正在接受请求的线程：是一个线程正在读取request的内容或者头部

下面就给出各种线程在javacore或者Threaddump中的表现形式：

Idle线程货运代理：
"Servlet.Engine.Transports : 20" (TID:0x427F190, sys_thread_t:0x15D175E8, state:R, native ID:0xBB8) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:429)
at com.ibm.ws.util.BoundedBuffer.take(BoundedBuffer.java:161)
at com.ibm.ws.util.ThreadPool.getTask(ThreadPool.java(Compiled Code)) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))

Keep-alive线程 (非SSL模式)：
"Servlet.Engine.Transports : 20" (TID:0x427F190, sys_thread_t:0x15D175E8, state:R, native ID:0xBB8) prio=5
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at com.ibm.ws.io.Stream.read(Stream.java)
at com.ibm.ws.io.ReadStream.readBuffer(ReadStream.java)
at com.ibm.ws.io.ReadStream.read(ReadStream.java)
at com.ibm.ws.http.HttpRequest.readRequestLine(HttpRequest.java)
at com.ibm.ws.http.HttpRequest.readRequest(HttpRequest.java)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java)
at com.ibm.ws.util.CachedThread.run(ThreadPool.java)

Keep-alive线程 (SSL模式)：
"Servlet.Engine.Transports : 12" (TID:0x458DBA18, sys_thread_t:0x60B297C0, state:R, native ID:0x427E) prio=5
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code))
at com.ibm.sslite.s.a(Unknown Source)(Compiled Code)
at com.ibm.sslite.s.b(Unknown Source)(Compiled Code)
at com.ibm.sslite.s.a(Unknown Source)(Compiled Code)
at com.ibm.sslite.a.read(Unknown Source)(Compiled Code)
at com.ibm.jsse.a.read(Unknown Source)(Compiled Code)
at com.ibm.ws.io.Stream.read(Stream.java(Compiled Code))
at com.ibm.ws.io.ReadStream.readBuffer(ReadStream.java(Inlined Compiled Code))
at com.ibm.ws.io.ReadStream.read(ReadStream.java(Inlined Compiled Code))
at com.ibm.ws.http.HttpRequest.readRequestLine(HttpRequest.java(Compiled Code))
at com.ibm.ws.http.HttpRequest.readRequest(HttpRequest.java(Compiled Code))
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java(Compiled Code))
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)


正在接受请求的线程：
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:85)
at com.ibm.ws.io.Stream.read(Stream.java:17)
at com.ibm.ws.io.ReadStream.readBuffer(ReadStream.java:411)
at com.ibm.ws.io.ReadStream.read(ReadStream.java:110)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:448)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)


Sun JVM的常见线程状态：

对于thread dump信息，主要关注的是线程的状态和其执行堆栈
线程的状态一般为三类
Runnable（R）：当前可以运行的线程
Waiting on monitor（CW）：线程主动wait
Waiting for monitor entry（MW）：线程等锁
一般关注的都是第一和第三种状态的线程
Cpu很忙则关注runnable的线程
Cpu闲则关注waiting for monitor entry的线程
一种典型的死锁是由于在server端应用（比如servlet）中请求由同一weblogic实例server的资源
解决办法就是将该servlet放到另外的执行队列里去执行

下面给出一个典型的死锁线程（注意STUCK关键字）：

"[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=02fe9a18 nid=35 lwp_id=7518924 runnable [440dd000..440db878]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:134)
 at weblogic.jdbc.oracle.net8.OracleDataProvider.getArrayOfBytesFromSocket(Unknown Source)
 at weblogic.jdbc.oracle.net8.OracleDataProvider.readFirstPacketInBuffer(Unknown Source)
 at weblogic.jdbc.oracle.net8.OracleDataProvider.readPacket(Unknown Source)
 at weblogic.jdbc.oracle.net8.OracleDataProvider.receive(Unknown Source)
 at weblogic.jdbc.oracle.net8.OracleNet8NSPTDAPacket.sendRequest(Unknown Source)
 at weblogic.jdbc.oracle.OracleImplStatement.fetchNext(Unknown Source)
 at weblogic.jdbc.oracle.OracleImplStatement.fetchNext2(Unknown Source)
 at weblogic.jdbc.oracle.OracleImplResultset.fetchAtPosition(Unknown Source)
 at weblogic.jdbc.base.BaseImplResultSet.next(Unknown Source)
 at weblogic.jdbc.base.BaseResultSet.next(Unknown Source)
 - locked <55f25550> (a weblogic.jdbc.oracle.OracleConnection)
 at weblogic.jdbc.wrapper.ResultSet_weblogic_jdbc_base_BaseResultSet.next(Unknown Source)
 at org.hibernate.loader.Loader.doQuery(Loader.java:685)


UNIX/Linux下可用top、vmstat或prstat命令观察系统资源状况

线程转储非常诊断，如对象监控死锁同步相关的问题非常有用。按Ctrl - "在Solaris / Linux上或Ctrl -中断对Windows已经被一个共同的方式来获取正在运行的应用程序线程转储。在Solaris或Linux，您可以发送QUIT信号给目标应用程序。在这两种情况下的目标应用程序打印一个线程转储到标准输出，并检测是否有任何死锁涉及的对象监视器。
jstack，一个新的故障诊断工具在老虎（J2SE 5.0中）介绍，提供了另一种方式来获得一个应用程序的线程转储。艾伦巴特曼有个关于jstack及其几个野马改进（即Java SE 6）不错的博客。野马jstack工作，如果你在Windows下，仿若按Ctrl - "或Ctrl -中断。
JConsole是JMX的投诉GUI工具，允许你在飞行中获得一个线程转储。在“使用JConsole监控应用程序”的文章给你一个老虎的监控和管理功能的概述。
野马扩展了线程转储，jstack，并JConsole的支持，以改善其诊断能力java.util.concurrent.locks。例如，在野马的主题选项卡JConsole现在显示了同步线程正在等待获取的线程被阻塞时锁定ReentrantLock的，也就是哪个线程拥有该锁。
此外，它有一个新的“死??锁检测”按钮（在底部）。当你点击“检测死锁”按钮，它会发送一个请求到目标应用程序来执行死锁检测操作。如果目标应用程序正在运行的野马，它发现死锁涉及监察对象都像java.util.concurrent.locks良好。如果目标应用是在Tiger上运行，它发现死锁涉及监察对象只。每个死锁周期将显示在一个单独的死锁标签。
点击这里看到这个截图更广泛的形式。
在JDK 6中有一个很好的演示$ JDK_HOME FullThreadDump /演示/管理/ FullThreadDump其中JDK_HOME是你的JDK 6的位置。该演示已经包含在JDK 5.0和更新为使用新的野马的API。它表明了java.lang.management API的使用获得检测死锁的线程转储和编程。

评论

1 楼 城的灯 2015-05-03  

这篇文章不错，推荐给博主，http://www.yangguo.info/2015/4/1/17.html