std::condition_variable必须与std::mutex配合使用，所有wait/notify操作须在同 mutex 保护下进行；需用lambda条件判断防虚假唤醒；notify_one/all选择取决于业务语义；超时等待后仍需检查条件。

std::condition_variable 必须和 std::mutex 一起用

单独声明 std::condition_variable 没有意义，它不管理临界区，只负责“通知-等待”逻辑。所有 wait()、notify_one()、notify_all() 调用都必须在持有同一把 std::mutex 的前提下进行，否则行为未定义（常见崩溃或死锁）。

典型错误是：在 wait() 前没加锁，或锁的是另一把互斥量。正确模式是：

std::unique_lock lock(mtx);
cv.wait(lock, [&]{ return ready; });

注意：wait() 内部会自动释放 lock，被唤醒后重新获取——这是防止唤醒丢失的关键机制。

用 lambda 判断条件，别手写 while + wait

直接调用 cv.wait(lock) 是危险的，可能遭遇虚假唤醒（spurious wakeup）。标准做法是传入一个可调用对象（通常是 lambda），让 wait() 内部循环检查条件是否真正满足。

立即学习“C++免费学习笔记（深入）”；

• cv.wait(lock, []{ return data_ready; }); —— 安全，推荐
• while (!data_ready) cv.wait(lock); —— 理论可行，但易漏写条件更新逻辑，且不如 lambda 清晰
• cv.wait(lock); —— 错误，无条件等待，无法响应业务状态变化

lambda 中捕获的变量（如 data_ready）必须受同一 std::mutex 保护，否则存在数据竞争。

notify_one() 和 notify_all() 的选择取决于等待者语义

notify_one() 唤醒**至少一个**正在 wait() 的线程；notify_all() 唤醒**所有**等待线程。选哪个不是看性能，而是看业务逻辑是否允许多个线程同时推进。

• 生产者-消费者模型中，一个新任务到达，只需唤醒一个消费者 → 用 notify_one()
• 状态变更（如“初始化完成”）需确保所有依赖线程都收到 → 用 notify_all()
• 用 notify_one() 却有多个等待线程？可能造成部分线程永久阻塞（如果条件不满足又没再次通知）

注意：notify_* 调用本身不要求持有锁（可以加锁后调用，也可以不加），但被唤醒线程恢复执行时，仍需重新竞争并获取该 mutex 才能继续——这点常被忽略。

std::condition_variable 不支持超时等待的简单写法

wait_for() 和 wait_until() 支持带超时的等待，但它们同样需要配合条件判断，不能只靠超时就认为“条件已满足”。

std::unique_lock lock(mtx);
if (cv.wait_for(lock, 100ms, [&]{ return result_available; })) {
    // 真正满足条件，可安全使用 result
} else {
    // 超时了，但 result_available 仍可能为 false —— 不能直接用 result
}

超时返回 false 只代表“等了这么久还没满足”，不代表“永远不满足”。若业务允许重试，应在外层加循环；若必须放弃，则需额外同步机制标记失败态。

容易被忽略的一点：系统时钟精度、调度延迟可能导致实际等待时间略长于指定值，尤其在高负载下。

https://www.php.cn/faq/1969995.html