notify_one调用后线程未唤醒的四大主因：一是wait未执行或已提前返回；二是wait与notify不在同一condition_variable实例；三是共享状态修改未加锁导致竞态；四是未用while循环检查谓词致虚假唤醒误判。
notify_one 调用后线程没醒，先确认 wait 是否在 notify 之前已返回
这是最常见原因：notify_one 发出时，目标线程根本不在 wait 中——它可能还没调用 wait，或者已经因虚假唤醒/超时提前退出了。C++ 的 condition_variable::wait 不保证“通知必达”，只保证“被阻塞时能被唤醒”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在
wait前加日志或断点，确认线程确实执行到了cv.wait(lock, pred)这一行； - 检查谓词
pred是否一开始就是true，导致wait直接返回不阻塞（比如共享变量初始值就满足条件）； - 不要依赖“先启动等待线程、再发通知”的时序，必须用互斥锁 + 谓词做状态保护，例如：
std::unique_lock<:mutex> lock(mtx); while (!ready) cv.wait(lock);</:mutex>
wait 和 notify 不在同一个 condition_variable 实例上
看似调用了 notify_one，但实际唤醒的是另一个 std::condition_variable 对象——比如局部变量、临时对象、或不同类成员实例。对象地址不一致，通知就完全无效。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在
wait和notify_one处分别打印&cv地址，确认是同一对象； - 避免在函数内定义
condition_variable并传给其他线程使用（生命周期易出错）； - 若用类封装，确保
cv是成员变量且被所有相关线程共享（非拷贝、非临时）；
notify_one 被调用时锁未正确持有或已释放
notify_one 本身不要求持锁，但**修改被等待的共享状态（如 ready = true）必须在锁保护下完成**，否则可能触发数据竞争，导致等待线程看到过期值而永远不醒。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 把状态修改和
notify_one都放在同一把std::unique_lock作用域内（不是必须，但最安全）； - 不要这样写：
lock.unlock(); ready = true; cv.notify_one();——ready写入和notify之间存在竞态窗口； - 更推荐：
lock.lock(); ready = true; lock.unlock(); cv.notify_one();或直接{ std::unique_lock lk(mtx); ready = true; } cv.notify_one();
调试时漏掉了虚假唤醒或 wait 提前返回
wait 可能无通知就返回（spurious wakeup），如果没配合谓词循环检查，线程会误以为条件已满足而继续执行，后续再等就卡死。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永远用
while (!pred()) cv.wait(lock);，别用if或裸wait()； - 谓词必须读取受同一互斥锁保护的变量，不能读取局部副本或未同步的缓存；
- 加日志：在
wait返回后立刻打印ready值，看是不是false却退出了（说明是虚假唤醒）；
真正难排查的，往往是状态修改和通知之间的微小竞态，或者多个 condition_variable 实例混用。盯住变量地址、锁范围、谓词逻辑这三点，比加一堆 std::this_thread::yield() 有用得多。
