核心问题是唤醒丢失：生产者notify时消费者尚未wait，通知丢失；必须用wait谓词版本自动重检条件，且queue所有操作（含empty、size）都需加锁，notify_one/notify_all选择取决于单次推送数量。
为什么用 std::mutex 和 std::condition_variable 实现生产者消费者容易卡死？
核心问题不是锁没加，而是唤醒丢失：消费者在 wait() 前被生产者发了 notify_one()，但此时消费者还没进入等待状态，通知就丢掉了。必须把「判断条件 + 等待」包进同一个原子操作里，也就是用 wait() 的谓词重载版本。
常见错误写法：
std::unique_lock<std::mutex> lock(mtx);
while (queue.empty()) {
cond.wait(lock); // ❌ 没有谓词，可能虚假唤醒后直接读空队列
}
// 取数据...
正确做法是让 wait() 自动重检条件：
std::unique_lock<std::mutex> lock(mtx);
cond.wait(lock, [&] { return !queue.empty(); }); // ✅ 虚假唤醒也会再检查
// 此时 queue 一定非空
std::queue 本身线程不安全，所有访问都得加 std::mutex
哪怕只是 size() 或 empty()，也必须锁住——因为这些函数内部可能读多个成员变量，C++ 标准不保证其原子性。漏锁一处，就会触发未定义行为（比如读到半更新的 size）。
立即学习“C++免费学习笔记（深入）”；
典型踩坑点：
- 在
wait()谓词里直接写queue.empty()却没加锁 → 编译不过（queue非 const 成员函数不能在 const lambda 里调） - 用
if (queue.size() > 0)判断后才加锁取数据 → 中间可能被其他线程清空 - 生产者 push 后只 notify，但没保证 push 本身已完成（即没锁保护）→ 数据可能写一半就被消费
所以所有对 queue 的读写操作，包括 empty()、front()、pop()、push()，都必须包裹在 std::unique_lock 作用域内。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
一个生产者多个消费者时，notify_one() 和 notify_all() 怎么选？
用 notify_one() 更高效，但前提是：每次 notify 都对应一个「真正能干活」的等待线程。如果多个消费者都在等，而你只 notify 一个，其余继续睡，没问题；但如果生产者一次 push 多个元素，却只 notify 一次，那其余消费者可能长期饥饿。
实操建议：
- 单次只 push 一个元素 → 用
notify_one() - 批量 push（如从文件读一批数据）→ 推荐用
notify_all()，避免唤醒不足 - 若坚持用
notify_one()批量场景，需确保每个消费者都能处理多条，且生产者 push 完立刻 notify 多次（不推荐，易错）
注意：notify_all() 不会唤醒已退出等待的线程，也不会导致重复消费——因为每个消费者醒来后都会重新检查 queue.empty()，只有第一个抢到锁且发现非空的才能取走数据。
别忘了 std::condition_variable::wait() 会自动释放和重获锁
这是最常被误解的一点：很多人以为要手动 unlock/lock，其实 wait() 内部做了两件事：先释放传入的 std::unique_lock，挂起线程；被唤醒后，再阻塞地重新获取该锁，才返回。所以以下写法是错的：
std::unique_lock<std::mutex> lock(mtx); cond.wait(lock); lock.unlock(); // ❌ wait 返回时 lock 已持有，这里 unlock 会抛异常 // ... lock.lock(); // ❌ 更错，重复 lock
正确结构永远是：
std::unique_lock<std::mutex> lock(mtx);
cond.wait(lock, [&]{ return !queue.empty(); });
// ✅ 此时 lock 有效，可安全访问 queue
auto item = queue.front();
queue.pop();
// lock 自动在作用域结束时释放
这个自动管理是 std::unique_lock 和 std::condition_variable 配合设计的关键，强行干预反而破坏语义。
