gdb中通过thread apply all bt查看卡在pthread_cond_wait或std::condition_variable::wait的线程，若唤醒线程未运行或未调用notify，则存在唤醒缺失；需确保wait配对unique_lock和谓词、notify不早于wait、避免析构时notify、一条件一condition_variable。
死锁时 gdb 里怎么看线程卡在哪
直接 gdb attach <pid></pid>，然后 thread apply all bt —— 重点看哪些线程停在 pthread_cond_wait 或 std::condition_variable::wait 的栈帧里。如果多个线程都卡在 wait，而唤醒线程（调用 notify_one/notify_all 的那个）没在运行、或根本没走到 notify，基本就是唤醒缺失或顺序错乱。
wait 调用必须配对 std::unique_lock 和 predicate
常见错误是只传了 lock，没传 predicate，导致虚假唤醒后直接往下走，逻辑出错；或者用了 wait(lock) 却在 while 循环外判断条件，漏掉唤醒后条件仍不满足的情况。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 正确写法一定是：
while (!condition_met) cv.wait(lock);或cv.wait(lock, []{ return condition_met; }); -
lock必须是std::unique_lock<:mutex></:mutex>，不能是std::lock_guard（后者不可转移，wait内部要临时释放并重获） - 如果用
wait_for或wait_until，记得检查返回值：cv_status::timeout不代表条件不成立，只是超时了，还得再查一次条件
notify 被调用时，等待线程可能还没开始 wait
notify 是“发信号”，不是“保证唤醒”：如果 notify 先于 wait 执行，信号就丢了，后续 wait 会一直阻塞。没有类似 semaphore 的计数机制。
- 典型场景：生产者先 notify，消费者还没 construct 出 thread 或还没 lock mutex 就调用 wait
- 解决方法：初始化阶段确保等待逻辑已就位，或用 flag + double-check，例如：
ready = true; cv.notify_all();配合while (!ready) cv.wait(lock); - 避免在析构函数里 notify —— 等待线程可能已退出，或 mutex 已销毁，导致未定义行为
多个 condition_variable 共享同一 mutex 容易误唤醒或漏唤醒
一个 mutex 配多个 cv 是允许的，但每个 cv 对应的等待条件必须互斥且独立。否则 A 条件满足时 notify_all，会把等 B 条件的线程也拉起来，它们发现条件不满足又回去 wait —— 白耗 CPU，还可能掩盖真正的唤醒丢失。
- 更安全的做法：一个条件一个
std::condition_variable，哪怕共用同一个 mutex - 如果真要复用，务必确认所有 wait 的 predicate 都覆盖各自关心的状态，且 notify 逻辑能精准区分场景
- 调试时可加日志：
LOG 和 <code>LOG ，比 gdb 更快定位错位
shared_ptr 判断非空，但对象内部字段又被其他线程改，那 predicate 就成了假阳性或假阴性。得靠 mutex 保护整个条件判断过程，不能只锁一部分。
