std::atomic_wait在实际项目中基本不能用，因其仅在特定条件下有效且主流标准库实现（如libstdc++、libc++）尚未支持，调用会崩溃或降级为忙等待；必须满足lock-free trivial类型、正确生命周期与调用顺序等严苛条件。
std::atomic_wait 不是“高性能挂起空闲线程”的通用解法——它只在特定条件下有效，且目前（C++20/C++23）支持极差，多数标准库实现（包括 libstdc++、libc++ 主流版本）根本没实现，调用会直接 std::terminate() 或静默降级为忙等待。
为什么 std::atomic_wait 在实际项目中基本不能用
这是最常被忽略的前提。C++20 引入 std::atomic_wait / std::atomic_notify_one 等，语义上类似 futex 或 Windows WaitOnAddress，但落地严重滞后：
- MSVC 19.35+（VS 2022 17.5+）开始提供实验性支持，需定义
_ENABLE_ATOMIC_WAIT宏且仅限 x64 - libstdc++（GCC 13/14）仍标记为
// TODO: implement，调用直接 abort - libc++（LLVM 18）仅在 Linux + glibc 2.34+ 上有条件启用，且需链接
-latomic - 所有实现均不支持
std::atomic<bool>或std::atomic<int>以外的类型 wait
std::atomic_wait 的正确使用姿势（仅限已确认支持的环境）
即便环境支持，也必须严格满足三个条件，否则行为未定义或退化：
- 等待变量必须是 lock-free 的 trivial 类型（
std::atomic_int、std::atomic_bool），且生命周期跨越 wait/notify（不能是栈上临时变量） - 必须先用
load(std::memory_order_relaxed)读取当前值，再传给std::atomic_wait；不能传表达式或中间变量 - notify 端必须用
std::atomic_notify_one或std::atomic_notify_all，且发生在修改原子变量之后（典型顺序：modify → notify）
示例（仅作语法示意，运行前务必验证 stdlib 支持）：
立即学习“C++免费学习笔记（深入）”；
std::atomic_int ready{0};
// 线程 A
void waiter() {
int expected = 0;
while (ready.load(std::memory_order_relaxed) == 0) {
std::atomic_wait(&ready, expected); // 注意：传的是 &ready 和当前期望值
}
}
// 线程 B
void notifier() {
ready.store(1, std::memory_order_relaxed);
std::atomic_notify_one(&ready); // 必须在 store 之后
}
替代方案：真正可用的低开销等待方式
生产环境应绕过 std::atomic_wait，改用成熟、跨平台、可预测的机制：
- Linux：用
eventfd+epoll_wait，内核级唤醒，零忙等，延迟低于 1μs - Windows：用
CreateEvent+WaitForSingleObject，同样无轮询 - 跨平台：
std::condition_variable配合std::mutex—— 虽有锁开销，但现代实现（如 glibc）在无竞争时已优化为 futex 等价操作，实测比手写自旋+yield 更省电 - 若必须无锁：用
std::this_thread::yield()+ 指数退避，避免 CPU 占满，但仅适合唤醒频率极低的场景
真正关键的不是“怎么挂起”，而是“谁负责唤醒”和“唤醒信号是否可靠”。std::atomic_wait 把责任推给底层 futex 实现，而现实里这个链路太脆弱——一个没打补丁的 glibc，或一个旧版 clang，就能让整条路径失效。与其赌标准库进度，不如用 epoll 或 condition_variable 把逻辑收束在可控范围内。
