必须用 while 循环而不能用 if 包裹 wait()，因为虚假唤醒是 POSIX 和 JVM 明确允许的行为；若用 if，线程被假唤醒后跳过条件重判，导致空队列取数、读未初始化字段等错误。
为什么 if (condition) wait() 一定会出问题
虚假唤醒不是 bug，是 POSIX 和 JVM 明确允许的行为：wait() 或 cond_var.wait() 可能在没收到 notify() / notify_all() 的情况下返回。用 if 检查只执行一次，线程一旦被假唤醒，就直接跳过条件重判，继续执行后续逻辑——比如从空队列取数据、读未初始化的字段、重复消费任务。
常见错误现象包括：
-
NullPointerException或IndexOutOfBoundsException（因误认为共享状态已就绪） - 生产者/消费者模型中出现负库存或超额消费
- 多线程下偶发崩溃，本地压测难复现，线上高并发时高频触发
Java 中必须用 while (!condition) wait() 包裹
所有对 wait() 的调用，必须放在 synchronized 块内，并用 while 循环包裹条件检查。JVM 规范第17.2节明确要求：「线程应在循环中调用 wait，以重新验证条件是否真正满足」。
正确写法要点：
- 条件变量（如
isDone、queue.isEmpty()）必须是volatile或在同步块内读取 -
wait()前后不能有非原子操作干扰条件判断 - 通知方修改状态和调用
notify()必须在同一把锁下完成
示例片段：
synchronized (lock) {
while (!taskCompleted) {
lock.wait(); // 即使被假唤醒，也会立刻再进循环检查
}
// 此处 taskCompleted 一定为 true
}
C++ std::condition_variable 的两种等效写法
C++11 起，std::condition_variable::wait() 提供两个重载：裸 wait 和带谓词的 wait。二者语义一致，都隐含 while 循环逻辑，但使用场景略有差异。
推荐优先用带谓词版本，原因：
- 代码更简洁，避免手写循环漏掉
lock作用域控制 - 谓词在每次唤醒后自动求值，不依赖外部变量生命周期
- 编译器可做少量优化，且语义更接近「等待直到某事为真」
两种写法对比：
// 手动 while 循环（显式可控）
std::unique_lock<:mutex> lk(mtx);
while (!ready) {
cv.wait(lk);
}
// 带谓词的 wait（内部自动循环）
std::unique_lock<:mutex> lk(mtx);
cv.wait(lk, []{ return ready; });</:mutex></:mutex>
注意：ready 必须在 lambda 中按值捕获或确保其生命周期覆盖整个 wait 过程；若用指针或引用捕获，需自行保证有效性。
pthread_cond_wait 场景下最容易忽略的锁粒度问题
POSIX 条件变量本身不维护状态，完全依赖用户代码保证：「条件检查、wait、状态修改、notify」四步全部在同一个互斥锁保护下进行。漏掉任意一环，虚假唤醒只是表象，底层是竞态本身。
典型坑点：
- 在
pthread_cond_wait()前用if判断，但判断逻辑没加锁 → 条件可能在判断后、wait前被其他线程改掉 - 多个条件共用一个
pthread_cond_t，但 notify 时没区分具体哪个条件已满足 → 导致无关线程被唤醒又立即阻塞，徒增开销 - wait 返回后直接操作共享数据，没再次加锁 → 此时锁已被 wait 自动重新获取，但开发者误以为要手动 lock
正确模式必须是：
pthread_mutex_lock(&mutex);
while (!condition_met) {
pthread_cond_wait(&cond, &mutex); // wait 内部会自动 unlock，唤醒时自动 re-lock
}
// 此处 condition_met 为 true，且 mutex 仍被持有
// ...操作共享资源...
pthread_mutex_unlock(&mutex);
虚假唤醒本身不可预测，但它的破坏力完全可控——关键在于把「条件成立」当作一个需要持续验证的断言，而不是一次性的入场券。只要每次唤醒后都回到条件检查点，操作系统那声“野猫碰桶”的响动，就永远无法骗过你的代码。
