std::atomic::wait比while循环更省CPU，因为它让线程在内核态挂起不消耗CPU时间片，而while循环是忙等并可能引发缓存行频繁无效化；但仅对整型或指针等lock-free类型有效，且需平台支持futex/WaitOnAddress等原语，否则退化为自旋。
std::atomic::wait 为什么比 while 循环更省 CPU
因为 std::atomic::wait 让线程在内核态挂起，不消耗 CPU 时间片；而 while (flag.load() != true) 是忙等，持续执行 load 指令，尤其在多核系统上还可能触发缓存行频繁无效化（cache line bouncing），实际延迟反而更高。
但注意：std::atomic::wait 不是万能的——它只对 std::atomic<T> 中 T 是整型或指针类型（且满足 is_always_lock_free）时才可用。浮点型、结构体、std::atomic<bool> 都不支持 wait/notify（C++20 标准明确限定）。
-
std::atomic<int>、std::atomic<uintptr_t>、std::atomic<void*>可用 -
std::atomic<bool>不能调用wait—— 编译失败，错误信息类似：no member named 'wait' in 'std::atomic<bool>' - 即使
T合法，也需确保该原子类型在目标平台 lock-free（可用is_always_lock_free静态成员检查）
如何正确配对使用 wait / notify_one / notify_all
必须严格遵循“先 wait，后 notify”顺序，否则 notify 可能丢失。典型错误是生产者先 notify_one()，消费者还没来得及 wait()，信号就没了。
解决办法：用一个初始值做“状态快照 + 等待”双重检查：
立即学习“C++免费学习笔记（深入）”；
// 示例：等待 flag 变为 1
std::atomic<int> flag{0};
// 消费者侧
int expected = 0;
while (flag.load(std::memory_order_acquire) == 0) {
flag.wait(expected, std::memory_order_acquire); // 注意：传入的是当前期望值，不是地址
expected = 0; // 如果 flag 被改过，下次 wait 前需更新 expected
}
-
wait(expected, order)的expected是值，不是引用或指针 - 每次
wait返回时，原子变量值可能已变，所以循环中必须重新load判断 -
notify_one()和notify_all()不同步，也不保证唤醒时机，仅是“发信号”动作 - 多个线程对同一原子变量调用
wait是安全的，但需确保所有等待者都用相同内存序（推荐统一用std::memory_order_acquire）
wait 在哪些场景下会失效或退化成忙等
某些 STL 实现（如较老版本 libc++ 或部分 Windows MSVC 工具链）对 std::atomic::wait 的底层支持不完整，会 silently fallback 到自旋等待，表现为 CPU 占用率陡升却无实际唤醒。
验证方法：在 Linux 上用 perf record -e sched:sched_switch 观察线程是否真正休眠；或直接看 /proc/<pid>/stack 是否出现 futex_wait 调用。
- Clang 15+ / GCC 12+ 在 Linux x86_64 上基本可靠；MSVC 2022 17.5+ 开始支持，但需启用
/std:c++20且目标 Windows 版本 ≥ RS5（1809） - macOS 目前（截至 macOS 14）仍不支持
std::atomic::wait，调用会抛std::system_error异常，错误码为std::errc::operation_not_supported - 嵌入式或实时系统（如 Zephyr、FreeRTOS）几乎都不提供 futex 等机制，
wait不可用
替代方案：当 wait 不可用时怎么写轻量等待
如果平台不支持 wait，又不想写纯忙等，可以用 std::this_thread::yield() 或短时 sleep_for 插入退避逻辑：
while (flag.load(std::memory_order_acquire) == 0) {
std::this_thread::yield(); // 让出当前时间片，但不保证调度延迟
// 或更稳妥：
// std::this_thread::sleep_for(1us);
}
-
yield()在高负载或单核系统上效果有限，有时等同于空转 -
sleep_for(1us)在多数 POSIX 系统上实际最小分辨率约 10–15ms，别指望真睡 1 微秒 - 真正低延迟场景（如高频交易、实时控制），应避免用户态等待，改用事件驱动、信号量或平台专用同步原语（如 Linux eventfd）
最易被忽略的一点：无论用 wait 还是退避，都必须确保原子变量的内存序与配套的 store 端一致——比如消费者用 acquire，生产者就必须用 release 或更强序，否则编译器/CPU 重排可能导致状态不可见。
