notify_all() 有时不唤醒等待线程，根本原因是调用时未持互斥锁或等待线程尚未进入wait()状态；它不缓存信号，必须与状态修改原子同步，且唤醒后需由谓词重新验证条件。
std::condition_variable::notify_all() 为什么有时不唤醒等待线程？
根本原因不是 notify_all() 失效，而是调用它时没有配套的互斥锁保护、或等待线程尚未进入 wait() 状态。它只负责“发信号”，不保证“有人在听”。
常见错误现象：notify_all() 调用后，wait() 仍阻塞；或只唤醒部分线程；或唤醒后立刻又挂起（因条件未真正满足）。
- 必须在持有同一
std::mutex的前提下调用notify_all()—— 不是为了保护notify_all()自身，而是确保“修改条件变量所依赖的状态”与“通知”是原子可见的 - 等待线程必须已执行到
wait()并被挂起，notify_all()才有效；若先通知后等待，信号丢失（condition_variable 不缓存信号） - 唤醒后，每个等待线程会重新获取互斥锁，并**重新检查谓词（predicate）** —— 这就是为什么必须用
wait(lock, pred)形式，而不是裸wait(lock)
std::condition_variable::wait() 的谓词写法错在哪？
直接写 cv.wait(lock) 再手动 if (!ready) continue; 是错的：可能被虚假唤醒（spurious wakeup），也可能在检查条件前被抢占，导致逻辑跳过。
正确做法是把条件检查完全交给 wait() 的谓词参数，让它内部循环处理。
立即学习“C++免费学习笔记（深入）”；
- ✅ 推荐写法：
cv.wait(lock, [&ready]() { return ready; });—— lambda 返回false时自动继续等待 - ❌ 危险写法：
cv.wait(lock); if (!ready) continue;—— 没有循环，一次失败就退出等待逻辑 - 谓词中访问的变量（如
ready）必须受同一std::mutex保护，否则存在数据竞争
notify_all() 和 notify_one() 性能差别大吗？
差别不在通知本身开销，而在于后续线程调度和锁竞争。用错场景才真伤性能。
-
notify_one()更轻量，适合“只有一个线程能推进工作”的场景（如生产者-消费者中一个任务完成） -
notify_all()会唤醒所有等待线程，它们抢锁、重检谓词、多数再次挂起 —— 如果等待线程多（比如上百），可能引发“惊群效应”，CPU 白耗在上下文切换上 - 但若条件变化影响所有等待者（如全局状态重置、关闭标志置位），就必须用
notify_all()；此时不用它反而导致部分线程永久卡住
多 condition_variable 共享一个 mutex 有问题吗？
完全没问题，而且是推荐做法：多个条件变量可以（也应该）复用同一个 std::mutex，只要它们保护的状态变量也由该锁保护。
典型误用：为每个 condition_variable 配一个独立 mutex —— 这会导致状态更新和通知不同步，出现信号丢失或数据竞争。
- 例如两个条件：
data_ready和shutdown_requested，都由std::mutex mtx保护，则共用一个std::condition_variable cv或分别用cv1、cv2都可以，但通知时必须锁住mtx - 关键点：不是 condition_variable 本身需要锁，而是它所关联的“共享状态”需要锁；通知只是对状态变更的配套动作
最容易被忽略的是谓词检查和锁的绑定关系——哪怕只漏掉一个 lock.lock() 或一处非原子读，整个等待逻辑就不可靠。C++ 的 condition_variable 不做任何魔法，它只忠实地执行你写的同步契约。
