应避免用 std::queue + mutex 实现异步任务队列，因其锁竞争导致吞吐量骤降3–5倍、阻塞回调会卡死全局消费，且无法满足生产者不等、消费者不抢等核心需求；推荐使用 boost::lockfree::queue 并严格遵循容量设置、返回值检查、正确判空与混合等待策略等规范。
为什么不用 std::queue + mutex 做异步任务队列
因为锁竞争会直接卡死吞吐量——尤其在大量短任务、多线程频繁 push/pop 的场景下，std::mutex 会导致线程反复陷入休眠/唤醒，CPU 缓存行频繁失效，实测吞吐可能比无锁方案低 3–5 倍。
更麻烦的是，一旦任务回调里意外调用了阻塞操作（比如日志写磁盘、网络等待），整个队列的消费者线程就挂住了，其他任务全被堵住。这不是并发，是串行排队加锁。
- 别用
std::queue配std::mutex实现“简单版”任务队列，它不解决根本问题 - 真正需要的是：生产者不等、消费者不抢、失败可重试、内存安全可控
-
boost::lockfree::queue是最稳妥的起点，比手写atomic+ CAS 更可靠，也比moodycamel::ConcurrentQueue对 C++11 兼容性更好
如何用 boost::lockfree::queue 构建任务容器
它底层用的是 Michael-Scott 算法，支持无锁 push 和 pop，但必须注意：默认构造是**有界队列**，且容量必须是 2 的幂次——填错会静默截断或构造失败，不报错也不警告。
常见错误现象：queue.push(task) 返回 false 却没检查，任务直接丢弃；或者用 queue.size() 判断是否为空，结果在多线程下返回过期值（它不是原子快照）。
立即学习“C++免费学习笔记（深入）”；
- 初始化时显式指定容量：
boost::lockfree::queue<:function>> task_queue{1024}</:function> - 永远检查
push()返回值：if (!task_queue.push(task)) { /* 备用处理，如丢弃或 fallback 到本地执行 */ } - 判空用
empty()，别用size() == 0；遍历消费必须用循环while (task_queue.pop(task)) { ... }，不能先size()再 for 循环 - 存储类型推荐
std::function<void></void>，避免裸函数指针生命周期失控；若追求极致性能，可用std::unique_ptr<taskbase></taskbase>+ 虚函数，但得自己管内存
消费者线程怎么避免忙等又不漏任务
纯 while(true) + pop() 是 CPU 空转；加 std::this_thread::yield() 又可能让出太多，延迟飙升；用 std::this_thread::sleep_for(1ns) 更糟——系统调用开销远大于任务本身。
正确做法是混合策略：先自旋几轮（比如 64 次），没取到就 yield 一次；再连续 16 次没取到，就 sleep_for(1μs)；仍无任务，才考虑短暂休眠或触发监控告警。
- 别依赖操作系统调度来“省电”，异步任务系统本质是延迟敏感型，响应时间比功耗重要得多
- 每个消费者线程应绑定独立 CPU 核心（
pthread_setaffinity_np或std::thread::hardware_concurrency()配合set_affinity），避免跨核缓存同步损耗 - 如果任务量极低（比如每秒不到 10 个），不如直接关掉该消费者线程，由主线程定时唤醒检查——省资源比“一直在线”更合理
任务执行异常时，谁负责捕获和记录
无锁队列只管传递，不管执行。如果任务内部抛异常且没捕获，std::terminate 直接干掉整个进程——连栈都没法打印。
所以所有入队的 std::function<void></void> 必须包裹一层 try-catch，且 catch 后不能吞掉错误：至少记录到线程局部日志缓冲区（避免锁日志器），严重错误触发熔断信号（如原子计数超阈值则暂停入队）。
- 不要在消费者线程里全局
set_terminate，它无法区分是任务异常还是系统级崩溃 - 日志写入推荐用 lockfree ringbuffer（如
spdlog::details::ringbuffer），别碰std::cout或文件流 - 异常任务的上下文（如 task id、入队时间戳、线程 ID）必须在捕获时立刻提取，别等日志线程去查——那时栈已销毁，变量早 gone
无锁不是银弹。真正的难点不在队列本身，而在任务生命周期管理、错误传播边界、以及 CPU 缓存一致性对性能的隐性惩罚——这些地方一松懈，吞吐量就掉回带锁水平。
