流水线结构用std::thread拆解阶段的核心是每个阶段封装为独立线程，通过std::queue+std::mutex+std::condition_variable构成单向通道串连，循环等待、处理、推送，并需统一stop_flag和error_code控制启停与异常传播。
流水线结构怎么用 std::thread 拆解阶段
核心是把每个阶段封装成独立的 std::thread，但不能让线程各自为政——必须串起来。最简方式是用一对 std::queue + std::mutex + std::condition_variable 构成单向通道（stage A → stage B）。每个阶段线程循环等待新数据、处理、推给下一阶段。
常见错误是直接用 std::queue 而不加锁，导致段错误或数据丢失；更隐蔽的是忘记在 wait() 前检查队列是否为空，造成死等。
- 每个阶段启动一个
std::thread，传入该阶段的处理函数和输入/输出队列指针 - 输入队列为空时，用
cv.wait(lock, [&]{ return !q.empty() || done_flag; });避免虚假唤醒 - 输出前需对下游队列加锁，
push()后立刻notify_one() - 不要在线程里直接
delete输入对象——建议用std::unique_ptr管理生命周期，移交时用std::move()
std::shared_ptr 和移动语义怎么选
流水线里数据在阶段间传递，拷贝开销大，但裸指针又难管理。优先用 std::shared_ptr，除非你确定某阶段是数据唯一所有者且后续不再访问——这时用 std::unique_ptr + std::move() 更高效。
容易踩的坑：混用两种智能指针，比如上游用 std::shared_ptr 推入，下游误用 std::move() 导致引用计数归零提前析构；或者多个阶段同时持有 std::shared_ptr 却没考虑线程安全——shared_ptr 的控制块原子操作只保证计数本身线程安全，指向的对象仍需额外同步。
立即学习“C++免费学习笔记（深入）”；
- 若阶段间只读传递（如日志解析后只读转发），
std::shared_ptr安全且简洁 - 若某阶段彻底消费数据（如序列化后写磁盘，后续无需再读），用
std::unique_ptr显式移交所有权 - 避免在
std::shared_ptr指向的对象内部做非原子修改——加锁或改用std::atomic成员
如何控制流水线启停与异常传播
不能靠 join() 等所有线程自然结束——某个阶段崩溃，其他线程可能卡在 wait() 上。必须引入统一的终止信号和错误通道。
典型错误是只设一个 done_flag，但没处理“某阶段已出错，其他阶段该继续跑还是立即停”。结果是错误被掩盖，或线程僵死。
- 每个阶段线程持有一个
std::atomic<bool></bool>stop_requested和一个std::atomic<int></int>error_code（0 表示正常） - 主控线程调用
stop_all()时，先置stop_requested = true，再notify_all()所有条件变量 - 每个阶段在循环开头检查
error_code.load() != 0，一旦发现非零值，跳过处理直接退出 - 异常发生时，捕获后设
error_code = 1（或具体码），并notify_all()让其他阶段快速响应
为什么不用 std::async 或线程池
std::async 默认是延迟启动或自动调度，无法精确控制阶段执行顺序和线程绑定；线程池则共享一组线程，阶段间依赖关系会变成任务排队竞争，破坏流水线的时序性和吞吐稳定性。
实测中，用固定线程数的流水线比线程池快 15–30%，尤其当阶段耗时不均（如解码慢、校验快）时，专用线程能持续喂数据，而线程池容易因任务分发不均导致瓶颈阶段饥饿。
-
std::async适合单次异步计算，不适合长期运行、状态耦合的流水线 - 线程池适合无依赖的批处理（如图像批量压缩），不适合 A→B→C 强依赖链
- 真要复用线程资源，可在每个阶段内用小范围线程池处理子任务（如 B 阶段内部并行校验多个字段），但阶段间仍保持一对一映射
