死锁是什么？如何预防与排查方法

什么是死锁？如何预防与排查？本文深入探讨了死锁的定义、成因以及应对策略，旨在帮助开发者有效避免和解决这一并发难题。死锁是指两个或多个进程因争夺资源而相互等待，导致程序无法继续执行的僵局。理解死锁的四大必要条件——互斥、占有并等待、不可抢占和循环等待，是预防死锁的关键。文章详细介绍了资源有序分配、超时机制、避免持有并等待、减小锁粒度等实用策略，以降低死锁发生的概率。一旦发生死锁，可借助日志监控、线程dump或数据库死锁日志分析等待图，定位循环等待链，并选择牺牲者回滚或终止进程，从根本上优化事务设计与并发控制逻辑，从而提升系统的稳定性和可靠性。

死锁的四大必要条件是互斥、占有并等待、不可抢占和循环等待，理解这些条件有助于从根源上预防死锁。通过资源有序分配、超时机制、避免持有并等待、减小锁粒度等策略可有效降低死锁发生概率；一旦发生，需借助日志监控、线程dump或数据库死锁日志分析等待图，定位循环等待链，选择牺牲者回滚或终止进程，并从根本上优化事务设计与并发控制逻辑。

死锁，说白了，就是两个或多个进程（或者线程，在数据库里就是事务）在争夺资源时，谁也得不到自己想要的，大家就这么僵持住了，谁也动不了，形成了一个循环等待的局面。这就像两辆车在单行道上迎面相遇，谁也不肯倒车，结果谁也过不去，整个交通就堵死了。避免和排查死锁，核心在于理解它的发生机制，然后从源头预防，或者在发生后能迅速定位并解除。

解决方案

处理死锁，我的经验是，预防远胜于治疗。我们不能指望每次都能完美地避免它，但至少要让它出现的概率降到最低。这需要我们在设计系统时就引入“死锁意识”。它不仅仅是技术问题，更是一种系统架构和并发控制的哲学。很多时候，死锁的根源在于我们对共享资源的管理不够精细，或者说，对并发场景的复杂性预估不足。所以，解决方案的起点，是深入理解并发，然后通过一系列策略去限制那些可能导致死锁的条件。

死锁的四大必要条件是什么？为什么理解它们至关重要？

谈到死锁，就不得不提它的四大“罪魁祸首”，也就是所谓的Coffman条件：互斥、占有并等待、不可抢占、循环等待。这四条，只要有一条不满足，死锁就不会发生。理解它们，对于我们从根本上预防死锁，简直是太重要了。

1. 互斥（Mutual Exclusion）： 这是最基础的。资源是独占的，同一时间只能有一个进程使用。如果资源可以共享（比如只读文件），那自然也就不会有争抢，死锁也就无从谈起。但问题是，很多资源，比如打印机、数据库的行锁，它们天生就是互斥的。我们不能打破这个条件，所以只能从其他方面入手。

2. 占有并等待（Hold and Wait）： 一个进程在持有至少一个资源的同时，又去请求其他被别的进程持有的资源，并且在等待这些新资源释放。这就像一个人手里拿着A，又想去拿B，但B在别人手里，同时那个“别人”可能也想拿A。这种“手里有粮，心里发慌”的状态，是死锁的温床。

3. 不可抢占（No Preemption）： 已经分配给一个进程的资源，在没有使用完毕之前，不能被强制性地从该进程手中抢走。如果资源可以被抢占，那么当一个进程等待另一个资源时，它可以暂时释放自己持有的资源，从而打破僵局。但实际中，很多资源（比如CPU，或者某些操作系统锁）是不允许随意抢占的，这使得问题变得棘手。

4. 循环等待（Circular Wait）： 这是最直接的死锁体现。存在一个进程链P1, P2, ..., Pn，P1等待P2持有的资源，P2等待P3持有的资源，...，Pn等待P1持有的资源。形成了一个闭环。一旦这个环路出现，基本上就宣告死锁了。

理解这四点，不是为了死记硬背，而是为了在设计并发系统时，能有意识地去检查，我们是不是在无意中满足了所有这些条件。只要我们能想办法打破其中任何一个，死锁的风险就会大大降低。

在实际开发中，我们有哪些策略可以有效避免死锁？

在实战中，避免死锁更多的是一种艺术，一种对系统并发行为的预判和控制。我个人觉得，最实用的策略往往是结合多种手段，而不是寄希望于某一种银弹。

1. 资源有序分配（Resource Ordering）： 这是最经典也最有效的方法之一。我们给所有可能引起竞争的资源（比如数据库中的表、程序中的锁对象）分配一个全局的顺序。然后，所有进程在请求资源时，都必须按照这个顺序来请求。例如，如果你的程序需要同时锁定资源A和资源B，那么所有需要同时锁定这两个资源的线程都必须先锁A，再锁B。这样就打破了“循环等待”条件。如果一个线程先锁B再锁A，就可能造成死锁。当然，实际操作中，这个“顺序”可能需要很精心的设计，尤其是在复杂的系统中。

2. 引入超时机制（Timeouts）： 当一个进程尝试获取一个锁时，设置一个超时时间。如果在这个时间内未能获取到锁，就放弃本次尝试，释放已经持有的资源，然后稍等片刻再重试。这本质上是打破了“占有并等待”的条件，因为它允许进程在等待资源时，主动放弃已持有的资源。在数据库事务中，这是很常见的策略，比如MySQL的innodb_lock_wait_timeout。代码层面，Java的ReentrantLock提供了tryLock(long timeout, TimeUnit unit)方法，就是这种思路的体现。

ReentrantLock lockA = new ReentrantLock();
ReentrantLock lockB = new ReentrantLock();

// 线程1
if (lockA.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        if (lockB.tryLock(100, TimeUnit.MILLISECONDS)) {
            try {
                // 执行业务逻辑
            } finally {
                lockB.unlock();
            }
        } else {
            // 获取lockB超时，释放lockA并重试
            System.out.println("Thread 1: Failed to acquire lockB, releasing lockA.");
        }
    } finally {
        lockA.unlock();
    }
} else {
    // 获取lockA超时，重试
    System.out.println("Thread 1: Failed to acquire lockA.");
}

3. 避免一次性请求所有资源（Avoid Hold and Wait）： 尽量让一个进程在开始执行之前，就一次性地请求所有它需要的资源。如果不能全部获取，就一个都不获取。这同样是打破“占有并等待”条件。但这种方式在实际中很难完全实现，因为它要求我们能提前预知所有资源需求，并且资源的分配可能导致资源利用率不高。

4. 减小锁的粒度，缩短锁的持有时间： 这不是直接避免死锁的策略，但能显著降低死锁发生的概率。锁定的资源范围越小，持有时间越短，与其他进程冲突的可能性就越小。比如，在数据库中，尽量使用行锁而不是表锁；在代码中，只在真正需要同步的关键代码块上加锁。

5. 死锁检测与恢复（Deadlock Detection and Recovery）： 这是一种事后处理的策略，不是预防。系统允许死锁发生，但会周期性地检查是否存在死锁，一旦发现，就采取措施解除它，比如回滚一个或多个事务，或者终止一个进程。数据库系统通常内置了死锁检测机制。

当死锁发生时，如何高效地进行排查与解决？

死锁一旦发生，那可是真真切切的生产事故，尤其是在高并发的系统中，它可能导致服务停滞。高效的排查和解决能力，这时候就显得尤为关键。

1. 监控与日志： 这是第一道防线。很多数据库系统（如SQL Server, MySQL InnoDB）都有内置的死锁检测器，它们会将死锁信息记录到错误日志中，或者通过特定的事件监控工具暴露出来。比如，MySQL的SHOW ENGINE INNODB STATUS命令，会输出最近一次死锁的详细信息，包括涉及的事务、锁定的资源、等待的资源等，这简直是排查死锁的“金矿”。

-- MySQL InnoDB 死锁信息
SHOW ENGINE INNODB STATUS\G

对于Java应用，如果线程被死锁，我们可以通过jstack工具生成线程dump，分析线程堆栈信息。在dump文件中，你会看到线程的状态（比如WAITING (on object monitor)），以及它们正在等待的锁和已经持有的锁。如果存在循环等待，jstack甚至能直接标记出“Found one Java-level deadlock”。

jstack <pid> > thread_dump.txt

2. 分析死锁图： 无论是数据库日志还是jstack输出，它们的核心都是为了帮助我们构建一个“等待图”或“死锁图”。通过这个图，我们可以清晰地看到哪个进程（或线程）持有了哪个资源，又在等待哪个资源，从而找出形成循环等待的那个闭环。理解这个图，是解决问题的关键一步。

3. 识别“牺牲者”（Victim）： 当死锁发生时，系统通常会选择一个或多个进程作为“牺牲者”来终止或回滚，以打破死锁。选择牺牲者的原则通常是成本最小化，比如选择已经执行时间最短、持有资源最少或者回滚代价最小的事务。在排查时，我们需要识别出哪个事务被回滚了，以及它为什么被选中。

4. 解决策略：

• 手动干预： 在紧急情况下，可以手动终止涉嫌死锁的进程或回滚事务。但这通常是治标不治本，而且可能导致数据不一致，需要谨慎。
• 代码或设计层面调整： 找到死锁的根本原因后，最彻底的解决办法是修改代码或数据库设计，应用前面提到的避免死锁的策略（如资源有序分配、超时机制、减小锁粒度）。这才是釜底抽薪。
• 优化事务设计： 确保事务尽可能短，减少事务持有的锁的数量和时间。复杂的业务逻辑可以考虑拆分成更小的、独立的事务。

排查死锁，很多时候就像侦探破案，需要耐心、细致地分析线索。没有一劳永逸的办法，但掌握了这些工具和思路，至少能让我们在面对死锁时，不再手足无措。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。