condition_variable必须与mutex配合使用，因其自身不保证线程安全，仅负责等待与唤醒；所有共享状态的读写需由同一mutex串行化，且wait前必须加锁、条件检查与wait共用同一mutex。
condition_variable 为什么必须和 mutex 一起用
因为 condition_variable 本身不保证线程安全，它只负责“等待”和“唤醒”，不保护共享数据。所有对共享状态（比如缓冲区是否为空、是否满）的读写，都得靠 mutex 串行化。漏掉锁，wait() 前的状态检查就可能被其他线程改写，导致虚假唤醒或死锁。
-
wait()内部会自动释放传入的mutex，等被唤醒后再重新加锁——这是它和普通 while 循环+sleep 的本质区别 - 必须在
wait()前加锁，且锁的对象要和检查条件用的是同一个mutex - 别用
std::atomic替代mutex：原子变量能保单个读写，但“检查+等待”是两步操作，中间有竞态窗口
notify_one() 和 notify_all() 到底该选哪个
看等待线程是否“等同”。生产者消费者模型里，多个消费者都在等“有数据”，一个数据来了只够一个消费者取，用 notify_one() 更高效；但如果所有等待者都需要响应同一事件（比如关闭信号），就得用 notify_all()。
-
notify_one()不保证唤醒谁，但避免了“惊群”——100 个消费者同时被唤醒却只有一个能干活，其余又立刻回去等 -
notify_all()要求所有等待线程的条件判断必须用while而不是if，否则可能因虚假唤醒读到无效状态 - 即使只调用了
notify_one()，也要用while循环检查条件：C++ 标准允许系统在无通知时唤醒线程（spurious wakeup）
生产者消费者代码里最容易错的三处
不是逻辑写错，而是同步原语用法细节没抠准。下面这三行写错任意一个，程序就可能卡死或崩溃：
- 消费者中写成
if (buffer.empty()) cv.wait(lock)—— 必须是while，不是if - 生产者 push 后只调用
cv.notify_one()，但消费者在等“非空”，而生产者可能 push 多次后才 notify，中间一次 notify 丢了就永远等下去——必须每次修改状态后 notify - 把
cv.wait(lock, []{ return !buffer.empty(); });的 lambda 捕获写成[&buffer]，但buffer是局部变量或生命周期短的对象，lambda 执行时已析构
std::condition_variable 和 std::condition_variable_any 的区别在哪
std::condition_variable 只认 std::mutex 及其兼容类型（如 std::recursive_mutex）；std::condition_variable_any 能配合任意满足 Lockable 概念的锁，比如 std::shared_mutex 或自定义锁。但代价是性能差不少——内部多一层类型擦除。
立即学习“C++免费学习笔记（深入）”；
- 日常生产者消费者，用
std::condition_variable+std::mutex就够了，别为了“通用”选any版本 -
std::condition_variable_any的wait()在异常抛出时可能不会自动重锁，需要更小心的异常安全处理 - Windows 上
std::condition_variable底层用的是SRWLock+WaitOnAddress，Linux 上是 futex，都不支持任意锁类型——所以any版本其实是模拟实现，开销实打实
