线程池核心用std::queue+std::vector即可，需用std::mutex+std::condition_variable保证队列线程安全，running须为std::atomic，任务统一用std::function封装，析构前必须notify_all并join所有线程，工作线程需try/catch捕获异常。
线程池核心结构用 std::queue + std::vector<:thread></:thread> 就够了
不需要第三方库，C++11 起标准库已足够。关键不是“怎么堆砌类”，而是控制好任务入队、线程取任务、生命周期三者的同步边界。任务队列必须是线程安全的，但别一上来就套 std::mutex 锁整个 push/pop —— 容易成为瓶颈。更稳妥的做法是用 std::queue 配合一个独占 std::mutex 和一个 std::condition_variable，让空闲线程在无任务时阻塞等待。
工作线程循环体典型写法是：while (running) { pop_task(); if (task) task(); }。注意 running 必须是 std::atomic<bool></bool>，否则可能因编译器优化或 CPU 重排导致线程永远看不到终止信号。
std::function<void></void> 是最实用的任务封装方式
它能容纳 lambda、函数指针、绑定对象的成员函数，覆盖绝大多数回调场景。别试图用模板参数推导不同签名（比如 void(int) 或 int()），那会把线程池变成泛型工厂，增加复杂度且无实际收益。统一收口为无参无返回值，调用方自己用 std::bind 或捕获 lambda 包装参数即可。
- 错误示范：
template<typename f typename... args> void enqueue(F&& f, Args&&... args)</typename>—— 导致每个调用实例化不同函数，二进制膨胀，且难以统一管理生命周期 - 正确做法：接收
std::function<void></void>，构造时立即捕获所有外部变量，确保任务入队后不依赖调用栈 - 注意：lambda 捕获
this时，要确认对象生命周期长于线程池；否则用std::shared_ptr管理宿主对象
析构时必须显式 join() 所有线程，不能靠 ~thread() 抛异常
如果线程还在运行，std::thread 析构会调用 std::terminate()，程序直接崩溃。常见错误是只设 running = false 就不管了，忘了唤醒所有阻塞在 wait() 上的线程。
立即学习“C++免费学习笔记（深入）”；
安全关闭流程必须包含三步：
- 置
running = false - 调用
cv.notify_all()唤醒全部等待线程 - 对每个
std::thread对象调用join()（不能用detach()）
顺序不能错：先通知，再 join()。否则可能部分线程永远等不到任务，也收不到终止信号。
别忽略任务执行异常 —— 默认会杀死工作线程
一个未捕获的异常会让对应工作线程退出，线程池 silently 少掉一个 worker，后续任务排队延迟上升，但不会报错。这不是 bug，是 C++ 标准行为。
解决方法很简单：在每个工作线程的循环体内加 try/catch(...)，至少记录日志，再继续下一轮循环。
while (running) {
std::function<void()> task;
{
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, [this] { return !tasks.empty() || !running; });
if (!running && tasks.empty()) break;
if (!tasks.empty()) {
task = std::move(tasks.front());
tasks.pop();
}
}
if (task) {
try {
task();
} catch (...) {
// 记录异常，但不传播
}
}
}
真正难处理的是任务里抛出的异常需要被调用方感知。这时得升级接口，用 std::packaged_task + std::future，但会带来额外分配和同步开销 —— 大多数服务端场景其实只需要 fire-and-forget。
线程池最难的从来不是启动多少线程，而是任务生命周期和异常边界的清晰界定。一旦开始混用裸指针、手动 new 任务对象、或让任务持有外部锁，问题就会从并发变成竞态+死锁+内存泄漏的组合拳。
