All things are difficult before they are easy. 没有软件的裸机是一具僵尸,没有硬件的软件是一个幽灵。2012,专注于Linux和C语言,关注自动化、性能测试,关注开源社区和开源测试工具、方法,尝试测试团队管理!
ThreadDump简介
上一篇 /
下一篇 2010-02-11 23:33:07
/ 个人分类:Java
原本也没听说过ThreadDump的概念,直到前几天,公司的BOPS系统
老是OutOfMemory,后来通过ThreadDump,高手们才找到了原因。我在想,ThreadDump肯定是个了不起的东东,于是网上学习了解
了一下,并自己本机尝试了将ThreadDump信息打印了出来。Thread
Dump是非常有用的诊断Java应用问题的工具,每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力。虽然各个
Java虚拟机thread dump打印输出格式上略微有一些不同,但是Thread
dumps出来的信息包含线程;线程的运行状态、标识和调用的堆栈;调用的堆栈包含完整的类名,所执行的方法,如果可能的话还有源代码的行数。Thread Dump特点:能在各种操作系统下使用;能在各种Java应用服务器下使用
;可以在生产环境下使用而不影响系统的性能;可以将问题直接定位到应用程序的代码行上
。Thread Dump能诊断的问题包括:查找内存泄露,常见的是程序里load大量的数据到缓存;发现死锁线程
。产生ThreadDump堆栈信息的方法:1. UNIX/LinuxKill -3 PIDPID通过下面方法获取ps -efHl | grep 'java' **. **2. Windows直接对MSDOS窗口的程序按Ctrl-breakSun JVM的常见线程状态:对于thread dump信息,主要关注的是线程的状态和其执行堆栈线程的状态一般为三类Runnable(R):当前可以运行的线程Waiting on monitor(CW):线程主动waitWaiting for monitor entry(MW):线程等锁一般关注的都是第一和第三种状态的线程Cpu很忙则关注runnable的线程Cpu闲则关注waiting for monitor entry的线程如何分析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 <JVM pid>
,在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: atcom.sun.enterprise.resource.IASNonSharedResourcePool.internalGetResource(IASNonSharedResourcePool.java:625)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - waiting tolock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atcom.sun.enterprise.resource.IASNonSharedResourcePool.getResource(IASNonSharedResourcePool.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=0x01394f18nid=0x109 runnable [6716f000..6716fc28][27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atjava.net.SocketInputStream.socketRead0(Native Method)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atjava.net.SocketInputStream.read(SocketInputStream.java:129)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at oracle.net.ns.Packet.receive(UnknownSource)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.net.ns.DataPacket.receive(Unknown Source)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.net.ns.NetInputStream.getNextPacket(Unknown Source)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.net.ns.NetInputStream.read(Unknown Source)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.net.ns.NetInputStream.read(Unknown Source)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.net.ns.NetInputStream.read(Unknown Source)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:929)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.jdbc.ttc7.Ocommoncall.receive(Ocommoncall.java:106)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.jdbc.ttc7.TTC7Protocol.logoff(TTC7Protocol.java:396)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f47a0> (aoracle.jdbc.ttc7.TTC7Protocol)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atoracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1518)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f4520> (aoracle.jdbc.driver.OracleConnection)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atcom.sun.enterprise.resource.JdbcUrlAllocator.destroyResource(JdbcUrlAllocator.java:122)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atcom.sun.enterprise.resource.IASNonSharedResourcePool.destroyResource(IASNonSharedResourcePool.java:872)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atcom.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(IASNonSharedResourcePool.java:1086)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x965d8110> (acom.sun.enterprise.resource.IASNonSharedResourcePool)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atcom.sun.enterprise.resource.IASNonSharedResourcePool$Resizer.run(IASNonSharedResourcePool.java:1178)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atjava.util.TimerThread.mainLoop(Timer.java:432)[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: atjava.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死锁。参考文档:http://lzmhehe.javaeye.com/blog/335526http://sesame.javaeye.com/blog/428012
相关阅读:
- Java中的TCP/UDP网络通信编程 (51testing, 2010-2-02)
- 浅论Java中接口的使用 (51testing, 2010-2-02)
- JSP自定义标签的编写 (51testing, 2010-2-03)
- JSP文件下载——流方式 (51testing, 2010-2-04)
- Stuts2中tree的实现 (51testing, 2010-2-05)
- 戏说Java web开发中的listener和filter (51testing, 2010-2-08)
- Java 终止函数深度分析 (51testing, 2010-2-09)
- JavaScript跨域问题的解决方案 (fishy, 2010-2-10)
- 使用Java构建稳定可靠的QTP自动化测试 (fishy, 2010-2-10)
- JDK和两个JRE (smile665, 2010-2-11)
收藏
举报
TAG:
java
ThreadDump
Dump