std::condition_variable 必须与 std::unique_lock 配合使用，是c++标准库中唯一支持可靠等待-唤醒语义的机制；它依赖操作系统事件实现零忙等待，需配合谓词防止虚假唤醒和信号丢失，且生命周期必须长于所有等待线程。
std::condition_variable 配合 std::unique_lock 是唯一正解
直接用 std::condition_variable 实现线程间通知，不是“可选方案”，而是标准库中唯一支持等待-唤醒语义的机制。它必须和 std::unique_lock<:mutex></:mutex> 搭配使用，不能配 std::lock_guard，也不能裸用互斥量——否则编译失败或运行时未定义行为。
常见错误现象包括：wait() 调用后线程永远不被唤醒、虚假唤醒未处理、notify_one() 在 wait() 之前调用导致丢失信号。
-
wait()内部会自动释放锁并挂起线程；被唤醒后重新获取锁再返回，所以条件检查必须是原子的（放在 lambda 中） - 必须用
std::unique_lock：因为wait()需要临时释放锁，而std::lock_guard不支持解锁操作 - 通知端（
notify_one()/notify_all()）无需持有锁，但加锁后通知更安全（避免竞态窗口） - 永远用谓词重载的
wait(lock, []{ return condition; })，不用无谓词版本——否则必须手动处理虚假唤醒
为什么不能只靠 std::mutex 或 std::atomic 实现可靠通知
std::mutex 只能阻塞/放行，无法让线程“等某个状态成立”；std::atomic<bool></bool> 可以轮询，但属于忙等待，浪费 CPU，且无法保证唤醒时机精确。
典型误用场景：用 std::atomic<bool></bool> 标记“消息已就绪”，另一个线程死循环检查。这在低负载下看似可行，但在高并发或低功耗设备上会导致严重性能问题，且无法响应超时、中断等高级需求。
- 轮询 +
std::this_thread::yield()或sleep_for是退化做法，不是通知，是妥协 -
std::atomic适合标志位、计数器等简单状态同步，不适合“等待某事发生”这类语义 - 条件变量底层依赖操作系统事件机制（如 futex、WaitForSingleObject），真正实现零忙等待
std::condition_variable 的生命周期和销毁风险
std::condition_variable 对象本身必须存活到所有等待线程全部退出之后，否则可能触发未定义行为（如 Linux 下 SIGSEGV）。这不是理论风险——在线程池或异步服务中极易踩坑。
常见错误：把 std::condition_variable 声明为局部变量、或在等待线程还在运行时就析构了包含它的类实例。
- 确保
std::condition_variable和受保护的共享数据（如队列）具有相同生命周期 - 停止通知逻辑前，先设置退出标志，再调用
notify_all()唤醒所有等待线程，最后等待它们 join 完毕 - 不要在析构函数里直接调用
notify_all()—— 此时对象可能已部分析构，wait()回调访问成员会崩溃
超时等待必须用 wait_for 或 wait_until，不能手写循环
需要带超时的消息等待（比如网络请求等待响应最多 5 秒），必须用 wait_for() 或 wait_until()，而不是自己用 std::atomic + sleep_for 模拟。
手写循环不仅重复造轮子，还会引入精度误差、系统时钟跳变处理缺失、以及无法与真实等待状态对齐等问题。
-
wait_for(lock, std::chrono::seconds(5))返回std::cv_status::timeout或std::cv_status::no_timeout，可直接判断 - 超时时间从调用时刻开始计算，不受系统时间调整影响（基于 steady_clock）
- 若需取消等待，只能靠配合退出标志 +
notify_one()主动唤醒，没有“中断等待”原语
最易被忽略的一点：条件变量不保证“通知必达”。如果 notify_one() 发生在 wait() 进入阻塞前的极小窗口，信号会丢失。所以每次 wait() 前必须检查条件是否已满足，且该检查必须与等待逻辑在同一个锁保护下完成——这就是为什么谓词 lambda 不可省略。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
