解析Java虚拟机死锁的办法[Java编程]

到目前为止,我认为解析Java代码问题的最有效的工具仍旧是java thread dump,缘由是:

1.任何操作系统平台下都可以利用.

2.在大都情形下,可以在生产环境中利用.

3.和操作系统供应的工具相比,java thread dump给出的信息是直白的,直接对应到利用代码.

4.它对被解析的系统干扰很小,因此能反映真实的问题.而别的很多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.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死锁.