线程池并非万能加速器，仅在任务粒度大、cpu密集且可并行拆分时有效；适用于高频短计算、超10⁵元素处理、并发数受限及无强依赖场景。
线程池不是万能加速器，小规模数据用它反而更慢；真正起效的前提是任务粒度够大、CPU密集、且能并行拆分。
什么时候该用线程池而不是裸 std::thread
直接 new 一堆 std::thread 容易踩三个坑：线程创建销毁开销大、缺乏统一生命周期管理、任务调度完全手动。线程池适合以下场景：
- 反复提交大量短时计算任务（比如每秒数百次向量加法）
- 单次处理超 10⁵ 级别元素的 CPU 密集型操作（排序、矩阵乘、图像像素变换）
- 需要限制并发数避免压垮系统（例如设定最多 8 个线程，匹配物理核心数）
- 任务间无强依赖，能安全共享只读数据或各自写独立内存区域
ThreadPool::enqueue() 提交任务的正确姿势
很多初学者把耗时函数直接传进去，结果发现没提速甚至变慢——问题常出在参数绑定和返回值处理上。
- 避免捕获大型对象到 lambda 中：
[data]会复制整个容器；改用[&data]或传指针/引用，但必须确保data生命周期覆盖任务执行期 - 不要在
enqueue()后立刻get()等待结果：这退化成串行；应批量提交再统一wait或用std::future::wait_for做超时控制 - 若任务需返回值，
enqueue()返回std::future；但频繁调用get()会阻塞，建议攒够一批再取 - 典型错误：对同一块内存不同段做并行写入却没对齐缓存行——引发伪共享；用
alignas(64)对齐输出缓冲区可缓解
数据划分不均导致加速比崩塌的现实问题
加速比达不到理论值（比如 8 核只跑出 3x），八成是因为任务分配静态且不均衡。例如：
size_t chunk_size = data.size() / pool_size; for (size_t i = 0; i <p>这段代码在 <code>data.size()</code> 不能被 <code>pool_size</code> 整除时，最后一块远大于其他块；更糟的是，如果数据本身访问模式不均（如稀疏矩阵中某些行非零元极多），静态切分会让某个线程卡死。</p>
- 对策一：改用动态任务队列，每个线程从共享队列取下一个未处理块（需加锁或无锁队列）
- 对策二：预估每块计算量，按权重而非长度划分（例如按每千元素平均耗时 × 元素数）
- 对策三：直接用
std::for_each+ 执行策略（C++17 起）：std::for_each(std::execution::par_unseq, begin, end, f)，底层自动负载均衡，但要求函数无副作用
线程池 shutdown 时机与资源泄漏风险
构造时启动线程，析构时必须确保所有任务完成且线程退出，否则 std::thread 析构会调用 std::terminate()。
- 别在主线程 exit 前忘记
pool.stop()或等所有std::future完成 - 若任务中抛异常未捕获，
std::packaged_task会把异常存进std::future，但不显式get()就看不到——建议在enqueue外包一层 try/catch 并记录日志 - 注意
std::condition_variable::wait的虚假唤醒：源码里那个[this]{return this->stop || !this->tasks.empty();}判断必不可少，漏掉会导致线程永久挂起
真正难的从来不是让代码跑在线程上，而是确认哪一段值得并行、怎么切不伤性能、以及如何让所有线程在该停的时候干净停下——这些细节不处理，线程池只会变成一个更难调试的定时炸弹。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
