std::notify_all_at_thread_exit不可用notify_all替代，因其在当前线程析构完毕后才唤醒，避免访问已销毁对象；notify_all则立即唤醒，易导致未定义行为。
std::notify_all_at_thread_exit 为什么不能直接用 notify_all 替代
因为 std::notify_all 只是立刻唤醒所有等待中的线程，但此时被唤醒的线程可能还没真正开始执行——尤其当调用 notify_all 的线程正要退出、其栈上对象（比如 std::mutex、std::condition_variable）即将析构时，被唤醒线程一抢锁就可能访问已销毁的互斥量，触发未定义行为。
std::notify_all_at_thread_exit 的作用是把唤醒“延迟到当前线程彻底退出、所有局部对象析构完毕之后”，确保被唤醒线程看到的是稳定状态。
- 只适用于当前线程即将退出的场景，比如在
std::thread启动的函数末尾 - 必须配合一个已锁定的
std::mutex使用，且该 mutex 必须在整个线程生命周期内有效（不能是栈上临时变量） - 不能在主线程（main 函数返回前）调用，否则行为未定义
std::condition_variable::notify_all 唤醒后线程卡在 wait 里
常见现象：调用 notify_all 后，部分或全部等待线程没继续执行，还停在 wait 或 wait_for 上。根本原因不是唤醒失效，而是「虚假唤醒」没处理，或者「条件检查逻辑有竞态」。
标准写法必须用 while 循环包裹 wait，不能用 if：
立即学习“C++免费学习笔记（深入）”；
while (!ready) {
cv.wait(lock);
}
- 遗漏循环检查会导致线程错过条件成立时机，尤其在多核 CPU 上更易复现
- 条件变量不保存状态，
notify_all发生时若无人在 wait，信号就丢了 - 如果
ready是普通变量，必须用std::atomic或受同一 mutex 保护，否则读写未同步
std::notify_all 和 std::notify_one 的性能与语义差异
notify_one 只唤醒一个等待线程，适合“任务队列取一个任务”这类场景；notify_all 唤醒全部，适合“状态全局变更”（如 shutdown 标志置位）。但别以为 notify_all 一定更慢——现代 libstdc++ 和 libc++ 对空等待队列做了短路优化，开销几乎和 notify_one 相当。
- 唤醒数量本身不构成性能瓶颈，真正慢的是被唤醒线程争抢 mutex 的过程
- 在高并发下，
notify_all可能引发“惊群效应”，大量线程同时抢锁，导致缓存行颠簸（cache line bouncing） - Windows 上
CONDITION_VARIABLE底层实现对notify_all有额外系统调用开销，Linux futex 则无此问题
std::condition_variable 配合 unique_lock 的生命周期陷阱
最常踩的坑：把 std::unique_lock 声明在 wait 语句块外，却在 wait 返回前提前释放了锁（比如 return、throw、goto），导致后续 notify_all 调用时，等待线程一醒来就发现锁不可用，又挂回去。
正确做法是让 std::unique_lock 的作用域覆盖整个条件检查 + 操作流程：
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, []{ return ready; });
// 此处 lock 仍持有，可安全操作共享数据
process_data();
// lock 在作用域结束时自动释放
- 不要手动调用
lock.unlock()，除非你明确知道后续没有条件变量交互 - 如果需要在 wait 返回后长时间持锁，考虑用
std::defer_lock+ 手动 lock/unlock，但务必保证 notify_all 发生时锁处于可获取状态 - 跨线程传递
std::unique_lock对象是未定义行为，别把它塞进std::thread构造函数
条件变量本身不难，难的是它要求你对线程生命周期、对象析构顺序、锁持有范围有精确控制——稍一错位，就是偶发崩溃或死锁，调试起来比纯计算逻辑麻烦得多。
