必须用std::condition_variable+std::unique_lock+谓词组合，因裸调wait()可能虚假唤醒导致崩溃；谓词确保条件成立才退出，状态修改与notify必须在同锁内原子完成，终止需结合stop_flag与wait_for。
必须用 std::condition_variable + std::unique_lock<:mutex></:mutex> + 谓词（lambda）组合，否则大概率丢消息、崩溃或卡死。
为什么裸调 wait() 会出问题
因为 std::condition_variable::wait() 可能被虚假唤醒（spurious wakeup）——线程没收到 notify_one() 就自己醒了。如果没检查条件就继续执行，queue.front() 会抛 std::out_of_range，或者读到空指针。
带谓词的写法：cv.wait(lock, []{ return !queue.empty(); });，它内部自动展开为 while 循环，每次唤醒都重判，只在条件为真时退出。
- 错误写法：
cv.wait(lock); if (!queue.empty()) { ... }→ 醒来不查条件，直接读，必崩 - 正确写法必须是谓词形式，不能拆成两步
- 谓词里访问的变量（如
queue、stop_flag）必须受同一把锁保护
notify_one() 和 notify_all() 怎么选
核心看等待者是否“等同”：能抢到活就算成功，还是所有人都得响应。
立即学习“C++免费学习笔记（深入）”；
- 单生产者 + 单消费者 → 用
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(); cv.notify_one(); - 也不要在锁外改状态再 notify —— 这等于把“状态变更”和“通知”拆成两个临界区
- 如果需要提前解锁（比如耗时操作），只能在 notify 之后 unlock，不能在之前
如何安全终止等待线程
没有超时或中断机制的 wait() 在程序退出时会永久阻塞，尤其当通知方已退出、无人调用 notify 时。
推荐方案是用 wait_for() + 终止标志：
std::unique_lock<std::mutex> lock(mtx);
while (!stop_flag.load() && queue.empty()) {
auto status = cv.wait_for(lock, 100ms, [this] { return !queue.empty() || stop_flag.load(); });
if (!status) continue; // 超时，重新检查
}
if (stop_flag.load()) return; // 退出信号已到
// 此时可安全 pop
- 仅靠
stop_flag不够，必须和条件变量配合，否则消费者可能永远等不到通知 - 谓词里同时检查
!queue.empty()和stop_flag.load()，确保任一成立就退出 wait - 别用
system_clock做超时基准，要用steady_clock（wait_for默认就是）
真正麻烦的不是写对一次，而是所有路径——包括异常分支、提前返回、析构逻辑——都得保证状态修改、通知、锁生命周期三者严格咬合。漏掉任意一环，高并发下就会间歇性出错，且极难复现。
