仅用std::mutex无法实现线程等待，必须配std::condition_variable：mutex保护临界区访问，condition_variable用于等待业务条件（如队列非空），避免忙等；notify需在锁内修改状态后调用，推荐notify_one，配合while循环防止虚假唤醒。
为什么不能只用 std::mutex 而必须配 std::condition_variable
只锁不等，消费者会疯狂轮询队列是否非空，CPU 白耗；生产者同理，可能往满队列硬塞。互斥锁管的是「临界区访问」，条件变量管的是「等某个业务条件成立」——比如 queue.empty() == false 或 queue.size() 。二者必须配合：锁保护共享状态，条件变量在锁内等待，并在被唤醒后重新检查条件（防止虚假唤醒）。
std::condition_variable::wait 必须传入 std::unique_lock<:mutex></:mutex>
不能传 std::lock_guard，也不能裸传 std::mutex。因为 wait 需要能临时释放锁（让其他线程进临界区改状态），并在唤醒时自动重新加锁。只有 std::unique_lock 支持移动和手动解锁/重锁。
常见错误写法：
std::lock_guard<std::mutex> lock(mtx); // ❌ 编译不过：wait 不接受 lock_guard
cv.wait(lock, [&]{ return !q.empty(); });
正确写法：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, [&]{ return !q.empty(); }); // ✅ lock 自动管理生命周期
- lambda 条件里必须捕获引用（
[&]），否则读到的是旧副本 - 不要在
wait外再手动lock.unlock()，会破坏原子性 - 唤醒后，
lock仍持有，可安全访问共享队列
消费者循环中必须用 while 而不是 if 检查条件
虚假唤醒（spurious wakeup）是 POSIX 和 C++ 标准允许的行为：线程可能没被 notify 就醒了。如果只用 if，醒来后直接取数据，极大概率 crash（队列实际还是空的）。
正确结构：
std::unique_lock<std::mutex> lock(mtx);
while (q.empty()) { // ✅ while，不是 if
cv.wait(lock);
}
auto item = std::move(q.front());
q.pop();
- 生产者端同理：用
while (q.size() >= capacity)等空间 - 所有对
q的读写操作，必须在lock持有时进行 -
cv.notify_one()放在修改完队列、且仍在锁内时最安全（避免唤醒后竞争）
多生产者/多消费者下 notify 的选择：notify_one 还是 notify_all？
多数场景用 notify_one 就够了：一个消费者醒来取走一个任务，其余继续睡。但要注意两个边界：
- 如果生产者在 push 后调用
notify_one，而此时没有消费者在 wait（比如刚启动），那这次通知就丢了 —— 所以条件检查永远在 wait 前做，靠 while 循环兜底 - 当有多个消费者且任务粒度很小时（如每条日志一个 notify），
notify_all可能引发惊群（thundering herd），大量线程争抢锁，反而降低吞吐。除非你明确需要「唤醒所有等待者一起干活」（比如 barrier 场景） - 若用
notify_all，务必确保所有被唤醒线程都能处理当前状态（例如队列非空），否则部分线程又立刻 wait 回去，白耗调度开销
真正容易被忽略的是：notify 不必和 wait 在同一把锁下发生，但它必须在修改共享状态后、且该状态对等待者可见时调用 —— 也就是在同一个 unique_lock 作用域内完成修改 + notify 最稳妥。
