condition_variable 必须搭配 mutex 使用，因其自身无线程安全机制，仅负责通知与挂起；所有共享状态读写必须由同一 mutex 保护，且 wait() 前需已持有该 unique_lock 类型锁。
condition_variable 为什么必须搭配 mutex 使用
因为 condition_variable 本身不提供线程安全，它只负责「通知」和「挂起」，所有共享状态的读写都得靠外部 mutex 保护。漏锁、错锁、或在 wait() 前没加锁，都会导致未定义行为——常见表现是程序卡死、虚假唤醒后崩溃，或者根本等不到通知。
典型错误写法：cv.wait(lock, []{ return ready; }); 中的 ready 是全局变量但没被 mutex 保护；或者用两个不同 mutex 分别保护生产者和消费者对同一条件的访问。
正确姿势：
-
wait()前必须已持有对应mutex（且该mutex必须是unique_lock<mutex></mutex>类型） - 所有修改条件变量所依赖的状态（比如
ready = true）的地方，必须用同一把mutex加锁 - 不要试图用
lock_guard替代unique_lock——wait()会临时释放并重新获取锁，lock_guard不支持这个操作
notify_one() 和 notify_all() 的实际区别在哪
不是“一个唤醒 vs 全部唤醒”这么简单，关键看等待线程是否在竞争同一资源。比如多个消费者线程都在等一个任务队列非空：notify_one() 只唤醒一个，其余继续睡，避免惊群；但如果只有一个生产者、多个消费者共用一个条件（如 done 标志），用 notify_one() 可能导致其他线程永远等不到通知。
立即学习“C++免费学习笔记（深入）”；
反过来，notify_all() 开销略大（唤醒所有线程，再由它们重新竞争锁和检查条件），但语义更确定。实际选哪个，取决于你的条件是否“可重用”以及等待者是否“等价”：
- 任务队列类场景（每个任务只该被一个线程处理）→ 优先
notify_one() - 一次性完成信号（如初始化结束、关闭标志置位）→ 必须
notify_all() - 条件判断含副作用（比如
pop()从队列取任务）→ 一定要用notify_one()，否则可能多个线程同时 pop 导致越界
虚假唤醒（spurious wakeup）怎么安全处理
即使没人调 notify，wait() 也可能返回。这是 POSIX 和 C++ 标准允许的行为，底层跟系统调度、中断或优化有关。不处理就会导致线程在条件未满足时继续执行，大概率 crash 或逻辑错乱。
唯一可靠做法：永远用带谓词的 wait() 形式，或者手动循环检查条件：
while (!ready) {
cv.wait(lock);
}
而不是：
cv.wait(lock);
if (!ready) { /* 错！可能刚唤醒就发现 ready 还是 false */ }
注意：谓词函数里不能抛异常，也不能有阻塞操作；如果条件检查本身开销大（比如要查数据库），得评估是否值得用 wait_for() 配合超时重试。
wait_for() 和 wait_until() 的超时陷阱
这两个函数常被误当成“防死锁保险丝”，但它们只保证「最多等多久」，不保证「等完一定有结果」。超时返回后，wait_for() 返回 cv_status::timeout，此时你仍需手动检查条件是否成立——它和无超时版的 wait() 在逻辑上完全等价，只是多了个退出机会。
容易踩的坑：
- 用
steady_clock以外的时钟（比如system_clock）→ 系统时间被修改会导致等待时间错乱 - 超时值设太短（如
1ms），在高负载下频繁轮询，CPU 占用飙升 - 忽略返回值直接往下走，以为“超时=条件已满足”，结果读到脏数据
真实建议：超时主要用于响应取消请求或防止无限等待，核心逻辑仍应依赖条件变量本身的语义，而非时间。
真正难的是设计好条件粒度和通知时机——比如用一个 condition_variable 管多件事，或让通知和状态更新不在同一个临界区里，这些比语法细节更容易出问题。
