std::thread 直接创建线程不适合高频任务，因其每次构造均触发系统调用、栈分配与调度入队，开销达微秒级，高频提交将耗尽CPU与系统资源；线程池通过复用固定线程消费任务队列规避该成本。
为什么 std::thread 直接创建线程不适合高频任务
每次 std::thread 构造都触发系统调用、分配栈内存、调度入队，开销在微秒级——但若每毫秒提交 100 个短任务，光是线程启停就吃掉大量 CPU 时间，还容易触发 OS 线程数限制或内存耗尽。线程池的核心价值不是“并发”，而是“复用”：让固定数量的线程持续消费任务队列，避开重复初始化成本。
常见错误现象：std::system_error: Resource temporarily unavailable（Linux 下 pthread_create 失败）、程序启动后卡顿、top 显示大量 defunct 进程（僵尸线程未 join()）。
- 别在循环里无节制
std::thread{func, args...}.detach()—— detach 后无法控制生命周期，易导致访问已析构对象 - 避免每个任务都 new 一个
std::thread对象 —— 堆分配 + 虚函数表查找增加延迟 - 线程数不建议超过
std::thread::hardware_concurrency()的 2 倍 —— 超量争抢 CPU 反而降低吞吐
用 std::queue + std::mutex + std::condition_variable 实现基础任务队列
标准库没有现成的线程安全队列，必须自己加锁保护。重点不是“能不能塞进去”，而是“唤醒时机是否精确”——过早 notify 会导致消费者线程虚假唤醒，过晚则任务积压。
关键设计点：
立即学习“C++免费学习笔记（深入）”；
- 任务类型用
std::function，支持 lambda、成员函数、绑定对象，但注意捕获引用可能悬空 - 使用
std::queue而非std::deque—— 前者 push/pop 平均 O(1)，且无需随机访问；后者虽支持 front/pop_front，但内部结构更复杂，缓存局部性略差 -
std::condition_variable::wait必须配合 while 循环检查条件，不能只用 if —— spurious wakeup 是 POSIX 标准允许的行为 - 停止信号用
std::atomic，而非全局变量或 mutex 保护的 bool —— 避免 stop_flag 读写成为性能瓶颈
std::queue<std::function> tasks_;
mutable std::mutex mtx_;
std::condition_variable cv_;
std::atomic stop_{false};
如何安全终止线程池并等待所有任务完成
粗暴调用 std::thread::join() 前必须确保线程已退出循环，否则主线程永久阻塞。而直接 std::thread::detach() 会丢失对工作线程的控制权，导致程序退出时仍在后台运行的线程访问已释放内存。
