std::atomic::wait 更轻量因其直接封装内核原语（如futex），无需mutex加锁/解锁、无等待队列和虚假唤醒；但仅适用于等待原子变量等于某值，且需满足可等待类型、非relaxed存储、最新读取三个前提。
std::atomic::wait 为什么比 std::condition_variable 更轻量？
因为 std::atomic::wait 是内核级 futex（Linux）或 WaitOnAddress（Windows）的直接封装，不涉及 mutex 加锁/解锁、不唤醒额外线程、不维护等待队列——它只在值真正变化时才被唤醒，且无虚假唤醒。而 std::condition_variable 必须搭配 std::mutex 使用，每次 wait() 都要先解锁、挂起、被唤醒后再加锁，开销明显更高。
但注意：它只适用于「等待某个原子变量等于某值」这一种场景，不能像条件变量那样等待任意布尔表达式。
std::atomic::wait 的基本用法和必要前提
必须满足三个条件才能安全调用：std::atomic::wait 才不会 UB：
-
std::atomic类型必须是可等待的（目前仅std::atomic<bool></bool>、std::atomic<:uint32_t></:uint32_t>等整型和bool在主流标准库中支持；std::atomic<int></int>通常也行，但std::atomic<struct></struct>不行） - 该原子对象必须用
std::memory_order::relaxed以外的顺序进行过至少一次存储（否则 wait 可能永远不响应） - 调用前需确保当前线程对这个原子变量的读取是“最新”的（即不能靠寄存器缓存旧值），通常用
load()触发一次读取即可
典型写法：
立即学习“C++免费学习笔记（深入）”；
std::atomic<int> flag{0};
// 线程 A
flag.store(1, std::memory_order_release);
// 线程 B
int expected = 0;
while (flag.load(std::memory_order_acquire) == 0) {
flag.wait(expected, std::memory_order_acquire); // 等待变为非 0
expected = flag.load(std::memory_order_acquire);
}
wait 和 notify 的配对陷阱
常见错误是 notify 太早、太晚，或 notify 次数不够：
-
std::atomic::notify_one()/notify_all()只唤醒正在 wait 的线程；如果 notify 发生在 wait 之前，这次通知就丢失了（无队列缓冲） - 必须用循环检查条件，因为即使被唤醒，也可能只是被信号中断，而非值真变了（POSIX 语义）
-
notify_all()不保证唤醒所有等待者——如果多个线程在等不同值（比如一个等 1、一个等 2），只有匹配expected值的线程才会被唤醒 - 不要在非 relaxed 写入后立刻 notify：确保写入已对其他 CPU 可见，推荐用
store(val, std::memory_order_release)+notify_one()
性能和平台兼容性现实情况
不是所有平台都实现了 std::atomic::wait 的高效路径：
- MSVC 19.3x+、GCC 12+、Clang 14+ 在 Linux/macOS/Windows 上才真正映射到 futex/WaitOnAddress；老版本会退化为自旋+yield，反而更差
- ARM64 上部分 libc++ 实现仍用用户态轮询，慎用
- 调试构建下 wait 可能被禁用（如 libstdc++ 的 _GLIBCXX_DEBUG），导致卡死或编译失败
- 单核设备或实时系统中，wait 可能因调度延迟表现不稳定，此时不如简单 while-loop +
std::this_thread::yield()
如果你只等一个标志位翻转，且目标平台较新，std::atomic::wait 确实更轻——但别为了“轻量”强行替换所有条件变量，它解决不了复杂同步逻辑。
