必须用while循环而非if检查条件变量等待，因为C++允许虚假唤醒且notify可能早于wait；while能每次唤醒后重新验证谓词，确保条件成立后再操作共享数据。
为什么if检查会出问题
直接用 if (!ready) + cv.wait(lock) 是最常见也最危险的写法。线程一旦被虚假唤醒，就跳过等待、直接执行后续逻辑，此时共享状态（比如 data_queue.empty()）很可能仍为 true，导致 front() 或 pop() 触发未定义行为。
这种错误不总能复现，但在线上高并发或特定内核调度路径下极易爆发，表现为偶发崩溃、数据错乱或空指针访问。
-
if只检查一次，无法应对唤醒后条件已失效的情况 - 即使没发生虚假唤醒，也可能因 notify 早于 wait（信号丢失）或多个消费者抢锁导致条件被抢先消费
- C++ 标准明确允许虚假唤醒，不处理等于主动放弃可移植性
while 循环才是安全底线
把等待包在 while 里，是防御虚假唤醒的最小成本方案。每次从 wait() 返回，都强制重新验证谓词，不满足就继续等。
示例中消费者取任务：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::unique_lock<std::mutex> lock(mtx);
while (data_queue.empty()) {
cv.wait(lock);
}
// 此时 data_queue.empty() 必为 false
int val = data_queue.front();
data_queue.pop();
- 必须用
while，不能用for或do-while替代——语义不清且易漏判初始状态 - 循环体里只能调用
wait()，不要夹杂其他可能抛异常或改变状态的操作 - 谓词检查（如
data_queue.empty()）必须在锁保护下进行，否则存在竞态
wait(lock, predicate) 是更优解
C++11 提供的带谓词重载版本，内部自动展开为等价的 while 循环，代码更简洁，也更难写错。
等效写法：
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, []{ return !data_queue.empty(); });
// 此时 data_queue 不为空，可安全操作
- 谓词必须是无副作用的纯函数；若需捕获外部变量，用
[&]或显式列出，避免悬垂引用 - 底层仍会多次调用谓词，所以谓词本身要轻量；重计算逻辑应提前缓存或移到锁外
- 它不能替代对共享状态的加锁保护——谓词里的读取仍需锁同步
容易被忽略的配套细节
光改 wait 写法不够。虚假唤醒只是表象，背后常连着更深层的同步漏洞。
- 通知方（producer）修改共享状态（如
push()）和调用notify_one()必须在同一个std::lock_guard或unique_lock作用域内，否则可能 notify 时状态还未更新完毕 - 所有对共享变量（如
ready、data_queue）的读写，只要跨线程，就必须受同一把std::mutex保护 - 不要依赖
notify_one()一定只唤醒一个线程——某些系统实现下它可能唤醒多个，所以每个等待线程都必须独立验证条件
真正难的不是写对 while，而是确保整个状态流转链条里没有裸读裸写、没有锁粒度错配、也没有通知与等待的时序裸奔。
