std::condition_variable_any不能直接用std::mutex，因其wait()要求锁满足Lockable概念（含try_lock()），而std::mutex在部分实现中不完全兼容；必须配合std::unique_lock<T>使用，并用谓词确保条件成立。
std::condition_variable_any 为什么不能直接用 std::mutex
因为 std::condition_variable_any 的设计目标就是「支持任意可锁类型」，但它本身不强制要求锁的类型。你传给 wait() 的锁对象必须满足 Lockable 概念（即提供 lock()、unlock()、try_lock()），但 std::mutex 不满足——它没有 try_lock()（C++11 起才加，但标准库实现中仍常被排除在 condition_variable_any 兼容范围外）。实际中更常见的是用 std::shared_mutex 或自定义锁，但最稳妥、最常用的是 std::unique_lock<:mutex></:mutex> ——注意：是带模板参数的 std::unique_lock，不是裸 std::mutex。
正确 wait() 调用必须配合 unique_lock<T> 且检查谓词
调用 wait() 前，锁必须已持有；wait() 内部会自动释放锁，并在被唤醒后重新获取。但唤醒不等于条件成立（可能虚假唤醒），所以必须用带谓词的重载或手动循环检查。
-
std::condition_variable_any的wait()只接受std::unique_lock（或其他满足 Lockable 的锁包装器），不能传std::lock_guard - 推荐始终使用谓词版本：
cv.wait(lock, [&]{ return ready; });，避免手写 while 循环出错 - 谓词必须捕获所有依赖变量（如
ready），且该变量需为std::atomic或受同一互斥体保护
#include <condition_variable>
#include <mutex>
#include <thread>
#include <iostream>
std::condition_variable_any cv;
std::mutex mtx;
bool ready = false;
void waiter() {
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, []{ return ready; }); // 谓词确保不会漏唤醒
std::cout << "Notified!\n";
}
void notifier() {
std::this_thread::sleep_for(std::chrono::milliseconds(100));
{
std::lock_guard<std::mutex> lock(mtx);
ready = true;
}
cv.notify_one();
}
int main() {
std::thread t1(waiter);
std::thread t2(notifier);
t1.join(); t2.join();
}
和 std::condition_variable 的关键区别在哪
核心差异只有两点：锁类型灵活性 和 性能开销。
-
std::condition_variable只接受std::unique_lock<std::mutex>，硬编码依赖std::mutex；std::condition_variable_any接受任意满足 Lockable 的锁（如std::unique_lock<std::shared_mutex>、std::scoped_lock等） - 但
std::condition_variable_any内部通常用void*存储锁对象，需额外类型擦除和虚函数调用，性能略低；除非你真需要等在std::shared_mutex上（比如读线程等待写完成），否则优先用std::condition_variable - 两者 notify 语义完全一致：notify_one() / notify_all() 不保证立即唤醒，也不保证唤醒顺序
容易忽略的线程安全细节
很多人以为只要锁了就安全，但 std::condition_variable_any 的使用链中存在三个独立的线程安全边界：
立即学习“C++免费学习笔记（深入）”；
- 被等待的条件变量（
cv）本身是线程安全的，可多线程调用notify_* - 被保护的状态变量（如
ready）必须与 wait 所用的锁同源 —— 不能一个用mtx，另一个用mtx2 -
notify_one()可以在无等待线程时安全调用，但若此时 wait 尚未开始，该通知就丢失；所以初始化顺序和首次通知时机要小心
真正难调试的问题往往出在状态变量没被锁保护，或者谓词里用了非原子、非同步访问的变量。
