std::atomic::wait 是 C++20 引入的原子等待机制，需编译器（GCC 11+/Clang 12+/MSVC 19.30+）和 -std=c++20 支持，仅适用于 trivially copyable 且 is_always_lock_free 的类型（如 int、指针），必须配对 notify_one/notify_all 使用，唤醒后需循环检查条件，并注意内存序以确保相关非原子数据的可见性。
std::atomic::wait 是 C++20 才有的东西，别在 C++17 里找
如果你编译报错 no member named 'wait'，大概率是因为标准版本不够。C++20 引入了 std::atomic 的等待/通知机制（基于 futex 或类似内核原语），但 GCC 11、Clang 12+ 才开始支持，且需显式开启 -std=c++20（或 c++2b）。MSVC 从 19.30（VS 2022 17.0）起支持，但早期版本可能只支持整数类型。
常见误判点：
- 用
std::atomic<bool></bool>调wait()：合法，但某些旧版 libstdc++ 实现会静默退化为忙等 - 用
std::atomic<:string></:string>：编译失败——wait()只支持 trivially copyable 且is_always_lock_free为 true 的类型（通常是int、long、指针、bool） - 忘记链接 pthread（Linux 下某些 libc++ 配置需要）
std::atomic::wait 必须配对使用 notify_one / notify_all
它不是条件变量替代品，而是“值变更通知”机制：线程阻塞在某个原子值等于期望值时，另一个线程修改该值并调用 notify_one() 或 notify_all() 唤醒。不发通知，wait() 可能永远挂起（除非被信号中断）。
典型用法：
立即学习“C++免费学习笔记（深入）”；
std::atomic<int> flag{0};
// 线程 A
flag.wait(0); // 阻塞直到 flag != 0
// 线程 B
flag.store(1, std::memory_order_relaxed);
flag.notify_one(); // 必须调用！
注意：
-
notify_one()和notify_all()不保证唤醒顺序，也不保证唤醒后值仍为期望值（可能被其他线程抢先改写） - 唤醒后应再次检查条件，推荐写成循环：
while (flag.load() == 0) flag.wait(0); -
notify_*()可以在wait()之前调用——如果通知早于等待，wait()会立即返回（这是“惊群”问题的根源，但也是设计使然）
内存序影响 wait/notify 的可见性，别全用 relaxed
wait() 内部隐含 acquire 语义，notify_*() 隐含 release 语义，但它们只对**该原子变量本身**生效。如果你在 notify 前写入其他非原子数据，必须确保这些写入对 wait 唤醒后的线程可见。
错误示范：
std::atomic<int> ready{0};
int data = 42;
// 线程 A
data = 100; // 非原子写入
ready.store(1, std::memory_order_relaxed); // ❌ 松散序无法同步 data
ready.notify_one();
// 线程 B
ready.wait(0);
std::cout << data; // 可能输出 42
正确做法：
- 把
ready.store(1, std::memory_order_release)和ready.wait(0)（自动 acquire）配对，形成 release-acquire 同步 - 或者将
data也改为std::atomic<int></int>并用相同原子变量协调 - 避免混用 relaxed 和 non-relaxed —— 容易漏掉同步点
wait 性能好 ≠ 适合所有场景，小心虚假唤醒和负载不均
在支持 futex 的 Linux 上，wait() 确实比 while-loop + load() 省 CPU，但它仍有开销：每次调用涉及用户态/内核态切换，且内核需维护等待队列。高频短等待（如微秒级）反而不如自旋。
真实瓶颈常出现在：
- 多个线程 wait 同一个原子变量，notify_one() 随机唤醒一个，其余继续等 —— 如果业务逻辑要求“最先等待者优先”，得自己加队列
- wait 被信号中断（
EINTR），libc++ 默认重试，libstdc++ 可能抛异常，需查文档或封装容错 - 调试时 attach gdb 可能导致 wait 永久阻塞（gdb 抑制信号传递），建议开发期加超时 fallback（虽然标准库没提供 timeout 版本）
真正省心的高性能等待，往往要结合 std::condition_variable（带 predicate 和超时）或更上层的 async/await 框架。atomic::wait 是个好工具，但不是万能胶。
