std::atomic_wait能替代while循环因其使线程真正休眠而非忙轮询，但需满足三条件：原子类型为整型且lock-free、等待前值等于expected、notify必须在store之后且保证内存序。
std::atomic_wait 为什么能替代 while 循环
因为 std::atomic_wait 让线程在等待时真正休眠，不消耗 CPU 周期；而 while (flag.load() == false) 是忙轮询，CPU 持续执行判断指令。关键前提是：目标原子变量必须是 lock-free 的（flag.is_lock_free() == true），否则 std::atomic_wait 会退化为自旋或直接返回错误（C++20 标准未强制要求 fallback 行为，实际实现如 libc++ 和 MSVC 在非 lock-free 场景下可能直接忽略等待或抛出异常）。
使用 std::atomic_wait 的最小可行步骤
必须满足三个条件才能安全调用：std::atomic_wait 不是“设个标志就能等”，它依赖底层 futex（Linux）或 WaitOnAddress（Windows）机制，所以：
- 原子变量类型只能是
std::atomic<bool></bool>、std::atomic<:uint32_t></:uint32_t>等整型原子类型（不能是std::atomic<:string></:string>或自定义结构体） - 等待前需确保变量值与期望值一致（即当前值等于你传入的
expected参数），否则调用立即返回 - 必须在调用前用
std::atomic_notify_one或std::atomic_notify_all配合唤醒 —— 单纯改值（flag.store(true)）不会自动触发等待线程唤醒
一个典型但易错的 wait/notify 配对写法
下面这段代码看似合理，实则有竞态漏洞：
// 错误示范：notify 在 store 之后，但 wait 可能在 store 后、notify 前已进入等待 flag.store(true, std::memory_order_relaxed); std::atomic_notify_one(&flag); // 这里 notify 可能失效
正确顺序是：
立即学习“C++免费学习笔记（深入）”；
- 先用带 memory_order_seq_cst 的 store 设置新值（或至少用
memory_order_release） - 再调用
std::atomic_notify_one(&flag)—— 通知动作本身不修改内存顺序，但必须发生在 store 之后且保证可见性 - 等待端必须用
std::atomic_wait(&flag, false)，且确保调用前flag.load()确实为false
更稳妥的做法是把 notify 放在 store 的同一原子操作之后，例如：
flag.store(true, std::memory_order_release); std::atomic_notify_one(&flag);
std::atomic_wait 在不同平台的实际表现差异
Linux（glibc + kernel ≥ 5.3）支持完整 futex_waitv，std::atomic_wait 效率接近 pthread_cond_wait；Windows（MSVC + Windows 10 2004+）通过 WaitOnAddress 实现，延迟略高但稳定；macOS 目前（截至 macOS 14）**不支持** std::atomic_wait，Clang/libc++ 会编译通过但运行时报 std::system_error（error code: operation_not_supported）。这意味着跨平台项目若启用该特性，必须做运行时检测或编译期兜底。
容易被忽略的一点：即使平台支持，如果原子变量被声明为 static 全局变量，某些链接器或初始化顺序问题可能导致 std::atomic_wait 在 main() 之前调用失败 —— 最好只在 main() 启动后、线程启动前初始化原子变量。
