c++如何使用条件变量condition_variable_c++ 线程等待与唤醒机制【方法】

std::condition_variable必须与std::unique_lock配合使用，因wait()需锁支持临时释放与重获；须用带谓词的wait(lock,[]{return cond;})避免虚假唤醒；notify_one/notify_all选择取决于语义，析构前须确保无等待线程。

condition_variable 必须和 unique_lock 一起用

单独声明 std::condition_variable 没法工作，它不管理互斥量，只负责挂起/唤醒线程。你必须配一个 std::unique_lock<:mutex>，且这个锁在调用 wait() 前必须已持有。

常见错误是传 std::lock_guard 或裸 std::mutex ——编译直接报错，因为 wait() 要求锁支持临时释放和重新获取。

• wait() 会自动释放锁，让其他线程能修改共享状态；被唤醒后自动重新加锁再返回
• 别用 std::mutex 直接构造 unique_lock 后就丢掉——要保持对象生命周期覆盖整个等待过程
• 如果用 std::shared_mutex 等非独占锁，condition_variable 不支持，得换 std::condition_variable_any

wait() 的 predicate 版本不是可选优化，而是必须用

裸 wait(lock) 有惊群和虚假唤醒风险：线程被唤醒时，条件可能根本没满足，或者多个线程同时被唤醒但只有一个能真正处理任务。

所以几乎总该用带谓词的重载：wait(lock, []{ return /* 条件表达式 */; })。它内部自动做 while 循环检查，安全可靠。

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

HTTPie AI

AI API开发工具

下载

• 谓词必须捕获共享变量（如用 [&]），且变量访问需受同一 mutex 保护
• 不要写成 wait(lock); if (x > 0) {...} ——这漏掉了虚假唤醒场景
• 谓词里别做耗时操作，否则阻塞其他线程获取锁

std::mutex mtx;
std::condition_variable cv;
bool ready = false;
// 等待方
std::unique_lock lk(mtx);
cv.wait(lk, []{ return ready; }); // 安全：自动循环检查
// 通知方
{
std::lock_guard lk(mtx);
ready = true;
}
cv.notify_one(); // 或 notify_all()

notify_one() 和 notify_all() 的选择影响性能与逻辑正确性

notify_one() 只唤醒一个等待线程，notify_all() 唤醒全部。选哪个不只看“快不快”，更要看语义是否匹配。

• 生产者-消费者中单个任务就绪 → 用 notify_one() 即可，避免多余唤醒
• 状态变更影响所有等待者（比如“全局关闭标志置位”）→ 必须用 notify_all()
• 用 notify_one() 但等待线程有多个不同条件（比如等 A 或等 B）→ 可能唤醒错人，导致死锁或饥饿
• notify_* 可以在锁外调用，但要注意：若通知早于 wait()，信号会丢失（因为 condition_variable 不保存信号计数）

销毁 condition_variable 前必须确保无等待线程

std::condition_variable 析构时，如果有线程还在 wait()，行为未定义——多数实现会 crash 或 abort。

这不是资源泄漏问题，而是直接 UB。所以实际工程中：

• 把 condition_variable 和关联的 mutex、共享数据放在同一作用域（如类成员），靠对象生命周期管理
• 退出前手动清理：设置退出标志 + notify_all() + join() 所有等待线程
• 别在 lambda 捕获中隐式延长 condition_variable 生命周期（比如在线程池里存了个引用）

最易忽略的一点：notify_all() 并不保证所有被唤醒线程都已完成执行——你得靠 join 或其他同步机制确认它们真退出了，才能安全析构。