不能直接用 std::queue 存裸指针任务，因作用域提前销毁会导致悬垂指针、segmentation fault 或引用捕获失效；应改用 std::shared_ptr 并配合无锁队列与空值检查。
为什么不能直接用 std::queue<:function>></:function> 存裸指针任务
裸指针（比如 new std::function<void>{...}</void>）放进队列后，若线程池未及时消费，而原始作用域提前销毁，指针就成悬垂状态。运行时调用会触发 segmentation fault 或未定义行为。更危险的是：即使没崩溃，std::function 内部捕获的 lambda 变量（尤其是按引用捕获）也会失效。
实操建议：
- 一律用
std::shared_ptr<:function>></:function>替代裸指针，让生命周期由引用计数管理 - 若任务需持有外部对象，优先用值捕获（
[obj = std::move(obj)]() mutable { ... }），避免引用捕获 + 指针混用 - 不要把
std::unique_ptr<:function>></:function>塞进共享队列——它不可拷贝，多线程取任务时会编译失败
std::queue 在多线程下必须加锁，但别用 std::mutex 粗暴包整个 push/pop
常见错误是写一个全局 std::mutex，每次 push() 和 pop() 都 lock()/unlock()。这会让所有线程在队列操作上串行排队，吞吐量骤降，尤其在高并发短任务场景下，锁争用成为瓶颈。
实操建议：
- 用
std::queue+std::mutex是可行的，但只锁最小临界区：仅包裹push()的入队动作、front()/pop()两步组合（注意：不能分开锁） - 更推荐改用无锁队列，如
moodycamel::ConcurrentQueue（轻量、免锁、支持 move-only 类型），它对std::shared_ptr<:function>></:function>友好 - 若坚持手写，至少把
empty()判断和pop()合并为原子操作（例如封装成try_pop(task)），防止检查后队列被其他线程清空
线程池中任务执行前要检查 shared_ptr 是否为空
即便用了 shared_ptr，仍可能遇到空指针：比如线程池正 shutdown，消费者线程已退出，但生产者线程还在往队列塞任务，此时某些 shared_ptr 可能已被 reset，或构造失败返回空值。
实操建议：
- 每个工作线程循环中，从队列取出
shared_ptr<:function>></:function>后，**必须先判空再调用**：if (task) (*task)(); - 不要依赖
queue.empty()结果做分支逻辑——它只是快照，不保证后续pop()一定成功 - shutdown 流程中，建议向队列 push 若干空
shared_ptr作为“哨兵”，让每个 worker 主动退出，比轮询running_flag更可靠
别在任务里 delete this 或手动管理线程池对象生命周期
有用户尝试在线程池析构时，让所有 worker 线程调用 delete this 来释放自身栈内存，这是严重错误。C++ 中线程函数栈帧由系统管理，this 指向的是线程池对象（堆上），不是线程栈；且多个线程并发 delete 同一对象会 double-free。
实操建议：
- 线程池对象本身应由智能指针（
std::shared_ptr<threadpool></threadpool>）或自动存储期管理，worker 线程只需 join 或 detach 后自然结束 - worker 线程函数体应是普通函数或 static 成员，不持有
this指针——除非你明确做了线程局部存储隔离 - 真正需要关注的是任务对象的析构时机：确保所有
shared_ptr<:function>></:function>被消费完毕后再销毁线程池，否则残留任务会在析构后被调用
最易忽略的一点：任务队列类型和线程池 shutdown 顺序必须严格匹配。比如用 moodycamel::ConcurrentQueue 时，若先析构队列再等待线程，worker 可能仍在尝试 pop 已销毁对象；反过来，若先 join 线程再清空队列，又可能漏掉最后几个任务。实际代码里得靠 RAII 封装，把队列、线程、shutdown 信号绑在一起。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
