线程池的核心是线程复用，而非每次任务新建线程；需固定工作线程、共享安全任务队列、条件变量休眠唤醒机制及原子停止标志，std::jthread仅简化析构与中断，不替代池逻辑。
为什么 std::thread 直接 new 一堆线程不是线程池
线程池的核心是复用，不是“一次一建”。直接用 std::thread 启动 N 个任务，等于每次新建+销毁线程，开销大、调度不可控、还容易触发系统线程数上限（Linux 默认一般 1024）。真正的线程池得有固定数量的工作线程、共享的任务队列、以及安全的取-执行循环。
- 典型错误现象：
std::system_error: Resource temporarily unavailable—— 线程创建失败，大概率是pthread_create被系统拒绝，不是代码写错了，是线程炸了 - 关键区别：线程池里每个
std::thread对象生命周期贯穿整个程序运行期（或池生命周期），只启动一次；任务通过std::function<void></void>投递进队列，由空闲线程取走执行 - 别用
std::async(std::launch::async)模拟池——它不保证复用，底层可能每次都起新线程，行为不可控
怎么用 std::queue + std::mutex + std::condition_variable 安全地存任务
任务队列必须线程安全，但不能只靠 std::mutex 锁住整个 push/pop——那样会严重串行化投递和执行。要用条件变量让工作线程在队列空时休眠，避免忙等。
- 常见坑：把
std::condition_variable::wait放在while (!queue.empty())外面，导致虚假唤醒后直接pop崩溃；必须用while (queue.empty()) cv.wait(lock) - 别用
std::stack或std::deque替代std::queue——虽然底层容器可换，但语义上std::queue更清晰，且默认用std::deque已足够高效 - 任务类型建议用
std::function<void></void>，别裸传std::packaged_task或 lambda 捕获大对象——容易隐式拷贝引发内存问题；如果需要返回值，用std::packaged_task<void></void>包一层再转成std::function<void></void>
工作线程怎么正确退出（避免死锁和资源泄漏）
线程池析构时，必须让所有工作线程安全退出，否则 std::thread 对象被销毁而线程还在跑，会调用 std::terminate。不能靠“等几秒”或“joinable 就 join”，得有明确的停止信号。
- 必须设一个原子标志位：
std::atomic<bool> stop_requested{false}</bool>，所有工作线程循环中检查它，且在检查前先尝试取任务；队列空 + stop_requested == true 才退出 - 析构函数里先置
stop_requested = true，再cv.notify_all()唤醒所有等待线程，最后对每个std::thread调用join()——顺序反了就会卡死 - 别在工作线程里调
std::this_thread::sleep_for来“降频”——这纯属浪费 CPU 时间片；条件变量 + 原子标志才是正解
std::jthread（C++20）能简化多少？哪些地方仍要手写
std::jthread 自动 join()，解决了最痛的析构安全问题，但它不提供任务队列、不管理线程数量、也不带停止令牌的自动传播——你还是得自己维护队列、同步原语和退出逻辑。
立即学习“C++免费学习笔记（深入）”；
- 能省掉的：不用手动
join()，不用写~thread_pool()里的 join 循环；std::jthread构造时可传std::stop_token，比裸用std::atomic<bool></bool>更标准 - 不能省的：任务队列的线程安全操作、
std::condition_variable的 wait/notify 逻辑、任务执行异常捕获（否则一个任务崩溃会让整个线程退出）、以及线程数量控制（std::jthread不是池，只是“可协作中断的 thread”） - 兼容性注意：GCC 10+、Clang 11+、MSVC 19.28+ 才完整支持
std::jthread；老项目慎用，别为了语法糖引入构建链路问题
真正难的从来不是“怎么启线程”，而是任务如何不丢、不重、不错序、不出错、不卡死——这些细节藏在队列锁粒度、唤醒时机、异常边界和停止信号传递路径里，漏掉任何一环，上线后都可能半夜报警。
