std::atomic::wait不能替代std::condition_variable，因其仅支持等待原子值等于预期值，不支持任意布尔谓词、无唤醒后重检机制、无互斥锁绑定，且notify可能丢失、无超时功能，平台支持有限。
std::atomic::wait 为什么不能直接替代 std::condition_variable
因为 std::atomic::wait 只能等待「原子值等于某个预期值」这一种条件，而 std::condition_variable 等待的是任意布尔谓词（比如 queue.size() > 0 && !shutdown_flag）。原子等待没有「唤醒后重新检查条件」的语义，也不提供与互斥锁的绑定机制。
常见错误是写成这样：
while (flag.load() == false) {
flag.wait(false); // ❌ 危险：可能错过 notify，且无锁保护
}
这漏掉了竞态窗口：load() 和 wait() 之间 flag 可能已被设为 true 并完成 notify_one()，导致永久阻塞。
用 wait/notify_one 模拟条件变量的基本模式
要安全复现条件变量行为，必须把「条件判断 + 等待」封装在原子操作+内存序协同中，并确保 notify 发生在条件真正满足之后、且对等待方可见。
立即学习“C++免费学习笔记（深入）”；
- 等待方必须用
load(std::memory_order_acquire)读取状态，再调用wait(expected)；wait内部会自动处理 acquire 语义 - 通知方必须先让条件变为真（如修改多个变量），再用
store(new_value, std::memory_order_release)更新被等待的原子变量，最后调用notify_one() - 被等待的原子变量通常只作「信号量」用途（如
std::atomic<bool></bool>或std::atomic<int></int>），不承载复杂状态
例如实现一个单次通知的 ready 标志：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::atomic<bool> ready{false};
// 等待方
void waiter() {
while (!ready.load(std::memory_order_acquire)) {
ready.wait(false); // 等待从 false 变为 true
}
// 此时 ready == true，且之前 store 的副作用（如 data 初始化）已对本线程可见
}
// 通知方
void notifier() {
data = compute(); // 先准备数据
ready.store(true, std::memory_order_release); // 再更新标志
ready.notify_one(); // 最后通知
}
notify_one 和 notify_all 的选择陷阱
std::atomic::notify_one() 不保证唤醒「正在 wait 的线程」——它只唤醒「当前在 wait 调用中阻塞的线程」。如果 notify 发生时无人在 wait，该次通知就丢失了。
这意味着：
- 不能靠
notify_one()实现「至少一次唤醒」的可靠信号，除非你确保等待方一定先调用wait() -
notify_all()代价更高，但更接近condition_variable::notify_all()的语义，适合广播场景（如 shutdown 通知） - 若需「唤醒至多一个等待者」且允许丢失（如生产者-消费者中单个新元素），
notify_one()是合理选择；但务必搭配「自旋重检」逻辑
典型误用：
// ❌ 错误：notify_one 可能丢失，且没处理 spurious wakeup ready.notify_one(); // ……然后期望 waiter 一定醒来 —— 不成立
混合使用原子等待和 mutex 的边界在哪
当条件涉及多个变量或需要保护临界区时，std::atomic::wait 无法替代 std::mutex + std::condition_variable。例如：
- 等待「队列非空」必须读
queue.size()和访问queue.front()，这两个操作需原子性+排他性，仅靠一个原子变量无法表达 - 等待「资源可用且未过期」需同时检查
resource_ptr和expiry_time，无法压缩进单个原子整数 -
std::atomic::wait不提供超时（wait_for/wait_until），要超时就得退回到condition_variable
所以真实项目中，更常见的做法是：用原子等待优化「热路径上的简单信号」（如 barrier、latch、single-producer single-consumer 通知），其余场景仍用 std::mutex + std::condition_variable。
最容易被忽略的一点：std::atomic::wait 在 glibc 中依赖 futex，Windows 上依赖 WaitOnAddress，不是所有平台都支持；编译时需确认 __cpp_lib_atomic_wait 宏是否定义。
