结论：应使用线程池而非为每个小任务新建std::thread。因std::thread构造/析构需系统调用、栈分配、TCB初始化等，开销达3–8μs，远超微秒级任务本身（如0.1μs计数循环），频繁创建销毁会浪费80%以上CPU时间。
std::thread。频繁创建/销毁线程的开销远超任务本身，尤其在毫秒级或微秒级小任务场景下，std::thread 构造和析构可能吃掉 80% 以上 CPU 时间。
为什么 std::thread 创建开销大
每次调用 std::thread 构造函数，底层会触发系统调用（如 Linux 的 clone()），分配栈空间（默认 1–8MB）、初始化 TCB（Thread Control Block）、注册信号处理、设置 TLS（Thread Local Storage）等。这些不是纯用户态操作，无法被编译器优化掉。
- 实测：在主流 x86_64 Linux 上，空
std::thread构造 +join()平均耗时约 3–8 μs；而一个简单计数循环（100 次加法）仅需 ~0.1 μs - 若任务平均执行时间
-
std::thread对象析构前未join()或detach()会直接调用std::terminate()—— 这是运行时崩溃，不是编译错误
std::async 不是万能解药
std::async 看似省事，但默认策略 std::launch::async | std::launch::deferred 是实现定义的。GCC libstdc++ 和 MSVC 默认倾向延迟执行（deferred），即不真正并发；而强制用 std::launch::async 仍会新建线程，没绕过创建开销。
- 它返回
std::future，但每次调用get()会阻塞，不适合高吞吐流水线 - 没有任务队列、无复用机制、无法控制并发数，大量调用会快速耗尽系统线程资源（Linux 默认 per-process 线程数上限常为 1024）
- 异常传播路径长，调试时堆栈难追踪
线程池必须自己管好三件事
一个轻量可用的线程池核心就三块：线程安全的任务队列、固定数量的 worker 线程、带唤醒语义的等待逻辑。别依赖第三方模板库——多数“通用”实现过度设计，反而引入额外原子操作或虚函数调用。
- 任务队列用
std::queue+std::mutex+std::condition_variable就够，避免std::deque的内存碎片问题 - worker 线程数建议设为
std::thread::hardware_concurrency()，超线程开启时可略增 1–2，但别盲目设成 100+ - 用
wait_for()而非wait()防止单个长期空闲线程卡死，便于 graceful shutdown - 任务包装推荐
std::packaged_task<void></void>，比裸std::function少一次动态分配，且自带std::future结果通道
最容易被忽略的陷阱：虚假共享与缓存行对齐
多个 worker 线程频繁访问相邻内存（比如任务队列的 size、head、tail 计数器挤在同一个 64 字节 cache line），会导致 CPU 核心间反复无效化缓存行（cache line bouncing），性能暴跌。
立即学习“C++免费学习笔记（深入）”；
- 把互斥锁对象、队列长度、唤醒标志等关键字段用
alignas(64)隔开 - 避免在任务 lambda 中捕获大对象，优先 move 捕获；否则每个任务对象体积膨胀，加剧队列内存压力
- 不要在 worker 线程里做 printf / iostream 输出 ——
std::cout全局锁会让所有线程串行化，瞬间退化成单线程
