std::atomic::wait是C++20引入的轻量等待机制，需编译器（GCC 11+/Clang 12+/MSVC 19.30+）、标准库及系统支持（如glibc≥2.34），必须配对notify_one/notify_all并用循环检查条件以应对虚假唤醒。
std::atomic::wait 是 C++20 引入的，不是所有编译器默认启用
它依赖 std::atomic 的等待/通知机制（类似 futex），但需要编译器和标准库支持。GCC 11+、Clang 12+、MSVC 19.30+ 才完整支持，且必须开启 C++20 模式：-std=c++20。否则调用 wait 会触发编译错误或退化为忙等（fallback busy-wait），完全失去意义。
检查是否可用最直接的方式是编译时断言：
#include <atomic><br>static_assert(std::atomic<int>::is_always_lock_free); // 基础保障<br>static_assert(__cpp_lib_atomic_wait >= 201907L); // C++20 wait 特性宏
- Linux 上需 glibc ≥ 2.34（否则即使编译通过，
wait可能 silently fallback） - macOS 目前（截至 macOS 14）libstdc++/libc++ 均未实现
wait，调用会抛std::system_error或崩溃 - Windows 上 MSVC 已支持，但 MinGW-w64 仍普遍不支持
std::atomic::wait 必须搭配 std::atomic::notify_one/notify_all 使用
wait 不是轮询 —— 它把线程挂起，直到被显式唤醒或虚假唤醒（spurious wakeup）。如果没人调用 notify_one 或 notify_all，线程可能永远阻塞（除非带超时）。
典型误用是只写 wait 不配对 notify，或者在错误线程里 notify（比如 notify 发生在 wait 之前，而没有内存序保证可见性）：
立即学习“C++免费学习笔记（深入）”；
std::atomic<int> flag{0};<br>// 线程 A：<br>flag.wait(0); // 等待 flag != 0<br><br>// 线程 B：<br>flag.store(1, std::memory_order_relaxed);<br>flag.notify_one(); // ✅ 正确：store 后 notify<br>// ❌ 错误：先 notify 再 store → A 可能永远等不到
- notify 必须发生在 wait 观察到旧值之后，推荐用
memory_order_seq_cst或至少memory_order_releasestore +memory_order_acquireload 配合 - notify_one 和 notify_all 性能差异明显：notify_all 唤醒所有等待者，适合广播场景；notify_one 更轻量，适用于一对一同步
- wait 的参数是“期望值”，即当原子变量值**等于该值时才挂起**；一旦值变化（哪怕只是临时变过），wait 就返回
避免虚假唤醒导致逻辑错乱
wait 可能无理由返回（spurious wakeup），所以不能假设返回就一定是因为 notify。必须用循环检查条件是否真正满足：
std::atomic<bool> ready{false};<br><br>// ✅ 正确写法<br>while (!ready.load(std::memory_order_acquire)) {<br> ready.wait(false); // 等待 ready 变成 true<br>}<br><br>// ❌ 错误：一次 wait 不够<br>ready.wait(false); // 可能虚假唤醒，此时 ready 仍是 false
- 循环中 reload 是必须的，否则无法区分真实状态变化和虚假唤醒
- reload 的 memory order 应与 wait 前的判断一致（通常用
memory_order_acquire） - 如果条件复杂（比如多个原子变量联合判断），
wait无法直接支持，得退回到 mutex + condition_variable
wait 超时版本容易被忽略的精度和平台行为差异
wait 有带 std::chrono::duration 的重载，但它的超时语义不是“最多等 X 时间”，而是“至少等 X 时间后检查一次当前值”——实际唤醒时间可能显著延迟，尤其在负载高或调度不及时的系统上。
- Linux 上基于 futex 的超时是相对精确的；Windows 上基于 SRWLock，延迟可能达毫秒级
- 超时后函数返回，但不修改原子变量值，也不保证后续 notify 是否还有效（notify 可能在超时前已发出但未送达）
- 不要用
wait_for替代心跳检测：它不提供周期性回调能力，仅单次等待 - 若需可靠定时+等待组合，应使用独立 timer 线程 +
notify，而非依赖 wait 超时精度
高性能等待的关键不在“怎么等”，而在“谁来通知、何时通知、通知是否被看见”。wait 很轻，但它的正确性完全依赖 notify 的时机和内存序——这点比代码写几行难得多。
