核心是避免线程间直接等待，用无锁队列做阶段间缓冲；每个阶段独立线程，只读上游队列、写下游队列，阻塞不扩散；推荐moodycamel::concurrentqueue或atomic环形缓冲；队列需容量上限并分离输入输出；阶段线程用try_dequeue()+yield()而非sleep；停止时先置原子标志、drain队列再join。
流水线结构怎么设计才不卡死
核心是避免线程间直接等待，用无锁队列做阶段间缓冲。每个阶段开独立线程，只从上游队列取数据、处理完塞进下游队列——这样任意阶段阻塞（比如 IO 或计算慢）都不会拖垮其他阶段。
别用 std::condition_variable 配 std::mutex 做“等有数据再取”，那会退化成串行。推荐 moodycamel::ConcurrentQueue（轻量、无锁、支持 move），或者自己用 std::atomic + 环形缓冲实现简易版。
- 每个阶段的输入队列和输出队列必须分离，不能共用一个
- 队列容量要有上限，否则内存爆掉；建议设为 1024 或按实际吞吐预估
- 阶段线程用
std::thread启动后，循环调用try_dequeue()，失败就std::this_thread::yield()，别用sleep_for(1ms)
如何让不同阶段共享上下文又不传参爆炸
传参太多说明阶段职责没切好。真正需要跨阶段传递的，只有原始输入、中间结果、错误状态这三类。用一个轻量级 struct PipelineContext 包裹，所有阶段都操作它，但每个阶段只读/写自己关心的字段。
例如：阶段一解析 JSON 到 context.raw_data，阶段二校验并写入 context.is_valid，阶段三序列化时只读 context.is_valid 和 context.raw_data。不要在阶段间传 std::shared_ptr<config></config> 或 std::function 这类重对象。
-
PipelineContext必须是move语义，禁止拷贝；构造函数初始化所有字段，避免未定义行为 - 如果某阶段需访问外部资源（如 DB 连接池），通过构造阶段对象时注入，而不是塞进
context - 阶段函数签名统一为
bool operator()(PipelineContext&&)，返回 false 表示该条数据应终止流水线
怎么安全地停止整条流水线
不能简单对每个 std::thread 调用 join() —— 如果某个阶段卡在队列等待，join() 会永久阻塞。必须配合中断信号 + 队列清空逻辑。
每个阶段线程循环里检查一个全局 std::atomic_bool stop_flag，同时在退出前把输入队列里剩余数据全 drain 掉（哪怕只做丢弃），否则上游还在 push 就停了，数据就丢了。
- 停止流程：先置
stop_flag = true→ 等所有线程完成本轮循环 → 对每个输入队列调用try_dequeue()直到空 → 最后join() - 别用
std::thread::detach()，detach 后无法控制生命周期，容易 core dump - 如果某阶段有阻塞系统调用（如
read()），需用pthread_cancel()或改用非阻塞 IO，C++ 标准线程没提供中断原语
为什么 stage 之间延迟飙升但 CPU 很低
典型症状：吞吐上不去，日志显示各阶段耗时正常，但 end-to-end 延迟翻倍。大概率是下游阶段消费太慢，导致上游队列积压，新数据在队列里排队——这不是代码问题，是背压没暴露出来。
加个简单的监控：每秒统计各队列 size()，超过阈值就打 warning 日志。更进一步，可以让上游阶段在队列 >80% 容量时主动 usleep(10)，给下游喘息时间（注意不是 sleep，避免唤醒延迟）。
- 别依赖队列的
size()精确值，moodycamel的 size 是近似值，仅用于趋势判断 - 生产环境必须设队列容量上限，否则内存泄漏比崩溃更难排查
- 如果发现某个阶段总是积压，优先看它是否做了同步 IO（如文件写、网络请求），应拆出子线程或换异步接口
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
