必须用std::condition_variable配合std::mutex和带谓词的wait()实现阻塞等待，通知前须在同锁下修改共享状态并notify，谓词检查防虚假唤醒和唤醒丢失。
std::condition_variable 怎么用才不卡死
线程间存在逻辑依赖时，比如“线程B必须等线程A完成初始化后才能开始处理”，靠轮询或 sleep 等待既耗资源又不可靠。正确做法是用 std::condition_variable 配合 std::mutex 实现阻塞式等待。
关键点在于：条件变量本身不保存状态，它只负责挂起/唤醒；真实的状态（如 ready）必须由共享变量承载，并用互斥锁保护读写。
- 必须在
wait()前加锁，且锁对象要和状态变量的保护锁是同一个 -
wait()会自动释放锁并挂起，被唤醒后重新加锁再返回——所以不能在wait()外部假设锁还持有 - 通知方调用
notify_one()或notify_all()前，必须先修改状态变量，并确保该修改对等待线程可见（即在同一个锁保护下完成） - 永远用带谓词的
wait(lock, []{ return condition; })形式，避免虚假唤醒（spurious wakeup）
错误示例：cv.wait(lock); if (!ready) return; —— 这里没检查条件就继续执行，可能直接跳过逻辑依赖。
多个依赖关系怎么串起来不乱套
一个线程依赖多个前置条件（比如“数据就绪”且“配置加载完成”且“网络连接建立”），不能简单叠加多个 wait() 调用，否则容易陷入死锁或顺序错乱。
推荐做法是把所有依赖收敛到一个统一的状态机或标志组合，用单个条件变量驱动：
- 用整型或位掩码表示各子状态，例如
int deps = 0;，每满足一项就用原子操作设置对应 bit - 等待线程检查是否所有 bit 都置位，例如
cv.wait(lock, [&]{ return (deps & ALL_READY) == ALL_READY; }); - 通知方每次更新状态后都调用
cv.notify_all()（不是notify_one()），因为多个等待者可能关心不同子集
注意：不要用多个 std::condition_variable 分别对应不同条件再嵌套等待——这极易导致唤醒丢失或锁序混乱。
std::thread::join() 和条件变量有什么区别
join() 是线程生命周期管理机制，只解决“等一个线程彻底结束”这一种硬依赖；而条件变量解决的是“等某个业务状态成立”的软依赖。
常见误用场景：
- 想等“另一个线程把数据写进缓冲区”，却对那个线程调用
join()—— 这会让当前线程完全阻塞到对方函数返回，但对方可能早就在某处return了，只是数据还没刷到共享内存 - 用
detach()后还想靠join()等待 —— 编译直接报错，std::thread对象一旦detach()就无法再同步
真正需要逻辑依赖时，join() 基本派不上用场；它只适合“主线程必须等所有工作线程收尾再退出”这种收尾场景。
为什么 notify 之后线程还不醒
最常见原因是：通知发生在等待之前，即“唤醒丢失（lost wakeup）”。std::condition_variable 不保证唤醒事件可积累，它只唤醒当前正在 wait() 的线程。
典型错误流程：
- 线程A检查
ready == false→ 进入wait() - 线程B设置
ready = true并调用notify_one() - 但此时线程A还没真正进入等待态（还在加锁、构造
unique_lock等），通知就被丢弃 - 线程A随后进入
wait()，永远卡住
唯一可靠解法：所有状态变更和通知，必须在同一个互斥锁保护下完成，并且等待方必须在锁内检查条件。这就是为什么标准写法强制要求 wait() 带谓词——它会在每次被唤醒后重新检查条件，把“通知早于等待”的情况兜住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
