[转帖]ThreadDump简介_Tomcat, WebLogic及J2EE讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方技术论坛-国内领先的Weblogic、Tuxedo中间件技术论坛
联动北方-国内领先的云技术服务提供商
»  游客             当前位置：  论坛首页 »  自由讨论区 »  Tomcat, WebLogic及J2EE讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3632 | 回复: 0   主题： [转帖]ThreadDump简介        下一篇 
    本主题由 zhou 于 2012-11-30 14:24:04 取消精华
zhou
注册用户
等级：中校
经验：2210
发帖：125
精华：6
注册：2012-11-19
状态：离线
发送短消息息给zhou 加好友    发送短消息息给zhou 发消息
发表于： IP：您无权察看 2012-11-26 12:43:52 | [全部帖] [楼主帖] 楼主
ThreadDump简介
原本也没听说过 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/Linux

Kill -3 PID


PID通过下面方法获取

 ps -efHl | grep 'java' **. **
2.
Windows


直接对MSDOS窗口的程序按Ctrl-break
Sun JVM的常见线程状态：
对于thread dump信息，主要关注的是线程的状态和其执行堆栈
线程的状态一般为三类
Runnable（R）：当前可以运行的线程
Waiting on monitor（CW）：线程主动wait
Waiting 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: 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.IASNonSharedResourcePoolResizer.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.FastThreadPoolThreadPoolThread.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/335526
http://sesame.javaeye.com/blog/428012


赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码： 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论

Weblogic中间件技术论坛

 |

Tuxedo中间件技术论坛

 |

数据库论坛

 |

Java论坛

 |

Linux/unix论坛

 |

网站地图


Powered by LandingBJ     @ 2008-2018     联动北方   
京ICP证号090597    京ICP备案09017624号    京公网安备110112000093号    
400-810-2327     Email：service@landingbj.com   

Powered by landingbj @ 2008-2015 联动北方
京ICP证号090597 京ICP备案09017624号 京公网安备110112000093号
86-27-87056338 Email：service@landingbj.com