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

对J2EE中死锁问题的研究(2)

跨资源死锁

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

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

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

这种死锁情况总是在特定的代码路径中出现（每次执行这些特定的操作时），还是依赖于两个或两个以上同时执行的代码路径呢？

涉及的数据库连接是什么？每个连接占有的数据库锁是什么？每个连接尝试获取的数据库锁是什么？每个数据库连接响应的Java虚拟机线程是什么？下一小节介绍了三种常见的发生跨资源死锁的情形。

跨资源死锁情形之1：客户端的增加导致资源池耗尽

我们要介绍的第一种死锁情形是单纯由于负载而造成的，即资源池太小，而每个线程需要的资源超过了池中的可用资源。例如，考虑一个使用数据库连接的EJB调用，执行一个嵌套的EJB调用（使用同一连接池中不同的数据库连接）。例如，如果该嵌套的EJB调用声明为RequiresNew，就会出现死锁情形。

在正常负载或者有足够大小的连接池的情况下，EJB调用将从池中获取一个数据库连接，然后调用嵌套的EJB。嵌套的EJB调用将从池中获取另一个数据库连接，提交内部事务，然后向池返回连接。外部EJB调用将提交自己的事务，并向池返回其连接。

但是，假设连接池最多有10个连接，同时有10个对外部EJB的并发调用。这些线程中每一个都需要一个数据库连接用来清空池。现在，每个线程都执行嵌套的EJB调用（需要获取第二个数据库连接）。则所有线程都不能继续，但又都不放弃自己的第一个数据库连接。这样，10个线程都将被死锁。

如果研究此类死锁情形，会发现线程转储中有大量等待获取资源的线程，以及同等数量的空闲且未阻塞的活动数据库连接。当应用程序死锁时，如果可以在运行时检测连接池，应该能确认连接池实际上已空。

修复此类死锁的方法包括：增加连接池的大小或者重构代码，以便单个线程不需要同时使用很多数据库连接。如果单线程需要的最大数据库连接数为M，且可能的最大并发调用数为N，则要避免此问题，在池中所需的最小连接数为(N*(M01))+1。或者可以设置内部EJB调用以使用不同的连接池，即使外部调用的连接池为空，内部调用也能使用自己的连接池继续。

跨资源死锁情

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!