std::atomic::wait仅支持整型和布尔等特化类型，因其他类型（如std::atomic或自定义结构体）未实现该成员函数，编译直接报错；必须改用支持类型或condition_variable。
std::atomic::wait 为什么不能直接用在所有 std::atomic 类型上
因为 std::atomic::wait 只对整型特化（std::atomic<int></int>、std::atomic<:size_t></:size_t> 等）和指针特化可用，其他类型（比如 std::atomic<bool></bool>、std::atomic<float></float> 或自定义结构体）压根没实现 wait 成员函数——编译直接报错：no member named 'wait'。
常见误操作是给 std::atomic<bool></bool> 调用 wait，结果卡在编译阶段。解决办法只有两个：换成整型（如 std::atomic<int></int>，用 0/1 表示 false/true），或改用 std::condition_variable 配合普通互斥锁（但失去 wait 的无锁等待优势）。
-
std::atomic<bool></bool>不支持wait，必须换为std::atomic<int></int>或std::atomic<:uint8_t></:uint8_t> - 自定义类型哪怕只含一个 int，也不能直接套
std::atomic<mystruct></mystruct>+wait；得用std::atomic_ref包装其底层整型字段（需确保对齐和无竞争访问） - Clang 和 GCC 12+ 才完整支持
wait/notify_one，MSVC 从 19.32（VS 2022 17.2）起支持；低于这些版本会静默降级为忙等（spin-wait），性能断崖下跌
std::atomic::wait 的正确调用姿势和内存序陷阱
它不是“等某个值出现”，而是“等当前值不等于预期值”——语义上更接近 while (load() == expected) pause();，但由内核/硬件优化为可被 notify_one 唤醒的轻量级阻塞。
必须配合 std::atomic::notify_one 或 notify_all 使用，且 notify 发生时，被 wait 的线程**不一定正在 sleep**：如果 notify 先于 wait 执行，通知会丢失（无队列、无计数），这是最常踩的坑。
立即学习“C++免费学习笔记（深入）”；
- 永远先设置好初始状态，再启动等待线程；或用循环检查 +
wait组合避免丢失通知 -
wait默认使用std::memory_order_seq_cst，但你可以显式传入第二个参数，例如a.wait(expected, std::memory_order_acquire)；不过 notify 端也得用对应强度的 store（如store(new_val, std::memory_order_release)），否则可能因重排导致 wait 看不到新值 - 不要在 wait 前用
load()判断再决定是否 wait —— 这中间存在竞态窗口；应直接wait(expected)，让原子操作保证一致性
实际场景中如何避免虚假唤醒和状态撕裂
虽然标准不保证虚假唤醒（unspecified spurious wakeups），但 Linux futex 实现和 Windows WaitOnAddress 在某些内核路径下仍可能发生。更危险的是“状态撕裂”：比如用两个 std::atomic<int></int> 分别表示 ready 和 value，wait 一个、notify 另一个，中间无法保证原子性。
典型做法是把多状态压缩进单个整型：低位表状态，高位表数据；或用 std::atomic<:uint64_t></:uint64_t> 存 struct bitfield（需确保平台支持 8 字节原子操作）。
- 推荐模式：用
std::atomic<:uint64_t></:uint64_t>封装状态+payload，通过位运算打包/解包，一次wait覆盖全部语义 - 若必须多变量协同，改用
std::atomic_flag+ 自旋 + 条件变量兜底，而非强行拼凑多个wait - 调试时可在
wait后加assert(load() != expected)捕获虚假唤醒（仅 debug 构建）
性能对比：wait vs condition_variable vs 自旋等待
在低频变更、高延迟容忍场景下，std::atomic::wait 比 std::condition_variable 快 2–5 倍（省去 mutex 获取/释放、内核事件对象调度开销）；但比自旋等待慢——因为涉及用户态到内核态切换。所以它最适合“等待时间 > 几微秒，且唤醒频率不高”的场景（如 I/O 完成、定时器触发、跨线程任务提交）。
- 高频变更（如每微秒更新一次）请用自旋 +
pause指令，wait反而因上下文切换变慢 - 唤醒后立刻要访问大量共享数据？记得在
wait返回后重新获取必要锁，别假设原子变量变化意味着整个临界区就绪 - 注意 NUMA：跨 socket notify 可能比同 socket 慢 2–3 倍，尤其在 notify_one 时，内核调度未必唤醒最近的 waiter
真正难的是设计出既不丢通知、又不伪唤醒、还能跨平台稳定工作的状态协议——wait 只是工具，状态机逻辑得自己反复推演边界条件。
