std::atomic::wait 不能直接使用，因为它是 C++20 新增特性，仅对部分整型和指针特化支持（如 std::atomic<int32_t>、std::atomic<void*>），不支持 std::atomic<bool> 和自定义类型，且需编译器（GCC≥12/Clang≥14）、标准库及操作系统（Linux内核≥2.6.22/Win10 1903+）协同支持，否则编译失败或退化为锁模拟。
std::atomic::wait 为什么不能直接用
因为 std::atomic::wait 在 C++20 才正式加入标准，且仅对部分整型和指针特化可用（如 std::atomic<int></int>、std::atomic<:uintptr_t></:uintptr_t>），std::atomic<bool></bool> 和 std::atomic<t></t>（自定义类型）**不支持**。很多编译器（如 GCC 11–12 默认）甚至默认禁用该特性，需显式开启 C++20 并链接 libstdc++ 的新原子等待实现。
常见错误是写成：
std::atomic<bool> flag{false};
flag.wait(false); // 编译失败：no member named 'wait'
根本原因是 std::atomic<bool></bool> 通常不满足 std::atomic_wait_supported_v 条件 —— 它底层可能用锁模拟，无法对接 futex 或 Windows WaitOnAddress。
- 检查是否启用 C++20：
-std=c++20 - 确认编译器版本：GCC ≥ 12（完整支持）、Clang ≥ 14（需
-D_LIBCPP_ENABLE_ATOMIC_WAIT） - 运行时依赖：Linux 需内核 ≥ 2.6.22（futex 支持），Windows 需 Win10 1903+（
WaitOnAddress）
哪些 std::atomic 类型能真正 wait
只有满足 std::atomic_wait_supported_v<t></t> 的类型才提供 wait/notify_one/notify_all 成员函数。实际可用的主要是：
立即学习“C++免费学习笔记（深入）”；
-
std::atomic<char>、std::atomic<int32_t>、std::atomic<int64_t> -
std::atomic<std::intptr_t>、std::atomic<std::uintptr_t> -
std::atomic<void*>（注意不是std::atomic<T*>，后者不保证可等待）
典型误用：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::atomic<size_t> counter{0};
counter.wait(0); // ✅ 可行（size_t 通常是 uint64_t 或 uint32_t）
std::atomic<long long> val{1};
val.wait(1); // ✅ 可行
std::atomic<double> d{0.0};
d.wait(0.0); // ❌ 编译失败：double 不支持原子等待
关键点：类型必须是 trivially copyable、无锁（is_lock_free() 返回 true），且底层硬件/OS 提供对应原语。
wait + notify 的正确配对姿势
wait 是自旋 + 系统调用混合策略：先短暂自旋，再挂起线程；notify_one 不保证唤醒正在 wait 的线程 —— 如果 notify 发生在 wait 之前（即“丢失唤醒”），线程会永远阻塞。必须靠应用层状态重检规避。
标准写法必须带 while 循环：
std::atomic<int> state{0};
// 等待 state 变为 1
while (state.load() != 1) {
state.wait(0); // 等待值仍为 0 时才挂起
}
// 此时 state == 1（但可能已被其他线程改回 0，所以不能省略 while）
-
wait(expected)只在当前值等于expected时才挂起；一旦值变化或被 notify，立即返回，但返回后需重新 load 判断 -
notify_one()唤醒**一个**等在相同地址、相同 expected 值上的线程（注意：不同 expected 值视为不同等待队列） - 多个线程用不同 expected 调用 wait，互不干扰；同一 expected 下 notify_one 有调度不确定性
性能陷阱：别在 hot path 上频繁 wait/notify
wait 的系统调用开销远高于普通原子操作，尤其在高竞争场景下，反复 notify + wake-up 可能比自旋更慢。实测显示：当等待时间 while(!flag.load());）反而更快；> 100μs 才体现 wait 优势。
真实建议：
- 仅用于“事件驱动型”等待（如 worker 等待任务队列非空），而非轮询式 busy-wait 替代品
- 避免对同一 atomic 变量高频 notify：每秒几千次以上 notify 可能触发内核队列争用
- 调试时加
assert(state.is_lock_free())，确保没退化成 mutex 模拟 - 跨线程通信优先考虑
std::condition_variable+std::mutex，除非 profiling 确认 atomic wait 是瓶颈且适用
最易被忽略的一点：wait/notify 的内存序默认是 std::memory_order_seq_cst，但你可以显式传入更弱的序（如 state.wait(0, std::memory_order_acquire)），不过多数场景没必要动它 —— 错配 memory order 会导致唤醒失效或数据竞争。
