std::notify_all_at_thread_exit并非通知线程结束的通用机制，而是当前线程退出前安全唤醒等待线程的延迟通知工具，必须配合condition_variable、mutex及wait使用，且对参数生命周期和调用时机有严格要求。
std::notify_all_at_thread_exit 不能直接“通知线程结束”
它不用于通知“某个线程即将结束”，而是用于在**当前线程即将退出时**，安全地唤醒其他等待中的线程。常见误解是把它当成了类似 pthread_cancel 或 std::thread::join 的同步机制——实际上它只是个延迟 notify 的工具，且必须配合 std::condition_variable 和 std::mutex 在特定上下文中使用。
必须搭配 std::condition_variable::wait 配合使用
该函数只对处于 wait 状态的线程起作用；它不会唤醒已超时、已中断或根本没调用 wait 的线程。典型场景是：主线程启动 worker 线程，worker 线程完成任务后，通过 std::notify_all_at_thread_exit 告知主线程“我马上退出”，主线程则在 cv.wait 中等待这个信号。
- 必须先调用
cv.wait(lock, pred)进入等待，否则notify_all_at_thread_exit无意义 -
pred（谓词）应反映线程实际退出条件，比如[&done]{ return done.load(); } - 调用
std::notify_all_at_thread_exit前，必须确保lock已释放（通常靠std::unique_lock析构自动释放） - 不能在
std::thread构造函数里直接传入 lambda 并在里面调用它——因为 lambda 执行完即退出，无法保证 notify 发生在“线程真正退出前”
正确调用顺序和生命周期约束
核心限制：std::notify_all_at_thread_exit 必须在目标线程函数末尾、所有局部对象析构前调用，且其参数（cv 和 lock）的生命周期必须延续到线程完全退出。这意味着：
-
std::condition_variable和std::mutex必须是全局、静态或由其他线程长期持有，不能是 worker 线程的局部变量 -
std::unique_lock<:mutex></:mutex>必须仍有效（未被 move 或析构），所以常需显式声明并保持作用域 - 不能在
try/catch块中提前 return，否则可能跳过 notify 调用 - 示例片段：
std::condition_variable cv;
std::mutex mtx;
std::atomic<bool> done{false};
void worker() {
std::unique_lock<std::mutex> lk(mtx);
// ... work ...
done = true;
lk.unlock(); // 必须先解锁，否则 notify 会阻塞
std::notify_all_at_thread_exit(cv, std::move(lk));
}
替代方案更常用也更安全
现实中几乎没人用 std::notify_all_at_thread_exit，因为它的使用门槛高、易出错，且功能可被更清晰的方式替代：
立即学习“C++免费学习笔记（深入）”；
- 用
std::promise/std::future：worker 线程结束前set_value()，主线程wait() - 用
std::atomic+cv.notify_one()：worker 设置标志后手动 notify，无需依赖线程退出时机 - 用
std::thread::join()：最直接——你本就关心线程结束，那就等它结束 -
std::notify_all_at_thread_exit主要用于极少数需要“确保 notify 发生在线程所有资源释放之后”的底层库实现，比如模拟 pthread_cleanup_push 的行为
真正容易被忽略的是：它不是线程通信的通用手段，而是一个有严格执行时序要求的“收尾钩子”。一旦搞错 lock 生命周期或调用位置，就会静默失效——既不报错，也不唤醒，调试起来非常隐蔽。
