应使用带条件变量的阻塞队列+原子停止标志+shared_ptr数据传递：各阶段循环中wait新数据→处理→push下游并notify→检查stop标志；关闭时置标志并notify_all后join。
流水线阶段怎么用 std::thread 组织才不会卡死
直接用 std::thread 启动多个阶段，但没加同步机制，结果 stage2 一上来就去读 stage1 还没写完的缓冲区——程序要么崩溃，要么读到垃圾值。核心问题不是“能不能开线程”，而是“每个阶段何时能安全读/写共享数据”。
- 每个阶段封装为独立函数对象（或 lambda），接受输入队列、输出队列、停止标志三者引用
- 输入队列用
std::queue+std::mutex+std::condition_variable实现线程安全的阻塞队列 - 阶段内部循环中：先
wait等待新数据到达；收到后处理；再push到下游队列；最后检查stop_flag是否置位 - 别用
std::thread::join()在主线程里等所有阶段结束——某阶段卡住会导致整个程序挂起；改用std::thread::detach()+ 原子标志控制生命周期
如何避免 stage2 比 stage1 快导致空转或忙等
stage2 处理快，stage1 还没投喂新数据，它就在循环里反复 try_pop → 失败 → sleep(1ms) → 再试……CPU 占用飙到 100%。这不是“性能好”，是资源浪费。
- 必须用
std::condition_variable::wait()配合谓词等待，而不是轮询 - 每次向下游队列
push后，立刻调用cv.notify_one()（或notify_all()，但notify_one更轻量） - 停止时，除了置
stop_flag，还要对每个阶段的条件变量调用notify_all()，否则 stage2 可能永远卡在wait()里 - 输入队列的
pop()接口应返回std::optional<T>或带 success flag 的结构，避免用异常表示“无数据”
为什么 shared_ptr<T> 比 raw pointer 更适合跨阶段传递数据
stage1 new 出来一个大对象，传给 stage2 处理完再交给 stage3 —— 如果用裸指针，谁 delete？提前 delete 了 stage2 就访问非法内存；没人 delete 就内存泄漏。这是多阶段流水线最隐蔽的崩溃源。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 统一用
std::shared_ptr<Data>包裹业务数据，构造时 refcount=1，每 push 一次下游队列就 copy 一份 ptr，refcount 自增 - stage3 处理完，
shared_ptr离开作用域自动减 refcount；当 refcount 降为 0 时才真正 delete - 注意：不要把
shared_ptr存进队列后再在 stage1 里 reset 它——refcount 会立刻减到 0，stage2 拿到的就是空指针 - 若数据只读且体积小（如
int,std::string），可直接传值；但涉及图像帧、网络包等大对象，必须用shared_ptr或std::move转移所有权
main() 里怎么启动和安全关闭整个流水线
用户按 Ctrl+C，主线程想停掉所有阶段，但 stage2 正在 wait()，stage3 正在 memcpy 数据——强行 join() 会死锁，直接 exit() 会丢数据、不析构资源。
立即学习“C++免费学习笔记（深入）”；
- 定义全局原子标志
std::atomic_bool g_stop{false}，所有阶段轮询它 - 注册
std::signal(SIGINT, [](int){ g_stop = true; });，捕获 Ctrl+C - 主线程调用
g_stop = true后，对每个阶段的std::condition_variable调用notify_all() - 然后逐个
join()：此时每个阶段已在 wait 返回后检查g_stop并跳出循环，能正常退出 - 关键细节：所有队列的
push()和pop()必须在g_stop == false时才执行，否则可能往已销毁的队列里写
真正麻烦的不是写几个 thread，是让它们在任意时刻被中断时，都不留下未完成的中间状态、不泄露内存、不触发竞态——这些边界条件，比主干逻辑更耗调试时间。
