Thread Dump

Thread Dump 性能分析方法：

1，Solaris OS

-’\’ (Control-Backslash)

kill -QUIT





2, Linux





Kill -3 PID

PID通过下面方法获取

ps -efHl | grep 'java'






Kill -3  输出到 Catalina.out 中







3，Windows

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







如何分析Java虚拟机死锁




我发现现在网上没有好好讲这个的，少数的几篇文章都是大谈自己的工具，却没把方法讲清楚。我决定以我以前碰到的case为例写一篇来分享。


到目前为止，我认为分析Java代码问题的最有效的工具仍然是java thread dump。原因：




- 任何操作系统平台下都可以使用。



- 在多数情况下，可以在生产环境中使用。



- 和操作系统提供的工具相比，java thread dump给出的信息是直白的，直接对应到应用代码。



- 它对被分析的系统干扰很小，因此能反应真实的问题。而其它很多profiling或Instrument工具本身对JVM运行有很大的干扰，经常不能暴露出真正的问题，而且这种工具不能用于生产系统。





我觉得在通常情况下分析Java虚拟机死锁比分析内存泄漏要容易的多。因为死锁发生时，JVM通常处于挂起状态(hang住了)，thread dump可以给出静态稳定的信息，查找死锁只需要查找有问题的线程。而内存泄漏的问题却很难界定，一个运行的JVM里有无数对象存在，只有写程序的人才知道哪些对象是垃圾，而哪些不是，而且对象的引用关系非常复杂，很难得到一份清晰的对象引用图。



Java虚拟机死锁发生时，从操作系统上观察，虚拟机的CPU占用率为零，很快会从top或prstat的输出中消失。这时你就可以收集thread dump了，Unix/Linux 下是kill -3 ，在Windows下可以在JVM的console窗口上敲Ctrl-Break。根据不同的设置，thread dump会输出到当前控制台上或应用服务器的日志里。



拿到java thread dump后，你要做的就是查找"waiting for monitor entry"的thread，如果大量thread都在等待给同一个地址上锁（因为对于Java，一个对象只有一把锁），这说明很可能死锁发生了。比如：





"service-j2ee" prio=5 tid=0x024f1c28 nid=0x125 waiting for monitor entry

[62a3e000..62a3f690]

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.IASNonSharedResourcePool.internalGetResource(IASNonS

haredResourcePool.java:625)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - waiting to

lock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.IASNonSharedResourcePool.getResource(IASNonSharedRes

ourcePool.java:520)

................



为了确定问题，常常需要在隔两分钟后再次收集一次thread dump，如果得到的输出相同，仍然是大量thread都在等待给同一个地址上锁，那么肯定是死锁了。



如何找到当前持有锁的线程是解决问题的关键。方法是搜索thread dump，查找"locked <0x965d8110>"， 找到持有锁的线程。





[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: "Thread-20" daemon prio=5 tid=0x01394f18

nid=0x109 runnable [6716f000..6716fc28]

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

java.net.SocketInputStream.socketRead0(Native Method)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

java.net.SocketInputStream.read(SocketInputStream.java:129)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at oracle.net.ns.Packet.receive(Unknown

Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.net.ns.DataPacket.receive(Unknown Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.net.ns.NetInputStream.read(Unknown Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.net.ns.NetInputStream.read(Unknown Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.net.ns.NetInputStream.read(Unknown Source)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:929)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.jdbc.ttc7.Ocommoncall.receive(Ocommoncall.java:106)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.jdbc.ttc7.TTC7Protocol.logoff(TTC7Protocol.java:396)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f47a0> (a

oracle.jdbc.ttc7.TTC7Protocol)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1518)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f4520> (a

oracle.jdbc.driver.OracleConnection)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.JdbcUrlAllocator.destroyResource(JdbcUrlAllocator.java:122)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.IASNonSharedResourcePool.destroyResource(IASNonSharedResourcePool.java:8

72)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(IASNonSharedResourcePool.java:1086)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x965d8110> (a

com.sun.enterprise.resource.IASNonSharedResourcePool)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

com.sun.enterprise.resource.IASNonSharedResourcePool$Resizer.run(IASNonSharedResourcePool.java:1178)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

java.util.TimerThread.mainLoop(Timer.java:432)

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at

java.util.TimerThread.run(Timer.java:382)



在这个例子里，持有锁的线程在等待Oracle返回结果，却始终等不到响应，因此发生了死锁。



如果持有锁的线程还在等待给另一个对象上锁，那么还是按上面的办法顺藤摸瓜，直到找到死锁的根源为止。



另外，在thread dump里还会经常看到这样的线程，它们是等待一个条件而主动放弃锁的线程。例如：



"Thread-1" daemon prio=5 tid=0x014e97a8 nid=0x80 in Object.wait() [68c6f000..68c6fc28]

at java.lang.Object.wait(Native Method)

- waiting on <0x95b07178> (a java.util.LinkedList)

at com.iplanet.ias.util.collection.BlockingQueue.remove(BlockingQueue.java:258)

- locked <0x95b07178> (a java.util.LinkedList)

at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:241)

at java.lang.Thread.run(Thread.java:534)



有时也会需要分析这类线程，尤其是线程等待的条件。



其实，Java thread dump并不只用于分析死锁，其它Java应用运行时古怪的行为都可以用thread dump来分析。



最后，在Java SE 5里，增加了jstack的工具，也可以获取thread dump。在Java SE 6里， 通过jconsole的图形化工具也可以方便地查找涉及object monitors 和java.util.concurrent.locks死锁。关于这方面的内容，请参见Mandy Chung的blog: http://weblogs.java.net/blog/mandychung/archive/2005/11/thread_dump_and_1.html

















如何确定在javacore或者Threaddump中应用服务器Web容器的常见线程状态







环境:

产品：WebSphere Application Server

版本：5.0.x,5.1.x

平台：平台无关



问题描述:

如何确定在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)









Weblogic 线程死锁





对于原因不明的hang或是响应慢，最根本的方法就是获取thread dump信息

对于windows系统，在运行java的窗口按Ctrl＋Break

对于unix系统，首先用ps找到运行weblogic的java进程的pid，然后执行kill –3 pid

JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出

为了方便获取thread dump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件

为了反映线程状态的动态变化，需要接连多次做thread dump，每次间隔10-20s





Weblogci 线程死锁

对于thread dump信息，主要关注的是线程的状态和其执行堆栈

线程的状态一般为三类

Runnable（R）：当前可以运行的线程

Waiting on monitor（CW）：线程主动wait

Waiting for monitor entry（MW）：线程等锁

一般关注的都是第一和第三种状态的线程

Cpu很忙则关注runnable的线程

Cpu闲则关注waiting for monitor entry的线程

一种典型的死锁是由于在server端应用（比如servlet）中请求由同一weblogic实例serve的资源

解决办法就是将该servlet放到另外的执行队列里去执行