std::atomic::wait不是condition_variable的轻量替代品，仅当值严格相等、类型大小≤指针宽且平台支持时才真正休眠，否则自旋；notify_one不保证唤醒顺序，需循环检查状态并配对内存序。
std::atomic::wait 和 notify 不是 condition_variable 的轻量替代品，它们只在严格满足三个条件时才真正休眠；否则就是自旋，甚至可能永远不唤醒。
std::atomic::wait 什么时候会退化成自旋
它只在以下三点同时成立时调用 futex 或 WaitOnAddress 进入内核等待：
-
load()返回值与传入的expected参数按位完全相等（不是逻辑相等） - 原子类型大小 ≤ 指针宽度，且满足
std::is_trivially_copyable_v<t></t> - 平台原生支持：Linux 需 futex，Windows 需
WaitOnAddress，macOS 当前仍回退到 mutex+condvar 模拟
常见错误是写成 counter.wait(0) —— 若 counter 是 std::atomic<uint64_t></uint64_t> 但只存低 32 位，高位可能含未初始化垃圾值，导致按位比较永远失败。正确做法是先 int expected = counter.load();，再 counter.wait(expected)。
notify_one 唤醒谁？别猜，也别依赖顺序
notify_one 不唤醒“最先等的那个”，也不保证唤醒你期望的线程；它只是通知内核：“有人在等这个原子变量，挑一个唤醒吧”，最终由调度器决定。
立即学习“C++免费学习笔记（深入）”；
-
notify_all只唤醒所有当前阻塞在该原子变量上的线程，不是广播给所有曾等过的人 - 被唤醒的线程必须重新检查状态，因为存在虚假唤醒（spurious wakeup）
- 若多个线程在不同时间点调用
wait，但共享同一个expected值，notify_one可能唤醒一个早已过期的等待者
所以实际编码中，几乎总要配合 while (state.load() == expected) 循环使用，而不是 if。
为什么不能用 std::atomic::wait 替代 std::condition_variable::wait
根本差异不在性能，而在锁语义：
-
std::condition_variable::wait必须绑定std::unique_lock，内部自动解锁/重锁，保护的是整个临界区数据 -
std::atomic::wait完全不碰锁，它只盯着那个原子变量本身是否变化；它无法阻止其他线程并发修改该变量所代表状态背后的非原子数据
典型错误：用 std::atomic<bool> ready</bool> 表示“结构体已初始化完毕”，但写线程只对 ready 调用 store(true, std::memory_order_release)，却没对结构体字段加内存序约束；读线程 ready.wait(false) 唤醒后直接访问结构体字段，可能看到部分更新的脏数据。
std::atomic::wait 的正确使用模式
它最适合用于纯状态信号，且该状态变更与后续操作之间无共享数据依赖。正确写法必须包含三要素：
- 循环检查：
while (!flag.load(std::memory_order_acquire)) { flag.wait(false); } - 显式加载 + 传参：
int expected = flag.load(); flag.wait(expected);，禁止字面量传参 - 配对内存序：通知方
store(..., std::memory_order_release)+notify_one()，等待方load(..., std::memory_order_acquire)建立同步点
最易被忽略的一点：notify_one() 和 store() 之间不能插入任何可能被重排的非原子操作，否则写入对等待线程不可见。
