关于J2EE中死锁问题的研究

　　大多数重要的应用程序都涉及高度并发性和多个抽象层。并发性与资源争用有关，并且是导致死锁问题增多的因素之一。多个抽象层使隔离并修复死锁环境的工作变得更加困难。

　　通常，当同时执行两个或两个以上的线程时，如果每个线程都占有一个资源并请求另一个资源，这时就会出现死锁情况。因为如果一个线程不能获取资源，则所有线程都不能继续执行，我们称那个特定的线程被阻塞；如果每个线程都由于同组中另一个线程所占有的资源而被阻塞，我们就称这个线程组被死锁。

　　在本文中，我们将讨论发生在典型的重要J2EE应用程序中的两大类死锁情况：“简单”数据库死锁和跨资源死锁。虽然我们的讨论基于J2EE平台，但也适用于其他技术平台。

　　数据库死锁

　　在数据库中，如果一个连接占用了另一个连接所需的数据库锁，则它可以阻塞另一个连接。如果两个或两个以上的连接相互阻塞，则它们都不能继续执行，这种情况称为死锁。

　　数据库死锁问题不易处理，这是因为涉及到的锁定通常不是显式的。通常，对数据行进行隐式更新时，需要锁定该数据行，执行更新，然后在提交或回滚封闭事务时释放锁。由于数据库平台、配置的隔离级以及查询提示的不同，获取的锁可能是细粒度或粗粒度的，它会阻塞（或不阻塞）其他对同一数据行、表或数据库的查询。

　　获取的锁依赖于内部生成的查询计划。当数据大小和分步随时间发生变化时，该计划也可能改变。这样在一个环境中获取一组锁的查询可以尝试在另一个环境中获取一组完全不同的锁。必要时，数据库可以随意地增加它的锁。例如，数据库可能会选择锁定整页，而不是锁定同一数据页中的10个数据行，这会阻塞对无需锁定的数据行的读写权限。