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死锁。
以上就是java虚拟机如何实现死锁的详细内容。