C++11中使用condition_variable实现线程同步时遭遇死锁，请求原因解析

我特别理解你现在的困惑——明明知道wait()会自动解锁互斥锁，结果程序还是死锁了，这种“理论和实际不符”的情况确实让人挠头。虽然你没贴出具体代码，但结合你描述的现象，我可以给你梳理几个最容易踩的坑，大概率你的问题就出在这里：

1. 用if而非while判断等待条件 #

这是condition_variable最经典的坑之一！很多人会图省事写：

std::unique_lock<std::mutex> lock(mtx);
if (!condition) {
    cond.wait(lock);
}

但wait()可能会被虚假唤醒（操作系统线程调度的机制问题，不是你的代码错误），或者子线程通知时条件其实还没真正满足。如果用if，线程被唤醒后会直接往下走，但此时条件可能依然不成立，后续操作就可能导致互斥锁被错误持有，进而引发死锁。

正确的写法必须用while循环做二次检查：

std::unique_lock<std::mutex> lock(mtx);
while (!condition) {  // 循环确认条件真的满足，避免虚假唤醒或无效通知
    cond.wait(lock);
}

2. 通知时机错误，导致主线程永远等不到信号 #

如果你的子线程在没有持有互斥锁的情况下调用notify_one()/notify_all()，或者主线程的wait()还没开始执行，子线程就已经发了通知，那主线程会一直阻塞在wait()上，看起来像是死锁。

举个典型的反例：

// 子线程先执行，提前发了通知，但主线程还没进入等待状态
void worker() {
    // 没加锁就通知，主线程根本收不到
    cond.notify_one();
}

// 主线程后执行，永远卡在wait里
int main() {
    std::thread t(worker);
    std::unique_lock<std::mutex> lock(mtx);
    cond.wait(lock);  // 死锁！
    t.join();
    return 0;
}

正确的做法是，子线程在修改共享条件变量（也就是触发等待条件的变量）时，必须持有互斥锁，然后再通知：

void worker() {
    std::lock_guard<std::mutex> lock(mtx);
    condition = true;  // 修改共享条件时必须持有锁
    cond.notify_one();
}

3. 互斥锁的重复锁定/未正确释放 #

虽然wait()会自动解锁互斥锁，但如果你的主线程在第二次操作时，错误地重复锁定了同一个互斥锁（比如用std::lock_guard而非std::unique_lock，或者手动调用lock()多次），就会导致死锁。

比如这种错误写法：

std::mutex mtx;
// 第一次手动锁定
mtx.lock();
cond.wait(std::unique_lock<std::mutex>(mtx, std::adopt_lock));
// wait返回后已经自动重新锁定了mtx，这里再手动锁就会卡死
mtx.lock();  // 死锁！

4. 子线程未正确执行或提前退出 #

如果你的子线程因为异常、逻辑错误提前退出，根本没执行到notify_one()/notify_all()，那主线程会一直卡在wait()里，也会表现为死锁。

给你的建议 #

如果可以的话，把你的演示代码贴出来，这样我能更精准地定位问题。但先按照上面的几点排查，尤其是用while替代if判断等待条件这个最常见的错误，大概率能解决你的问题。

内容的提问来源于stack exchange，提问作者da cheng