在许多应用中进程需要以独占的方式访问资源，当操作系统允许多个进程并发执行时可能会出现进程永远被阻塞现象，如两个进程分别等待对方所占的资源，于是两者都不能执行而处于永远等待状态，此现象称为死锁。死锁通常被定义为：如果一个进程集合中的每个进程都在等待只能由此集合中的其他进程才能引发的事件，而无限期陷入僵持的局面称为死锁。

死锁的规范定义：集合中的每一个进程都在等待只能由本集合中的其他进程才能引发的事件，那么该组进程是死锁的。

一种情形，此时执行程序中两个或多个进程发生永久堵塞(等待)，每个进程都在等待被其他进程占用并堵塞了的资源。例如，如果进程A锁住了记录1并等待记录2，而进程B锁住了记录2并等待记录1，这样两个进程就发生了死锁现象。

计算机系统中，如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。

在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。例如：事务A 获取了行 1 的共享锁。事务 B 获取了行 2 的共享锁。

排他锁，等待事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。

排他锁，等待事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。

事务 B 完成之后事务 A 才能完成，但是事务 B 由事务 A 阻塞。该条件也称为循环依赖关系：事务 A 依赖于事务 B，事务 B 通过对事务 A 的依赖关系关闭循环。

除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。Microsoft SQL Server 数据库引擎死锁监视器定期检查陷入死锁的任务。如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。这样，其他任务就可以完成其事务。对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。

在应用程序中使用特定编码约定可以减少应用程序导致死锁的机会。有关详细信息，请参阅将死锁减至最少。

死锁经常与正常阻塞混淆。事务请求被其他事务锁定的资源的锁时，发出请求的事务一直等到该锁被释放。默认情况下，除非设置了 LOCK_TIMEOUT，否则 SQL Server 事务不会超时。因为发出请求的事务未执行任何操作来阻塞拥有锁的事务，所以该事务是被阻塞，而不是陷入了死锁。最后，拥有锁的事务将完成并释放锁，然后发出请求底事务将获取锁并继续执行。

不只是关系数据库管理系统，任何多进程系统上都会发生死锁，并且对于数据库对象的锁之外的资源也会发生死锁。例如，多进程操作系统中的一个进程要获取一个或多个资源(例如，内存块)。如果要获取的资源当前为另一进程所拥有，则第一个进程可能必须等待拥有进程释放目标资源。这就是说，对于该特定资源，等待进程依赖于拥有进程。在数据库引擎实例中，当获取非数据库资源(例如，内存或进程)时，会话会死锁。

在示例中，对于 Part表锁资源，事务 T1 依赖于事务 T2。同样，对于 Supplier表锁资源，事务 T2 依赖于事务 T1。因为这些依赖关系形成了一个循环，所以在事务 T1 和事务 T2 之间存在死锁。

当表进行了分区并且 ALTER TABLE 的 LOCK_ESCALATION 设置设为 AUTO 时也会发生死锁。当 LOCK_ESCALATION 设为 AUTO 时，通过允许数据库引擎在 HoBT 级别而不是 TABLE 级别锁定表分区会增加并发情况。但是，当单独的事务在某个表中持有分区锁并希望在其他事务分区上的某处持有锁时，会导致发生死锁。通过将 LOCK_ESCALATION 设为 TABLE 可以避免这种类型的死锁，但此设置会因强制某个分区的大量更新以等待某个表锁而减少并发情况。

看到这里，相信我们已经弄清楚了什么是Java死锁，死锁在Java中的应用还是非常广泛的，我们可以观看动力节点在线的免费视频课程学习更多的Java死锁相关知识。