关于J2EE中死锁问题的研究

　　遇到死锁问题和锁定其他线程的锁的具体频率在很大程度上取决于数据库平台、硬件、数据库模式和查询。在使用基于锁的并发控制的数据库（如MSSQL）中，未提交的写操作会阻止读操作，而未提交的读操作会阻止写操作，使数据库更易出现死锁问题。在多版本并发控制(MVCC)数据库（如Oracle）中，未提交的写操作不阻止读操作——读操作仅查看旧版本数据行。这虽然会引入其他问题，但不会造成同样多的死锁机会。我们要让自己熟悉这些数据库锁定模式，并注意自己正在使用的类型。

　　在查找、修复以及避免数据库死锁方面，有一些很好的参考方法，但它们都不能彻底消除死锁的可能性。

　　跨资源死锁

　　当死锁情况不完全局限于数据库时，将更难找到它。数据库对占有和请求的锁有识别能力，所以能检测整个数据库中的死锁；此外，数据库事务在确定哪些东西是原子、哪些不是方面提供了一个良好的界线，所以能轻松地回滚事务，使其从死锁中恢复。其他环境（如Java虚拟机）中的死锁或可跨环境的死锁更加危险，因为环境不能（或没有）检测到这些死锁并尝试恢复。更糟糕的是，这些死锁会产生综合效果——如果两个线程占有某些资源集时出现死锁，则其他任何尝试访问其中一个资源的线程也将被阻塞，该线程已经获取的所有资源也被阻塞。这些死锁常常不易发现，但对常见模式有一定的了解将有助于识别和修复死锁问题。

　　当环境中出现可疑的死锁情况时，您就需要考虑一些问题了。这些问题的答案将说明您正在处理的情形是下列情形中的哪一种（如果有的话），并提供了修复以下问题的详细信息。要考虑的一些重要事项包括：

　　涉及什么线程，它们的调用堆栈是什么？这需要进行一些详细的分析，将实际的死锁线程从那些只是被死锁的线程阻塞了的线程中分离出来。