死循环和死锁本质不同：死锁是线程因互斥锁顺序不一致而永久阻塞在lock处，忙等则是无退出条件的无效轮询；应使用std::lock或固定地址顺序加锁避免死锁，用condition_variable替代忙等，并确保notify在正确锁保护下发出。
死循环和死锁是两回事。C++多线程里没有“处理死循环”这个通用需求——你真正要解决的，通常是**死锁导致的线程卡死假象**，或者**本意是等待但没设退出条件的忙等（busy-wait）**。
std::mutex 加锁顺序不一致导致的“卡死”
这不是死循环，是死锁：两个线程各持一把锁，又互相等对方释放，CPU 不空转但线程永远停在 std::lock_guard 构造处。现象是程序无响应、日志断在某一行、gdb 显示线程停在 __lll_lock_wait 或类似系统调用里。
- 别用
std::lock_guard分步加多把锁，比如先锁mtx1再锁mtx2 - 改用
std::lock(mtx1, mtx2)一次性原子获取所有锁，失败时自动回退，不会留下半锁状态 - 若必须分步，所有线程严格按同一地址顺序加锁：比如总是先锁地址小的互斥量，可用
std::less<:mutex>()(&mtx1, &mtx2)</:mutex>判断
while(true) { /* 无条件等待 */ } 这类忙等
看起来像死循环，实际是浪费 CPU、阻塞调度、还可能掩盖真实同步问题。常见于轮询某个标志位却忘了加锁或用 std::condition_variable。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 把
while(flag == false) { std::this_thread::yield(); }换成std::unique_lock+cv.wait(lock, [&]{ return flag; }); - 如果真需要超时轮询，用
cv.wait_for(lock, 100ms, [&]{ return flag; })，避免无限等待 -
std::this_thread::yield()效果极弱，现代调度器下几乎无效；std::this_thread::sleep_for(1ms)开销大，仅作兜底
std::condition_variable notify_one/notify_all 漏发或错发
等待线程永远收不到唤醒，表现就是“卡住”，容易被误认为死循环。根本原因是通知逻辑没覆盖所有路径，或在错误的锁保护下发送。
立即学习“C++免费学习笔记（深入）”；
-
notify_one()只唤醒一个等待者，确保有且仅有一个线程在等，否则可能漏唤醒 - 通知必须在持有同一把
std::mutex的前提下发出，否则唤醒可能丢失 - 用
notify_all()更安全，但要注意虚假唤醒，务必配合谓词判断（即wait(lock, predicate)形式）
真正难调试的不是代码写错了循环，而是同步原语用得似是而非：锁没配对、条件变量没守卫、notify 被优化掉、或者用了 volatile 当同步手段。这些地方一松懈，线程就停在那儿，既不崩溃也不报错，只安静地等一个永远不会来的信号。
