std::atomic::wait不能直接用于轮询，因其设计为事件驱动式等待，需配合notify_one/notify_all使用；频繁调用会导致性能崩溃且逻辑错误；正确做法是store后notify，或采用自旋+yield+wait混合策略。
std::atomic::wait 为什么不能直接用于轮询标志位
它根本不是为轮询设计的——std::atomic::wait 是等待某个值**恰好等于预期值**时被唤醒，底层依赖 futex（Linux）或类似内核同步原语，必须配合 std::atomic::notify_one/notify_all 使用。直接在 while 循环里反复调用 wait 不仅逻辑错（每次都要传当前期望值），还会因频繁系统调用拖垮性能，甚至触发内核拒绝（如 EAGAIN 频发）。
正确用法：wait + notify 构成“事件驱动式等待”
典型场景是生产者-消费者模型中，消费者等一个 std::atomic<bool></bool> 变成 true，但必须由生产者显式通知：
std::atomic<bool> ready{false};</bool>- 消费者线程：
ready.wait(false);—— 阻塞直到值变为true（注意：不是“等到变成 true”，而是“等到值不等于 false”） - 生产者线程做完工作后：
ready.store(true, std::memory_order_relaxed); ready.notify_one();
关键点：两次原子操作必须分离；store 后再 notify，否则可能丢失唤醒；wait 的参数是“当前认为的旧值”，不是“想等到的目标值”。
替代轮询的高性能方案：自旋 + yield + wait 混合策略
如果真需要低延迟响应（比如实时线程等标志），纯 wait 唤醒有微秒级延迟，可结合短时自旋：
立即学习“C++免费学习笔记（深入）”；
- 先自旋几十到几百次（用
std::atomic<bool>::load(std::memory_order_acquire)</bool>） - 期间插入
std::this_thread::yield()或_mm_pause()（x86）降低功耗 - 超时后 fallback 到
wait，避免空转耗尽 CPU
示例节选：
while (!flag.load(std::memory_order_acquire)) {
for (int i = 0; i < 100; ++i) {
if (flag.load(std::memory_order_acquire)) return;
_mm_pause();
}
flag.wait(false); // 此时 flag 仍为 false，安全
}
注意：wait 调用前必须确认值仍是期望旧值，否则可能跳过唤醒。
常见错误和兼容性坑
Windows MSVC 19.35+ 和 GCC 12+ 才完整支持 std::atomic::wait；Clang 需要 -std=c++20 -D_LIBCPP_HAS_NO_ATOMIC_WAIT 关闭模拟实现。常见报错：
-
error: 'wait' is not a member of 'std::atomic<bool>'</bool>→ 编译器或标准库版本太低 - 程序 hang 在
wait→ 忘记调用notify_one，或 notify 发生在 wait 之前（无唤醒丢失机制） - 多线程下偶尔失效 →
wait参数用了过期的局部副本，应每次重新 load
最易忽略的是：wait/notify 只对同一内存位置有效，跨 cache line 或不同 atomic 对象间无效；且 notify 不保证立即唤醒，只是“允许唤醒”，实际调度仍由 OS 决定。
