在C++并发编程里，死锁是多线程程序最令人头疼的问题之一。当多个线程相互等待对方释放资源而无法继续执行时，系统就陷入了死锁状态。要写出健壮的并发代码，必须先弄清楚死锁的成因，再掌握工程中可用的规避手段。
死锁产生的四个必要条件
死锁并不是随机出现的，它必须满足四个学术上总结的条件，也就是互斥、占有且等待、不可抢占和循环等待。互斥指资源一次只能被一个线程占用，比如互斥量；占有且等待表示线程已经拿到部分资源，还想去拿别的资源且不释放手里的；不可抢占是说线程手中的资源不能被别的线程强行夺走；循环等待则是多个线程形成环形的等待链。
只要打破其中任意一个条件，死锁就不会发生。例如让线程一次性申请所有需要的锁，就破坏了占有且等待；给加锁规定全局顺序，就破坏了循环等待。理解这四点，能帮助我们在设计阶段主动规避问题，而不是等到程序假死后再去调试。
常见死锁场景与代码示例
最典型的写法是两个线程以相反顺序锁定两个互斥量。下面这段代码在并发执行时极有可能卡死：线程A先锁mutex1再锁mutex2，线程B先锁mutex2再锁mutex1，两者交错执行就会互相等待。
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mutex1;
std::mutex mutex2;
void thread_a() {
mutex1.lock();
std::this_thread::sleep_for(std::chrono::milliseconds(10));
mutex2.lock();
std::cout << "thread_a done" << std::endl;
mutex2.unlock();
mutex1.unlock();
}
void thread_b() {
mutex2.lock();
std::this_thread::sleep_for(std::chrono::milliseconds(10));
mutex1.lock();
std::cout << "thread_b done" << std::endl;
mutex1.unlock();
mutex2.unlock();
}
int main() {
std::thread t1(thread_a);
std::thread t2(thread_b);
t1.join();
t2.join();
return 0;
}
上例中如果t1刚好锁住mutex1，t2刚好锁住mutex2，接下来彼此都要获取对方持有的锁，程序就会永久阻塞。这类问题在测试环境可能很少出现，但在高并发生产环境会被放大。
除了顺序反转，锁嵌套调用也是隐患。比如函数foo()锁了A再去调用bar()，而bar()内部又试图锁B，同时别的调用路径以不同顺序进入，也会引发类似问题。因此在代码评审时应重点检查跨函数加锁逻辑。
避免死锁的核心策略
固定加锁顺序
最简单也最易落地的办法是给所有互斥量编号，要求任何线程都必须按编号升序加锁。这样循环等待链无法形成，死锁自然消失。团队可以通过代码规范或静态检查工具来约束顺序。
不过这种方式依赖人工约定，在大型项目里维护成本不低。一旦新增互斥量或重构老代码，就容易遗漏顺序规则。所以它适合规模较小、锁层级清晰的模块。
使用std::lock同时加锁
C++标准库提供了std::lock函数，它可以原子地锁住多个互斥量，避免中间状态导致死锁。配合std::lock_guard的adopt_lock参数使用更安全。
#include <mutex>
std::mutex m1;
std::mutex m2;
void safe_func() {
std::lock(m1, m2);
std::lock_guard<std::mutex> g1(m1, std::adopt_lock);
std::lock_guard<std::mutex> g2(m2, std::adopt_lock);
// 业务逻辑
}
这种写法由标准库保证不会出现顺序相关的死锁，比手写顺序更可靠。缺点是只能用于已知所有锁的情况，动态数量的锁就不太方便。
采用std::scoped_lock
C++17引入的std::scoped_lock是对std::lock的进一步封装，语法更简洁，且支持可变数量互斥量。它会在构造时一次性锁好，析构时自动释放。
#include <mutex>
std::mutex a;
std::mutex b;
void modern_func() {
std::scoped_lock lock(a, b);
// 安全操作共享数据
}
从工程实践看，scoped_lock是目前最推荐的默认选择。它既消除了忘记解锁的风险，也顺带解决了多锁死锁。在新项目中应优先使用，而非老的lock_guard单独加锁。
超时机制与回退
当无法统一锁顺序时，可使用try_lock_for或try_lock_until尝试拿锁，若超时则释放已持有的锁并重试。这破坏了不可抢占或占有且等待条件。
#include <mutex>
#include <chrono>
std::timed_mutex tm1;
std::timed_mutex tm2;
bool attempt() {
if (tm1.try_lock_for(std::chrono::milliseconds(50))) {
if (tm2.try_lock_for(std::chrono::milliseconds(50))) {
// 成功
tm2.unlock();
tm1.unlock();
return true;
}
tm1.unlock();
}
return false;
}
超时方案会增加逻辑复杂度，且频繁重试可能带来性能损耗。它通常用于不能接受长阻塞的服务，例如网络线程或实时任务，作为兜底保护而非首选。
调试与检测手段
在Linux环境下，可以用ThreadSanitizer编译程序，它能动态捕获数据竞争和潜在死锁。此外，GDB附加到卡死进程后，用thread apply all bt查看各线程栈，往往能直接看到谁在等哪把锁。
日常开发中也可以封装一层日志锁，在加锁前后打印线程ID与锁地址，出问题时通过日志还原顺序。虽然会略微影响性能，但对排查偶发死锁非常实用。
| 策略 | 适用场景 | 主要优点 | 主要缺点 |
|---|---|---|---|
| 固定加锁顺序 | 小型模块 | 直观易理解 | 靠人工维护易出错 |
| std::lock | 已知多锁 | 标准库保障 | 不支持动态数量 |
| std::scoped_lock | 现代C++项目 | 简洁安全 | 需C++17 |
| 超时回退 | 高可用服务 | 避免永久阻塞 | 逻辑复杂 |
综合来看，写C++并发程序时应优先用scoped_lock管理多锁，辅以清晰的锁层级设计，再配合 sanitizer 做定期检查，基本可以把死锁风险压到最低。