std::thread直接new不叫线程池，因缺乏复用、任务队列和统一生命周期管理；真线程池需固定工作线程+阻塞队列+安全执行循环，并须用mutex+condition_variable保护共享队列。
为什么 std::thread 直接 new 一堆线程不叫线程池
因为线程创建/销毁开销大，且无法复用、缺乏任务队列和统一生命周期管理。真正的线程池得有：固定数量的工作线程 + 阻塞任务队列 + 安全的取任务/执行循环。
常见错误现象：std::thread 对象未 join() 或 detach() 导致程序崩溃；任务提交后无等待机制，主线程提前退出；多个线程同时 pop 同一个 std::queue 没加锁，触发数据竞争。
- 必须用
std::mutex+std::condition_variable保护共享队列 - 工作线程循环里不能裸调
queue.pop()，得用wait()等待非空状态 - 避免在构造函数里直接启动线程——成员变量初始化顺序可能导致
mutex尚未就绪
std::packaged_task 是怎么把任意 callable 转成可入队任务的
它把函数对象（lambda、函数指针、绑定表达式等）和它的返回值包装进一个可移动、不可复制的对象，并自带 std::future 接口。这是实现泛型任务调度的关键一环。
使用场景：你需要让线程池支持 int f();、void g(std::string)、甚至带捕获的 lambda，且能获取返回值或异常。
立即学习“C++免费学习笔记（深入）”；
- 声明队列类型应为
std::queue<:packaged_task>></:packaged_task>（统一转成无参无返回，靠 capture 携带参数） - 别用
std::function<void></void>替代——它会额外拷贝、且不提供get_future() - 提交任务时用
std::move(task)入队，否则编译失败（std::packaged_task不可复制）
线程池 shutdown 的正确顺序为什么不能颠倒
先停任务接收、再通知工作线程退出、最后 join() —— 顺序错一点就会死锁或丢任务。
典型错误：调用 join() 前没设停止标志，工作线程还在等新任务，永远卡在 cv.wait()；或者先析构了 std::mutex，但还有线程试图 lock。
- 加一个原子布尔
std::atomic<bool> stop_requested{false}</bool>控制循环退出 - shutdown 函数里先置
stop_requested = true，再cv.notify_all() - 每个工作线程循环条件应是
!stop_requested || !tasks.empty()，确保清空剩余任务 - 所有
join()必须在 mutex 和 cv 生命周期结束前完成
为什么生产环境慎用 std::hardware_concurrency() 当线程数
它返回的是逻辑核心数，不是最佳并发数。I/O 密集型任务可能需要更多线程；CPU 密集型反而可能因上下文切换拖慢整体性能。
性能影响：在 8 核机器上硬开 32 个线程跑纯计算任务，L3 缓存争用加剧，实测吞吐可能下降 20%+；而处理大量 socket 回调时，16 个线程可能比 8 个响应更快。
- 默认值建议设为
std::thread::hardware_concurrency() * 1.5（仅作起点） - 留出配置项，比如构造时接受
size_t pool_size = 0，0 表示自动推导 - 注意 macOS 上
hardware_concurrency()可能返回 0，需 fallback 到 4
最麻烦的其实是异常传播——任务里抛的异常若没在 std::packaged_task 内 catch，会直接 terminate。这点很容易被忽略，又没法在主线程外全局捕获。
