std::mutex 无法实现线程等待条件成立，需配合 std::condition_variable 和 std::unique_lock 使用；后者支持自动释放/重获锁，必须用谓词循环检测防止虚假唤醒。
为什么直接用 std::mutex 不够用
只靠 std::mutex 无法让线程“等某个条件成立”，比如“队列非空”或“队列未满”。你可能会写成忙等待：
while (queue.empty()) { std::this_thread::yield(); }，这浪费 CPU，且可能因调度延迟导致响应滞后。真正需要的是：线程挂起，直到被明确通知条件满足。
std::condition_variable 必须和 std::unique_lock<:mutex></:mutex> 配合使用
这是最容易出错的点——std::condition_variable::wait() 要求传入的锁必须是 std::unique_lock（不能是 std::lock_guard），因为 wait() 内部会先释放锁、挂起线程，唤醒后再重新加锁。若用错锁类型，编译直接报错。
典型写法：
std::unique_lock<std::mutex> lock(mtx);
cond_var.wait(lock, [&] { return !queue.empty(); }); // 唤醒后自动重加锁
- lambda 中的判断必须是“实际检查条件”，不能只写
queue.empty()后取反，否则虚假唤醒会导致逻辑错误 - 不要在
wait()外手动lock.unlock()，它会破坏原子性 -
notify_one()和notify_all()不需要持有锁，但通常建议在持有锁的上下文中调用，确保通知与状态更新的可见性
生产者和消费者都要处理虚假唤醒
即使没人调用 notify_*，wait() 也可能返回（POSIX 和 C++ 标准允许）。所以永远要用带谓词的 wait()，或者手动循环检查：
立即学习“C++免费学习笔记（深入）”；
std::unique_lock<std::mutex> lock(mtx);
while (queue.empty()) {
cond_var.wait(lock);
}
// 此时 queue 仍可能为空，必须再检查
更安全、更简洁的写法就是用谓词版本：cond_var.wait(lock, [&]{ return !queue.empty(); });，它内部已帮你做了循环。
- 生产者端同样要检查“是否已满”：
cond_var.wait(lock, [&]{ return queue.size() - 注意：
queue.size()在多线程下不是原子操作，必须在锁保护下读取
别忘了在析构前停止线程并清理资源
如果生产者/消费者线程还在运行，而容器（如 std::queue）已被析构，就会触发未定义行为。常见做法是引入一个 std::atomic<bool> done{false}</bool> 控制循环，并在退出前调用 cond_var.notify_all() 唤醒所有等待线程。
例如消费者循环结构：
while (!done.load()) {
std::unique_lock<std::mutex> lock(mtx);
cond_var.wait(lock, [&]{ return !queue.empty() || done.load(); });
if (done.load() && queue.empty()) break;
auto item = std::move(queue.front());
queue.pop();
lock.unlock();
process(item);
}
这里 done.load() 参与了 wait 谓词，确保能及时响应退出信号；同时唤醒后再次检查 done，避免漏掉终止指令。
虚假唤醒、锁类型误用、谓词缺失、析构竞态——这四点覆盖了 90% 的实际 crash 和死锁场景。
