如何避免死锁？

访客性能优化 2026-06-06 12:56:21 2

如何避免死锁？一文掌握死锁预防与解决方案

什么是死锁？——核心概念与经典案例
死锁产生的四个必要条件（互斥、持有并等待、非剥夺、循环等待）
如何避免死锁？六大实战策略
- 破坏互斥条件
- 破坏持有并等待条件
- 破坏非剥夺条件
- 破坏循环等待条件
- 银行家算法（系统级预防）
- 超时与重试机制（工程实践）
常见问题问答（Q&A）
总结与最佳实践建议

死锁是指两个或多个线程（或进程）在争夺资源时，彼此都在等待对方释放资源，从而陷入无限等待的状态，线程A持有资源1，等待资源2；线程B持有资源2，等待资源1，两者都不愿放手,程序卡死。

经典案例：数据库中的事务死锁、操作系统的进程调度、多线程并发编程中的锁竞争。

根据计算机科学家Coffman的总结，只要同时满足以下四个条件,死锁就必然发生：

核心原则：只要破坏上述任一条件,死锁就不会发生。

尽量使用共享资源代替互斥资源，使用读写锁（读操作可并发，写操作互斥）；或使用无锁编程（Atomic操作、CAS算法）代替互斥锁。

适用场景：读多写少的系统（如缓存、配置中心）。

// 示例：使用读写锁避免不必要的互斥
ReadWriteLock rwLock = new ReentrantReadWriteLock();
rwLock.readLock().lock(); // 多个读线程可同时访问

让线程在开始执行前一次性申请所有需要的资源，若资源不足,则让线程等待并释放已持有的资源。

实现方法：

public void runTask() {
    synchronized (lock1) {
        synchronized (lock2) { // 同时申请两个锁
            // 执行任务
        }
    }
}

风险：可能导致资源利用率降低（占用资源却未使用）。

允许资源被强制剥夺,常见做法：

ReentrantLock lock = new ReentrantLock();
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { 
    // 获取成功
} else {
    // 超时后释放已有资源，重新尝试
}

对所有资源进行全局唯一编号，要求线程必须按编号顺序（递增或递减）申请资源，这被称为资源有序分配法。

示例：假设资源编号1,2,3，所有线程都必须先申请小号资源，再申请大号资源,这样就不会出现循环等待。

# 伪代码：按资源ID顺序加锁
def task():
    with lock1:  # 先小号
        with lock2:  # 后大号
            # 执行

优点：实现简单、效率高。缺点：编号难以在动态系统中维护。

操作系统级算法，系统维护一个安全状态表，只有分配资源后系统仍处于安全状态，才分配资源，算法复杂度较高,适合单机多进程调度。

核心公式：Available[j] + Need[i][j] > Request[i][j] 才能满足请求。

在分布式系统中，使用乐观锁+重试避免死锁，数据库更新时使用version字段，若更新失败则重试（配合退避策略）。

UPDATE account SET balance = balance - 100, version = version+1 
WHERE id = 1 AND version = 10;  -- 假设当前version=10
-- 若更新影响行数为0，说明版本冲突，重试

A：死锁检测是事后处理（允许死锁发生，然后通过工具检测并恢复）；死锁避免是事前预防（通过算法或策略组织死锁发生）,生产环境中更推荐避免而非检测。

A：因为synchronized不支持中断和超时，一旦进入等待，只能死等，而ReentrantLock提供了tryLock()、lockInterruptibly()等机制,更容易破坏非剥夺条件。

A：常用方法包括：分布式锁超时（Redis锁设置过期时间）、有序加锁（按业务ID哈希排序）、TCC（Try-Confirm-Cancel）模式（通过补偿事务打破僵局）。

A：不要同时持有多个锁，如果必须持有多个锁，务必按固定顺序获取,并设置超时后主动释放。