直接用 std::condition_variable 等待会卡死，因其 wait() 要求调用前 mutex 必须已锁定；未锁、提前解锁或跨线程调用将触发未定义行为（如挂起或崩溃）。
为什么直接用 std::condition_variable 等待会卡死？
因为 std::condition_variable::wait() 要求调用前必须持有与之绑定的 std::mutex，且该 mutex 必须处于 locked 状态。如果忘了加锁、提前解锁，或在错误线程里调用，wait() 会直接触发未定义行为（常见表现是程序挂起或崩溃）。
典型错误写法：
std::mutex mtx;<br>std::condition_variable cv;<br>// 错误：没 lock 就 wait<br>cv.wait(lock, []{ return !queue.empty(); }); // crash 或 hang
- 必须用
std::unique_lock<:mutex></:mutex>构造时传入 mutex，且保持 locked 状态进入wait() -
wait()内部会自动 unlock mutex，等待被 notify 后再重新 lock —— 这个“自动 unlock + relock”是安全前提，不能绕过 - 永远不要对同一个
std::condition_variable使用多个不同 mutex，它不支持
生产者怎么发信号才不会丢通知？
用 notify_one() 还是 notify_all() 取决于你是否允许“唤醒竞争”。消费者只有一个时，notify_one() 足够；但如果有多个消费者线程在等，而生产者只发一个 notify_one()，可能唤醒的是刚检查完队列为空、还没来得及 wait 的那个线程，导致通知丢失。
更稳妥的做法是：只要队列从空变为非空，就用 notify_all()；或者确保每次 notify 前，至少有一个消费者真正在 wait 中（较难保证）。
-
notify_one()不保证唤醒“等待条件成立”的那个线程，只唤醒任意一个 —— 条件是否满足，由被唤醒线程自己用 predicate 再判断 - 生产者插入后必须调用 notify，且要在释放 mutex 之前调用（否则可能唤醒后立刻又抢不到锁，再次 wait）
- 避免在循环里反复 notify —— 比如批量 push 多个元素，只需一次 notify，因为消费者醒来后会自己消费完所有可用项
消费者如何避免虚假唤醒和忙等？
std::condition_variable::wait() 允许虚假唤醒（spurious wakeup），所以绝不能用 if 判断条件，必须用 while 循环重检。否则可能拿到空队列还继续 pop，触发 undefined behavior。
立即学习“C++免费学习笔记（深入）”；
正确模式：
std::unique_lock<std::mutex> lock(mtx);<br>while (queue.empty()) {<br> cv.wait(lock); // 自动 unlock，唤醒后自动 relock<br>}<br>// 此时 queue 非空，可安全 pop
- predicate 版本
wait(lock, []{ return !queue.empty(); })内部就是 while 循环，等价且更简洁 - 不要在 wait 之后再加一层 if —— predicate 已帮你做了，重复判断反而容易出错
- 如果消费者需要超时退出（比如 shutdown 场景），用
wait_for()或wait_until()，它们返回std::cv_status，需显式判断是否超时
完整模型里最容易漏掉的同步点
除了队列读写要加锁、wait/notify 要配对，还有两个隐性同步点常被忽略：
- 共享队列本身（如
std::queue<int>）不是线程安全的，所有 push/pop 必须在 mutex 保护下进行，哪怕只是 size() 查询 - shutdown 信号需要单独处理：比如用一个
std::atomic_bool stopped{false}，生产者置 true 后 notify_all，消费者在 while 条件里同时检查!queue.empty() || !stopped，避免永久阻塞 - 析构顺序很重要：如果消费者线程还在运行，而主线程先销毁了
std::condition_variable或std::mutex，就会 crash —— 务必 join 所有工作线程后再销毁同步原语
实际写的时候，把队列、mutex、cv 封装进一个类里，比裸用零散变量更容易守住这些边界。
