100% CPU占用本身不是问题，关键在于是否由无效忙等待导致；应改用通知唤醒机制，如std::condition_variable（跨平台可靠）、std::atomic_wait（需满足lock-free等前提）或std::this_thread::yield()（仅短时让权）。
100% CPU 占用本身不是问题，问题在于它是否由无效忙等待（busy-wait）导致——比如 while (!flag.load()) 这类空转循环。真正要解决的，是把“无意义的轮询”换成“有通知才唤醒”的机制。
为什么 std::atomic_wait 不是万能的
std::atomic_wait 看似是 while 循环的完美替代，但它有硬性前提，不满足就直接失效或退化：
- 原子变量必须是整型且 lock-free：
flag.is_lock_free() == true，std::atomic<bool></bool>在多数平台满足，但std::atomic<:string></:string>完全不支持 - 调用前必须确认当前值等于你传入的
expected参数，否则函数立即返回，不会等 -
std::atomic_notify_one()或std::atomic_notify_all()必须显式调用；仅flag.store(true)不会触发唤醒 - macOS 当前（截至 macOS 14）完全不支持
std::atomic_wait，代码会编译通过但运行时静默失败
std::condition_variable 是更稳妥的跨平台选择
当你要等一个条件成立（如队列非空、标志置位），std::condition_variable + std::mutex 组合比 std::atomic_wait 更可靠，尤其在 macOS 或非 lock-free 场景下：
- 它不要求原子变量类型限制，任意布尔逻辑都能包装进
std::unique_lock保护的判断中 - 唤醒由
cv.notify_one()显式触发，语义清晰，无内存序隐含陷阱 - 底层基于 futex（Linux）或 Critical Section（Windows），延迟可控，不依赖内核版本新特性
- 注意：
wait()的谓词判断必须用 lambda 或函数对象，避免虚假唤醒，例如cv.wait(lock, [&]{ return ready; });
std::this_thread::yield() 适合短时让权场景
如果你只是想缓解几毫秒内的忙等待，又不想引入锁或条件变量的开销，std::this_thread::yield() 是轻量级折中方案：
立即学习“C++免费学习笔记（深入）”；
- 它不阻塞线程，只是向调度器“建议”切换，适合自旋锁内部或初始化阶段的短暂等待
- 不能替代真正的同步原语——它不提供内存序保证，也不保证唤醒时机，
yield()后仍需重新检查条件 - 在高负载系统上效果可能减弱，因为调度器可能没有其他可运行线程可选
- 示例：
while (!ready.load(std::memory_order_acquire)) { std::this_thread::yield(); }
最常被忽略的一点：即使用了 std::atomic_wait 或 condition_variable，如果 notify 发生在 store 之前，或者 wait 前没校验值，整个同步链就断了——CPU 占用率会瞬间回到 100%，而错误却难以复现。
