std::atomic::wait仅在三重约束同时满足时才真正休眠：原子值与expected按位相等、平台支持底层原语、类型大小≤指针宽度且可平凡复制；否则自旋或UB。
std::atomic::wait 和 notify 不是“拿来就能用”的通用通知工具，它们只在满足类型、内存序、状态匹配三重约束时才真正进入内核休眠；否则退化为自旋，甚至触发未定义行为。
std::atomic::wait 什么时候才真正休眠
它只在以下三个条件同时成立时，才会调用 futex_wait 或 WaitOnAddress 进入高效等待：
- 当前原子值
load()的结果与传入的expected参数按位完全相等（注意：不是逻辑相等；例如int64_t存了 32 位值但高位有垃圾，wait(0)就永远不触发） - 目标平台支持底层原语（Linux 需 futex，Windows 需 WaitOnAddress，macOS 目前仍回退到 mutex+condvar 模拟）
- 原子类型大小 ≤ 指针宽度，且满足
std::is_trivially_copyable_v<T>（C++27 才放宽限制）
常见误写：counter.wait(0)；正确写法必须是先 int expected = counter.load()，再 counter.wait(expected)，确保视图一致。
notify_one 唤醒谁？别猜，也别依赖顺序
notify_one 不唤醒“最先等的那个线程”，也不保证唤醒你期望的那个线程——它只是通知内核：“有人在等这个原子变量，挑一个唤醒吧”，最终由调度器决定。
立即学习“C++免费学习笔记（深入）”；
更关键的是：
- 被唤醒的线程必须重新检查状态（因为存在虚假唤醒），不能直接假设条件已满足
-
notify_all是唤醒所有当前阻塞在该原子变量上的线程，不是广播给所有曾等过的人 - 若多个线程在不同时间点调用
wait，但共享同一个expected值，notify_one可能唤醒一个早已过期的等待者
所以实际编码中，几乎总要配合 while (state.load() == expected) 循环使用，而不是 if。
为什么不能用 atomic::wait 替代 condition_variable::wait
核心差异不在性能，而在锁语义：
-
std::condition_variable::wait必须和std::unique_lock绑定，内部自动解锁/重锁，保护的是整个临界区数据 -
std::atomic::wait完全不碰锁，它只盯着那个原子变量本身是否变化；它无法阻止其他线程并发修改该变量所代表状态背后的非原子数据
典型错误：用 std::atomic<bool> ready 表示“结构体已初始化完毕”，但写线程只对 ready 调用 store(true, std::memory_order_release)，却没对结构体字段加内存序约束；读线程 ready.wait(false) 唤醒后直接访问结构体字段，可能看到部分更新的脏数据。
循环检查 + 正确 memory_order 是避免通知丢失的唯一可靠方式
notify_one 和 notify_all 不缓存通知。若 notify 发生在 wait 之前，该次通知即被丢弃。因此必须保证“状态更新 → 通知”发生在“检查状态 → 等待”逻辑之后。
标准写法是：
while (flag.load(std::memory_order_acquire) == false) {
flag.wait(false);
}
注意两点：
- 每次
wait返回后，必须立即load()并验证条件是否真正满足，不可假设唤醒即代表条件成立 - 通知方应在修改所有相关共享数据后，再执行
store(..., std::memory_order_release)+notify_one()，且两者之间不得插入可能被重排的非原子操作
最易被忽略的一点：wait 的参数必须是 load() 得到的瞬时快照，而非字面量或静态值——这是防止因平台对齐/填充导致按位比较失败的硬性要求。
