condition_variable 必须与 unique_lock 搭配使用，因其 wait 系列函数依赖 unique_lock 的可转移和中途解锁能力；裸指针、lock_guard 或手动锁控均导致编译错误或未定义行为。
condition_variable 为什么必须和 unique_lock 搭配使用
因为 condition_variable 的 wait()、wait_for()、wait_until() 函数内部会**自动释放锁并挂起线程**，等被唤醒后又自动重新加锁——这个“释放-等待-重获”流程只有 std::unique_lock<:mutex></:mutex> 支持，std::lock_guard 不支持中途解锁，std::shared_lock 不支持独占写操作。
常见错误是传入 lock_guard 或裸指针，编译直接报错：no matching member function for call to 'wait'。
- 必须用
std::unique_lock<:mutex></:mutex>构造时传入 mutex，且保持其生命周期覆盖整个 wait 调用 - 不能用
std::mutex::lock()/unlock()手动控制后传给wait()—— 这会导致未定义行为 -
wait()返回时，锁一定已被重新获取（除非被虚假唤醒打断）
wait() 里的 predicate 为什么不能省略
直接调用 cv.wait(lock)（无谓词版本）极容易出错，因为存在**虚假唤醒（spurious wakeup）**：系统可能在没收到 notify_one() 或 notify_all() 时就让线程醒来。此时共享状态未必满足预期，直接继续执行大概率导致逻辑错误。
正确做法是把条件检查包装进 Lambda 或函数对象，交给 wait() 内部循环验证：
立即学习“C++免费学习笔记（深入）”；
cv.wait(lock, [&ready] { return ready; });这等价于：
while (!ready) { cv.wait(lock); }- 谓词必须是可调用对象，返回
bool；捕获变量注意生命周期（比如用引用捕获时，确保被引用对象在线程等待期间不销毁） - 不要在谓词里修改共享状态（如
ready = true），否则破坏原子性 - 如果条件涉及多个变量或复杂判断，务必保证谓词内访问是线程安全的（通常靠外部 lock 保护）
notify_one() 和 notify_all() 到底该选哪个
选哪个不取决于“通知几个”，而取决于**等待者是否等价、能否互相替代**。
例如生产者-消费者模型中，多个消费者等待同一缓冲区非空：任意一个被唤醒都能取走任务，用 notify_one() 更高效，避免惊群（thundering herd）；但若所有等待者都需响应同一事件（比如“全局配置已重载”），就必须用 notify_all()。
-
notify_one()不保证唤醒“最早等待的那个”，只是唤醒一个当前阻塞的线程（具体哪个由调度器决定） -
notify_all()会唤醒所有在该condition_variable上等待的线程，但它们仍要竞争 mutex，所以不是并发执行谓词检查 - 调用
notify_xxx()时，不必持有 mutex —— 但如果你的共享状态修改本身需要同步，那自然得在锁内改完再通知
为什么 notify 要在修改状态之后、unlock 之前调用
顺序错了就可能丢通知：如果先 unlock() 再 notify_one()，那么等待线程可能在你 unlock 后、notify 前被调度并进入 wait，结果错过这次通知，陷入永久阻塞。
典型安全写法是：
{ std::unique_lock<std::mutex> lock(mtx); ready = true; // 修改共享状态 cv.notify_one(); // 紧接着通知 } // lock 自动析构，释放 mutex- 通知动作本身不需要锁保护，但它必须紧挨着状态修改之后，且仍在锁的作用域内
- 如果通知逻辑复杂（比如要遍历容器判断谁该醒），也应尽量缩短锁持有时间，但 notify 仍要在锁内完成
- 极端情况：若你确定等待线程尚未开始 wait（比如刚启动），那顺序影响不大；但生产代码永远按“改状态 → notify → 解锁”来写
最常被忽略的是谓词的完备性和 notify 的时机配合——这两个点一错，程序就变成概率性卡死或读到脏数据，调试起来非常隐蔽。