std::atomic_wait 目前仍是实验性机制，GCC未实现、LLVM仅Linux有限支持、MSVC需宏启用、macOS回退模拟，且仅支持lock-free trivial类型，否则行为未定义。
std::atomic_wait 在绝大多数项目里根本不能用
它不是“高性能挂起”的开箱即用方案，而是目前（2026 年中）仍处于实验性、碎片化支持的机制。libstdc++（GCC 13/14）标记为 // TODO: implement，调用直接 std::terminate()；libc++（LLVM 18）仅在 Linux + glibc 2.34+ 上有条件启用，且必须显式链接 -latomic；MSVC 19.35+（VS 2022 17.5+）需定义 _ENABLE_ATOMIC_WAIT 宏才开启 x64 实验支持。macOS 全面回退到 mutex+condvar 模拟，std::atomic_wait 实质是锁+自旋，毫无优势。
即使环境支持，也必须满足三个硬性条件
缺一不可，否则行为未定义、永久阻塞或静默降级为忙等待：
-
std::atomic_wait只接受std::atomic_int、std::atomic_bool等 lock-free trivial 类型——static_assert(std::is_trivially_copyable_v<int> && sizeof(int) 必须通过</int> - 等待变量生命周期必须长于 wait 操作：不能是栈上局部变量，不能在 lambda 中临时构造后传地址
- 调用顺序必须是 “先
load(std::memory_order_acquire)→ 再传值给std::atomic_wait(&var, expected)→ 修改方必须store(..., std::memory_order_release)后紧接std::atomic_notify_one(&var)”
常见错误写法及对应修复
这些代码看似合理，实则极易出问题：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
错：
while(!ready.load()) { ready.wait(false); }——load()默认是relaxed，可能读缓存旧值，wait传入的false是字面量，不反映最新状态 -
对：
int expected = ready.load(std::memory_order_acquire); while(expected == 0) { ready.wait(expected); expected = ready.load(std::memory_order_acquire); } -
错：先
std::atomic_notify_one(&ready)再ready.store(1)—— 通知发出去时值还是 0，等待线程没进入 wait 状态，信号丢失 -
对：严格按
ready.store(1, std::memory_order_release); std::atomic_notify_one(&ready);顺序执行
真正可用的替代方案
生产环境别赌 std::atomic_wait 的支持程度。低开销等待应选成熟路径：
立即学习“C++免费学习笔记（深入）”；
- Linux：用
eventfd+epoll_wait，内核级唤醒，延迟 - Windows：用
CreateEvent+WaitForSingleObject，同样零轮询、可超时、可跨进程 - 跨平台抽象层：如
folly::ParkingLot或absl::CondVar（底层自动选择最优原语），比手撸std::atomic_wait更可靠
复杂点不在语法，而在“你根本不知道当前构建环境是否真支持它”，以及“即使支持，你能否保证所有调用点都严守内存序与生命周期约束”。把精力花在 eventfd 或 Windows Event 上，远比调试 std::atomic_wait 的 silent fallback 更省时间。
