std::atomic::wait 必须搭配 notify_one/notify_all 使用，因其依赖内核休眠机制，无通知则永久挂起；参数需传 const T& 且确保引用对象生命周期覆盖调用；C++20 特性，平台支持有限，不可用时退化为忙等。
std::atomic::wait 为什么需要搭配 std::atomic::notify_one/notify_all 使用
std::atomic::wait 不是轮询，也不是阻塞式自旋，它依赖操作系统内核的 futex（Linux）或等价同步原语（Windows/macOS）实现真正休眠。但前提是：必须有其他线程调用 std::atomic::notify_one 或 std::atomic::notify_all 才能唤醒等待线程。如果没人通知，wait 就永远挂起——这不是 bug，是设计使然。
常见错误是只写 wait 却漏掉对应 notify，尤其在多生产者/单消费者场景里，容易漏 notify 或 notify 时机错位。
- 通知必须发生在被等待的原子变量**已更新为新值之后**，且新值要和
wait的预期值不一致（否则立即返回） - 不能在持有锁期间调用
notify后立刻释放锁——这会导致唤醒丢失（wakeup lost），正确做法是先 unlock 再 notify，或用notify_all降低风险 -
notify_one只唤醒一个等待者，适合一对一场景；notify_all开销略大但更安全，尤其当多个线程可能 wait 同一变量时
std::atomic::wait 的参数陷阱：为什么传 const T& 而不是值
std::atomic::wait 第二个参数是 const T& expected，不是值拷贝。这意味着它会**按引用读取你传入的对象**，并在内部与原子变量当前值做比较。如果你传的是局部变量、临时对象或已销毁对象的引用，行为未定义。
典型翻车现场：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 写成
flag.wait(true)—— 错！true是临时 bool，引用绑定到临时对象，生命周期仅到该行结束 - 写成
auto expected = flag.load(); flag.wait(expected);—— 看似合理，但如果flag在 load 和 wait 之间被改过，wait就会直接返回（因为值已变），失去等待意义 - 正确做法：用
flag.wait(flag.load())，让load()返回的值在wait内部被安全使用；或者显式声明变量并确保其生命周期覆盖整个wait调用
std::atomic::wait 在不同平台上的可用性与编译条件
std::atomic::wait 是 C++20 引入的特性，但不是所有标准库实现都默认启用。libstdc++（GCC）从 13.1 开始支持，MSVC 从 19.35（VS 2022 17.5）起支持，libc++（Clang）需开启 -std=c++20 -D_LIBCPP_ENABLE_CXX20_ATOMIC_WAIT。
运行时还依赖内核能力：Linux 要求 kernel ≥ 2.6.32（futex 支持），glibc ≥ 2.3.2；Windows 需要 Windows 10 1607+；macOS 目前不支持（截至 macOS 14，std::atomic::wait 是空操作或抛异常）。
- 编译期检查：可用
__cpp_lib_atomic_wait宏判断是否启用，例如#if __cpp_lib_atomic_wait >= 201907L - 若不可用，退化方案只能是
while (var.load() == expected) std::this_thread::yield();，但这是忙等，CPU 占用高 - 不要依赖
std::atomic_flag::wait替代，它不接受预期值，语义不同
wait/notify 组合的实际性能边界在哪
std::atomic::wait 的优势只在“等待时间远大于上下文切换开销”时才明显。如果变量变化非常频繁（比如微秒级响应），或者等待时间极短（
真实瓶颈往往不在 wait 本身，而在 notify 的调用频率和线程调度延迟：
- 每秒 notify 百万次以上时，内核 futex 哈希表竞争可能成为瓶颈，此时考虑批量状态合并或改用信号量
- notify 后线程实际被调度执行存在毫秒级抖动，无法保证实时性；对硬实时场景，仍需专用 RTOS 或用户态轮询
- 调试时注意：GDB 默认不拦截 futex 等待，
wait线程在 gdb 中可能显示为 “sleeping”，但bt仍可看到调用栈
最易被忽略的一点：wait 不提供内存序保证，它只同步该原子变量的修改。如果等待逻辑依赖其他非原子变量的状态，必须额外用 memory_order_acquire 或 fence，否则可能读到陈旧数据。
