为何使用条件变量时需用while循环而非if语句？附代码对比

核心原因：不止是虚假唤醒，还要处理「条件失效的唤醒」 #

很多文档只提虚假唤醒，但这只是一部分原因。更关键的是：线程被唤醒时，当初等待的条件可能已经不成立了，比如：

• 多个线程等待同一个条件变量，调用broadcast会唤醒所有线程，但只有第一个抢到资源的线程能满足条件，剩下的线程条件依然不成立
• 虚假唤醒：系统无理由地唤醒线程，此时条件根本没满足
• 其他线程在当前线程被唤醒前，已经修改了共享变量（比如count），导致条件不再成立

用if的问题在于：它只在进入等待前检查一次条件，被唤醒后直接继续执行，不会再验证条件是否真的满足。而while会在每次被唤醒后，重新检查条件——只要条件不满足，就回到等待状态，直到条件真正成立为止。

两段伪代码的执行差异 #

先看两段代码的结构：

第一段（if版本）

lock(mu)
count--;
unlock(mu)
if(count > 0) {
lock(mu)
wait(cond, mu)
unlock(mu)
}
else{
lock(mu)
signal(cond)
unlock(mu)
}

第二段（while版本）

lock(mu)
count--;
unlock(mu)
while (count > 0) {
lock(mu)
wait(cond, mu)
unlock(mu)
}

lock(mu)
signal(cond)
unlock(mu)

具体差异分析

1. 条件验证逻辑

   • if版本：仅在进入等待前检查一次count>0，被唤醒后直接退出if块，不会再确认count的值。如果是虚假唤醒，或者被唤醒时count依然大于0，线程会直接结束，不会继续等待，导致逻辑错误。
   • while版本：每次被唤醒后，都会重新检查count>0是否成立。只要条件不满足，就再次进入等待，直到count<=0才退出循环。

2. 信号发送逻辑

   • if版本：只有当count--后count<=0时，才会发送信号。如果线程被虚假唤醒（此时count仍>0），该线程不会发送信号，导致其他等待的线程可能永远无法被唤醒。
   • while版本：无论什么情况，只要退出while循环（即count<=0），就会发送信号。即便是被唤醒后发现条件仍不满足，会继续等待；直到条件满足后，一定会发送信号，确保后续等待的线程能被唤醒。

3. 多线程场景下的正确性
   举个例子：初始count=3，三个线程依次执行：

   • 线程1：count--到2，进入if块等待
   • 线程2：count--到1，进入if块等待
   • 线程3：count--到0，进入else块发送信号，唤醒线程1
   • 线程1被唤醒后，直接退出if块，结束执行，不会发送信号。此时线程2仍在等待，且没有其他线程会发送信号，导致线程2永久阻塞。

   而用while版本时：

   • 线程3执行完count--到0，退出while循环，发送信号唤醒线程2
   • 线程2被唤醒后，检查count=0，退出while循环，发送信号唤醒线程1
   • 线程1被唤醒后，检查count=0，退出while循环，发送信号
   • 所有线程都能正常结束，不会出现永久阻塞的情况

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