三. 如何检测死锁的根源
Java并不提供对死锁的检测机制。笔者认为常用分析Java代码问题的最有效的工具仍然是java thread dump。当死锁发生时，JVM通常处于挂起状态，thread dump可以给出静态稳定的信息，查找死锁只需要查找有问题的线程。Java虚拟机死锁发生时，从操作系统上观察，虚拟机的CPU占用率为零，很快会从top或prstat的输出中消失。这时可以收集thread dump，查找"waiting for monitor entry"的thread，如果大量thread都在等待给同一个地址上锁（因为对于Java，一个对象只有一把锁），这说明很可能死锁发生了。
为了确定问题，笔者建议在隔几分钟后再次收集一次thread dump，如果得到的输出相同，仍然是大量thread都在等待给同一个地址上锁，那么肯定是死锁了。如何找到当前持有锁的线程是解决问题的关键。一般方法是搜索thread dump，查找"locked，找到持有锁的线程。如果持有锁的线程还在等待给另一个对象上锁，那么还是按上面的办法顺藤摸瓜，直到找到死锁的根源为止。
另外，在thread dump里还会经常看到这样的线程，它们是等待一个条件而主动放弃锁的线程。有时也需要分析这类线程，尤其是线程等待的条件。
四. 几种常见死锁及对策
解决死锁没有简单的方法，这是因为线程产生死锁都各有各的原因，而且往往具有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在这里中，笔者将讨论开发过程常见的4类典型的死锁和解决对策。
(1)数据库死锁
在数据库中，如果一个连接占用了另一个连接所需的数据库锁，则它可以阻塞另一个连接。如果两个或两个以上的连接相互阻塞，则它们都不能继续执行，这种情况称为数据库死锁。
数据库死锁问题不易处理，通常数据行进行更新时，需要锁定该数据行，执行更新，然后在提交或回滚封闭事务时释放锁。由于数据库平台、配置的隔离级以及查询提示的不同，获取的锁可能是细粒度或粗粒度的，它会阻塞（或不阻塞）其他对同一数据行、表或数据库的查询。基于数据库模式，读写操作会要求遍历或更新多个索引、验证约束、执行触发器等。每个要求都会引入更多锁。此外，其他应用程序还可能正在访问同一数据库模式中的某些对象，并获取不同应用程序所具有的锁。
所有这些因素综合在一起，数据库死锁几乎不可能被消除了。值得庆幸的是，数据库死锁通常是可恢复的：当数据库发现死锁时，它会强制销毁一个连接（通常是使用最少的连接），并回滚其事务。这将释放所有与已经结束的事务相关联的锁，至少允许其他连接中有一个可以获取它们正在被阻塞的锁。
由于数据库具有这种典型的死锁处理行为，所以当出现数据库死锁问题时，数据库常常只能重试整个事务。当数据库连接被销毁时，会抛出可被应用程序捕获的异常，并标识为数据库死锁。如果允许死锁异常传播到初始化该事务的代码层之外，则该代码层可以启动一个新事务并重做先前所有工作。
当出现问题就重试，由于数据库可以自由地获取锁，所以几乎不可能保证两个或两个以上的线程不发生数据库死锁。此方法至少能保证在出现某些数据库死锁情况时，应用程序能正常运行。
1
