结论：用 std::condition_variable + std::unique_lock + 谓词（lambda）组合是唯一安全、可落地的消息通知机制；裸调 wait() 不带谓词等于埋雷，因其无法防范虚假唤醒，易导致读空队列、崩溃或丢消息。
直接说结论：用 std::condition_variable + std::unique_lock<:mutex></:mutex> + 谓词（lambda）组合，是唯一安全、可落地的消息通知机制；裸调 wait() 不带谓词等于埋雷。
为什么必须用带谓词的 wait()
因为 std::condition_variable::wait() 可能被虚假唤醒（spurious wakeup）——线程在没人调用 notify_one() 的情况下自己醒了。不检查条件就继续执行，大概率读到空队列、空指针或过期状态。
带谓词的写法：cv.wait(lock, []{ return !queue.empty(); });，它内部自动做 while 循环检查，醒一次判一次，直到条件真才退出。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 消费者线程偶尔崩溃在
queue.front()，报std::out_of_range - 生产者发了 10 条消息，消费者只处理了 7 条，剩下 3 条“卡住”没通知
- 程序在高负载下偶现死锁，尤其在多核 CPU 上更频繁
notify_one() 和 notify_all() 怎么选
核心原则：只唤醒真正需要的那个线程，避免“惊群”浪费调度开销。
典型场景判断：
- 单生产者 + 单消费者 → 用
notify_one()就够了，唤醒对方即可 - 多个消费者竞争同一队列（如线程池）→ 仍用
notify_one()，让一个线程抢走任务，避免多个线程同时醒来争锁再发现没活干 - 广播类通知（如全局配置更新、停止信号）→ 必须用
notify_all()，且等待端谓词里要包含终止条件，例如：[] { return !queue.empty() || stop_flag.load(); }
性能影响：在 100+ 线程等待时，notify_all() 可能引发大量上下文切换，而 notify_one() 基本无额外开销。
共享状态修改和通知必须在锁内完成
这是最容易被忽略的竞态点：如果先改数据、后 notify，中间可能被其他线程插进来读取旧状态；如果先 notify、后改数据，等待线程醒过来一查发现条件还是假，又挂回去——白唤醒一次，还可能永远等不到下一次通知。
正确顺序（必须在同一临界区）：
std::unique_lock<std::mutex> lock(mtx); queue.push(data); // 修改共享状态 cv.notify_one(); // 紧接着通知 // lock 自动在作用域结束时释放
不能写成：
queue.push(data); lock.unlock(); // ❌ 错！unlock 后 notify 是裸操作 cv.notify_one();
如何安全终止等待线程
没有超时或中断机制的 wait() 在程序退出时会卡死。解决方案是引入终止标志 + 谓词中合并检查：
- 用
std::atomic<bool> stop_requested</bool>作为全局退出信号 - 等待谓词写成：
[] { return !queue.empty() || stop_requested.load(); } - 退出前设置
stop_requested = true;并调用cv.notify_all()
注意：不要在析构函数里直接调用 notify_all()，此时其他线程可能已开始析构或已退出，condition_variable 对象本身也可能被销毁。务必确保所有等待线程已响应并退出后再清理资源。
最复杂的点不在语法，而在状态边界——比如“队列为空但 stop 已置位”这种双重条件，漏掉任一判断都会导致线程永远挂起或误触发。写的时候盯着谓词逻辑，比盯着 notify 调用位置更重要。
