为什么两个线程会互相等待，导致程序“死锁”

在多线程环境下，两个或多个线程之所以会陷入“互相等待”的僵局，最终导致程序部分或全部功能“死锁”，其根本原因在于它们对共享资源的“申请”与“持有”顺序，形成了一个无法被打破的“循环依赖”。一个典型的死锁场景，其形成，必须同时满足四个缺一不可的“必要条件”，这些条件共同构成了死锁的“温床”，主要涵盖：源于多个线程对“共享资源”的并发访问、线程在获取锁的过程中形成了“循环等待”、每个线程都“持有”部分资源并“请求”其他资源、系统不允许“抢占”已被持有的资源、以及缺少统一的“资源获取顺序”。

其中，线程在获取锁的过程中形成了“循环等待”，是死锁现象最直观的“拓扑结构”。这意味着，线程A，成功地，锁住-了资源1，然后，它试图，去锁定资源2；而几乎在同一时刻，线程B，已经成功地，锁住了资源2，并反过来，试图，去锁定资源1。此时，A在等待B释放资源2，而B又在等待A释放资源1，两者，就如同在单行道上迎面相遇的两辆汽车，谁也不肯退让，最终，陷入了一个永恒的、无法被打破的等待循环。

一、问题的场景：一个经典的“十字路口”僵局

要直观地理解“死锁”，我们可以想象一个没有交通信号灯的、狭窄的十字路口。此时，有四辆汽车，分别从东、南、西、北四个方向，同时到达了路口的中心，并且，每一辆车，都想“左转”。

东侧的汽车，占据了路口的东南角，它的下一步，需要西侧汽车所占据的西南角空出来。

南侧的汽车，占据了路口的西南角，它的下一步，需要北侧汽车所占据的西北角空出来。

西侧的汽车，占据了路口的西北角，它的下一步，需要东侧汽车所占据的东北角空出来。

北侧的汽车，占据了路口的东北角，它的下一步，需要南侧汽车所占据的东南角空出来。

此时，一个完美的“循环等待”就形成了。每一辆车，都在等待下一辆车移动，但没有任何一辆车，能够先行移动。整个路口的交通，因此，完全瘫痪。

在多线程编程中，“汽车”，就对应着“线程”；而那些被汽车所占据的、有限的“路口空间”，就对应着被线程所竞争的、唯一的“共享资源”（例如，一个内存对象、一个数据库连接、或一个文件句柄）。

计算机科学领域的先驱艾兹赫尔·戴克斯特拉，曾提出了一个著名的“哲学家就餐问题”，这正是对“死锁”问题，最早的、也最深刻的理论模型之一。它揭示了，即便每一个独立的个体（哲学家/线程）的行为，都是完全理性的，但如果缺乏一个更高层级的、系统性的“协同规则”，整个系统，也可能，会陷入一种“集体非理性”的瘫痪状态。

二、死锁的“科学”定义：四个“必要条件”

一个程序，要发生“死锁”，并非一件“随机”的事件。根据计算机科学家科夫曼的总结，死锁的发生，必须，且必然地，同时满足以下四个“必要条件”。只要我们，能够在程序的设计中，有策略地，打破其中任何一个条件，死锁，就将永远不会发生。

1. 互斥条件 这个条件，指的是，一个资源，在同一时刻，只能被一个线程所“独占”使用。当一个线程，获取了该资源后，在它主动“释放”之前，其他任何试图获取该资源的线程，都只能进入“等待”状态。这，正是我们日常使用的“锁”机制（如互斥锁）的本质。这个条件，在大多数并发场景下，是为了“保障数据一致性”所必需的，通常，无法被打破。

2. 持有并等待条件 这个条件，指的是，一个线程，在已经“持有”了至少一个资源的同时，又发起了，对另一个资源的“请求”，而这个新的请求，导致了它进入“等待”状态。简而言之，就是“吃着碗里的，看着锅里的”。

3. 不可抢占条件 这个条件，指的是，一个线程，已经获得的资源，在它自愿“释放”之前，不能被任何其他的线程，或操作系统，所强制性地“剥夺”或“抢占”。

4. 循环等待条件 这是最核心的、也是最终形成“僵局”的条件。它指的是，在系统中，存在一个由两个或多个线程，所组成的“等待链”，并且，这个链条，形成了一个闭环。

例如，线程A，在等待线程B所持有的资源；线程B，又在等待线程C所持有的资源；而线程C，最终，又在等待线程A所持有的资源。

只有当这四个条件，如同四块拼图，在某个不幸的、特定的执行时序下，完美地，拼接在了一起时，死锁，才会真正地，降临。

三、“犯罪现场”重现：一个经典的死锁代码示例

让我们通过一个最经典的“银行账户转账”的例子，来在代码层面，重现一次“死锁”的完整“犯罪过程”。

1. 场景设置

我们有两个银行账户对象：账户A（初始余额5000元）和 账户B（初始余额5000元）。

我们有两个线程：线程1，负责执行“从账户A，向账户B，转账100元”的操作；线程2，则负责执行“从账户B，向账户A，转账200元”的操作。

为了保证转账操作的“原子性”，我们在进行转账时，必须同时锁定“转出账户”和“转入账户”，以防止在操作过程中，有其他线程，来干扰这两个账户的余额。

2. 一个会导致死锁的代码实现（以Java为例）

Java

public class BankTransfer {
    public void transfer(Account fromAccount, Account toAccount, int amount) {
        // 先锁定“转出账户”
        synchronized (fromAccount) {
            System.out.println(Thread.currentThread().getName() + " 锁定了 " + fromAccount.getName());
            
            // 为了“创造”出死锁的条件，我们在这里，让线程稍微“睡”一下
            try { Thread.sleep(100); } catch (InterruptedException e) {}

            System.out.println(Thread.currentThread().getName() + " 尝试锁定 " + toAccount.getName());
            // 再锁定“转入账户”
            synchronized (toAccount) {
                // ... 执行实际的转账操作 ...
            }
        }
    }
}

3. “致命的执行时序” 现在，让我们来“导演”一场由操作系统线程调度所引发的“完美犯罪”：

时刻1：线程1启动，调用transfer(账户A, 账户B, 100)。它成功地，获取到了账户A的锁。打印出：“线程1 锁定了账户A”。

时刻2：线程1，开始执行Thread.sleep(100)。此时，操作系统，完全有可能，进行一次线程切换，将中央处理器的使用权，暂时地，从线程1，切换给线程2。

时刻3：线程2启动，调用transfer(账户B, 账户A, 200)。它成功地，获取到了账户B的锁。打印出：“线程2 锁定了账户B”。

时刻4：线程2，也开始执行Thread.sleep(100)。

时刻5：假设，线程1的睡眠时间结束，操作系统，将控制权，交还给线程1。线程1，继续执行，打印出：“线程1 尝试锁定账户B”。

时刻6：线程1，试图，去获取账户B的锁。然而，此时，账户B的锁，正被线程2所“持有”。因此，线程1，被迫进入“等待”状态。

时刻7：假设，线程2的睡眠时间也结束了，操作系统，将控制权，交还给线程2。线程2，继续执行，打印出：“线程2 尝试锁定账户A”。

时刻8：线程2，试图，去获取账户A的锁。然而，此时，账户A的锁，正被线程1所“持有”。因此，线程2，也被迫进入“等待”状态。 最终僵局：线程1在等待线程2，而线程2又在等待线程1。**“循环等待”**条件达成。两者，都将永远地，停留在“等待”状态，程序，也就因此，而“死锁”。

四、解决方案一：“预防”死锁

预防死锁的核心思想，是通过“代码设计”层面的约束，来人为地，破坏掉死锁四个必要条件中的、至少一个。

1. 破坏“持有并等待”条件 一种策略是，要求一个线程，在开始执行前，必须“一次性地、原子性地”，获取到它所需要的“所有”资源的锁。如果无法一次性获取到所有锁，那么，它就必须，先把自己已经拿到的锁，都“释放”掉，然后，过一段时间，再重新尝试。这种策略，在实践中，实现起来比较复杂，且可能会降低并发性能。

2. 破坏“循环等待”条件（最常用、最有效的策略） 这是在应用层编程中，预防死锁的、最常用、也最有效的策略。其核心思想是，对系统中的所有“共享资源”（或“锁”），都进行一次“全局的、唯一的、强制性的排序”。然后，在我们的编码规范中，严格地，规定：“任何一个线程，在需要获取多个锁时，都必须，严格地，按照这个“全局排序”的顺序，来依次获取。”

重构银行账户案例：我们可以，为每一个“账户”对象，都赋予一个唯一的、不可变的ID（例如，银行卡号）。然后，我们规定，在进行转账、需要同时锁定两个账户时，永远，都必须，先锁定那个ID“较小”的账户，再锁定ID“较大”的账户。

修正后的代码：Javapublic void transfer(Account fromAccount, Account toAccount, int amount) { Account firstLock = fromAccount; Account secondLock = toAccount; // 通过比较ID，来决定锁的获取顺序 if (fromAccount.getId() > toAccount.getId()) { firstLock = toAccount; secondLock = fromAccount; } synchronized (firstLock) { synchronized (secondLock) { // ... 执行转账 ... } } }

通过这种方式，无论，是线程1（A->B），还是线程2（B->A），它们在获取锁时，都必然会，遵循同一个、全局统一的顺序。这就从根本上，破坏了“循环等待”的形成条件。

五、解决方案二：“避免”与“检测”

除了在编码层面进行“预防”，在更复杂的系统（如操作系统、数据库）中，还会采用更高级的“避免”和“检测”策略。

死锁避免：系统，通过一些复杂的算法（如“银行家算法”），在每一次的“资源分配”之前，都进行一次“安全检查”，预测本次分配，是否有可能，导致未来进入“不安全”的、可能发生死锁的状态。如果可能，就拒绝本次分配。

死锁检测与恢复：系统，允许死锁的发生。但它，会有一个独立的“监控”线程，来周期性地，检查系统的“资源分配图”，看是否存在“环路”。一旦检测到环路（即死锁），系统，就会采取“恢复”措施，例如，强制性地，“剥夺”某个线程的资源，或者，直接“终止”掉某个处于死锁链中的线程，来打破这个循环。

六、在流程与规范中“防范”

编码规范：团队的《编码规范》中，必须，有专门的、详尽的章节，来规定“并发编程的最佳实践”，特别是，必须，为系统中所有需要被加锁的共享资源，都定义出清晰的、唯一的“加锁顺序”。

代码审查：并发相关的缺陷，是所有类型的缺陷中，最难通过“测试”来复现和发现的。因此，严格的、由经验丰富的开发者，所执行的“代码审查”，是发现潜在“竞态条件”和“死锁”问题的、最重要的“人工防线”。

常见问答 (FAQ)

Q1: “死锁”和“活锁”有什么区别？

A1: 死锁，是多个线程，相互“永久阻塞”，都在等待对方释放资源，线程，处于“不活动”状态。而“活锁”，则是多个线程，都在“积极地”行动，但却因为不断地相互“谦让”和重试，而导致，所有人都无法取得实质性进展，线程，是“活动的”，但却在做“无用功”。

Q2: 发生死锁后，程序一定会崩溃吗？

A2: 不一定。死锁，通常，只会导致，那些参与了“循环等待”的特定线程，被永久地“挂起”。如果，程序的其他部分，不依赖于这些被挂起的线程，那么，程序，可能会继续运行，只是，其部分功能，会表现为“无响应”或“卡死”。

Q3: 是不是只要用了多线程，就总是有死锁的风险？

A3: 不是。只有当你的多线程程序，同时满足了“互斥”、“持有并等待”、“不可抢占”和“循环等待”这全部四个条件时，才有可能发生死锁。如果你的线程之间，不共享任何资源，或者，你采用了无锁的并发编程技术，那么，就不会有死锁的风险。

Q4: 如何在程序已经卡死的情况下，判断它是否发生了死锁？

A4: 最专业的做法，是使用你所用语言或平台提供的“线程转储”工具（例如，Java的jstack命令）。这个工具，可以生成一份，在当前瞬间，所有线程的“状态快照”。通过分析这份快照，你可以清晰地看到，哪些线程，正处于“等待锁”的状态，以及，它们分别，在等待哪个线程所持有的锁，从而，精准地，定位到“循环等待”的链条。