std::condition_variable 必须与 std::unique_lock 配合使用，因 wait() 需其支持解锁/重锁，且需用谓词版本防虚假唤醒；notify_one()/notify_all() 应按语义选用；注意生命周期、状态更新顺序及异常安全。
condition_variable 必须和 unique_lock 配合使用
单独声明 std::condition_variable 没有意义，它不管理互斥状态，也不持有锁。所有 wait()、notify_one()、notify_all() 调用都要求线程已持有与之关联的 std::mutex，且必须通过 std::unique_lock<:mutex></:mutex> 传入 —— std::lock_guard 不行，因为它不支持解锁后重锁（wait() 内部会先释放锁再挂起）。
常见错误是试图用 lock_guard 或裸 mutex.lock()/unlock() 配合 wait()，结果编译失败（类型不匹配）或运行时崩溃（未正确释放锁）。
-
wait()第一个参数必须是unique_lock，不是mutex，也不是lock_guard - 构造
unique_lock时可延迟加锁：std::unique_lock<:mutex> lk(mtx, std::defer_lock);</:mutex>，但调用wait()前它必须已上锁 -
wait()返回时，unique_lock一定已重新获得锁，无需手动再lock()
wait() 的谓词版本才是安全写法
直接调用 wait(lk) 容易陷入虚假唤醒（spurious wakeup）：系统可能在没有收到 notify 的情况下让线程醒来，此时共享状态可能仍未就绪，继续执行就会出错。
正确做法是始终用带谓词的重载：wait(lk, []{ return condition; })。它等价于循环检查 + 手动 wait()，但由标准库保证原子性与安全性。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 谓词必须是无副作用的纯判断逻辑，比如
!queue.empty()、ready_flag.load() - 不要在谓词里修改共享数据或调用可能阻塞的函数
- 如果不用谓词而自己手写 while 循环，必须确保循环条件检查在每次
wait()返回后立即进行，否则仍可能跳过状态变更
notify_one() 和 notify_all() 的选择取决于等待者语义
notify_one() 唤醒一个等待线程，notify_all() 唤醒所有。选哪个不是看“性能”，而是看业务逻辑是否允许多个线程同时推进。
例如生产者-消费者中，一个产品入队只需唤醒一个消费者，用 notify_one() 即可；但如果某个状态变更（如“全部任务完成”）需要所有等待线程一起响应，则必须用 notify_all()。
- 过度使用
notify_all()会造成“惊群效应”，尤其在线程数多、条件检查开销大时明显拖慢整体性能 -
notify_one()并不保证唤醒“最先等待的那个”，顺序由调度器决定，不可依赖 - 通知操作本身不加锁，可放在临界区外，但要确保通知前状态已更新完毕（通常在锁内更新状态 + 通知）
别忘了 wait() 前的状态检查和异常安全
很多初学者只关注“怎么等”，却忽略“等什么”和“等不到怎么办”。condition_variable 本身不提供超时、取消或中断机制，需组合其他工具。
- 需要限时等待？用
wait_for(lk, dur, pred)或wait_until(lk, time_point, pred) - 等待期间可能被中断？C++20 起可配合
std::stop_token使用wait()的新重载，但主流项目仍常用标志位轮询 - 如果等待逻辑可能抛异常，确保
unique_lock的生命周期管理正确 —— 它在作用域结束时自动解锁，比手动管理更可靠
最常被忽略的一点：condition_variable 的生命周期必须长于所有可能调用它的线程。把它作为局部变量、或在还有线程等待时就析构，会导致未定义行为 —— 这类问题往往在压力测试或程序退出时才暴露。
