C++中condition_variable怎么用_C++线程间同步等待通知机制【精讲】

wait() 必须搭配 std::unique_lock，因其需原子执行“释放锁+挂起线程+唤醒后重锁”；用 lock_guard、裸锁或 shared_mutex 均不满足要求，且须用 while 循环避免虚假唤醒。

condition_variable 本身不提供线程安全，必须和 std::mutex 配合使用；单独调用 wait() 而不加锁或不检查条件，大概率导致死锁或虚假唤醒失效。

为什么 wait() 必须搭配 unique_lock？

因为 wait() 内部会先原子地释放锁、挂起线程，被唤醒后又自动重新加锁——这个“释放+挂起+重锁”过程不可拆分。用 std::lock_guard 或裸 mutex.lock()/unlock() 都无法满足该原子性要求。

常见错误：

• 传入 std::lock_guard：编译失败（wait() 要求可移动、可交换的锁类型）
• 手动 unlock 后再 wait：唤醒后无法自动重锁，条件检查与等待之间出现竞态
• 用 std::shared_mutex：不支持，wait() 只接受 std::unique_lock<:mutex> 或其兼容锁

如何避免虚假唤醒（spurious wakeup）？

即使没收到 notify_one() 或 notify_all()，wait() 也可能返回。所以永远不要用 if 判断条件，而要用 while 循环重检。

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

正确写法示例：

std::unique_lock lk(mtx);
while (!data_ready) {
    cv.wait(lk);
}
// 此时 data_ready 一定为 true

错误写法（可能跳过真实信号或误执行）：

AI图像编辑器

使用文本提示编辑、变换和增强照片

下载

if (!data_ready) {
    cv.wait(lk); // 一次判断，一次等待 → 危险
}

notify_one() 和 notify_all() 的实际影响差异

两者都只负责“唤醒”，不保证被唤醒线程立即执行，也不保证唤醒后条件仍成立（可能被其他线程抢先修改）。

选择依据：

• notify_one()：适用于“一个任务对应一个消费者”的场景（如单生产者-单消费者队列），避免惊群效应，性能更好
• notify_all()：适用于多个等待者中**任意一个**满足条件即可，或条件逻辑复杂、无法精确匹配唤醒目标（如多个线程等不同类型的事件，但共用一个 condition_variable）
• 注意：唤醒后所有被唤醒线程都会竞争 mutex，最终只有一个能真正进入临界区，其余继续阻塞在锁上——这容易被误认为“唤醒没生效”

wait_for() / wait_until() 的超时陷阱

它们返回的是 std::cv_status（no_timeout 或 timeout），不是布尔值；且超时返回后，仍需手动检查条件是否成立——超时 ≠ 条件不满足，只是“等够了时间”。

典型误用：

• 把 wait_for() 当作带超时的“if 条件”直接用，忽略循环检查
• 传入相对时间却用了系统时钟（应使用 std::chrono::steady_clock）导致时钟跳变干扰等待
• 超时后未处理资源状态，比如缓冲区已满但生产者仍尝试 push

推荐模式：

auto deadline = std::chrono::steady_clock::now() + std::chrono::seconds(2);
while (!data_ready && std::chrono::steady_clock::now() < deadline) {
    if (cv.wait_until(lk, deadline) == std::cv_status::timeout) break;
}

最易被忽略的一点：condition_variable 的生命周期必须长于所有可能调用它的线程——析构一个正在被 wait() 的 condition_variable 是未定义行为，哪怕所有线程已 join，也要确保销毁顺序：先通知并等待所有 wait 返回，再销毁 cv。