前言

线程池（thread pool）要解决的问题很具体：频繁地创建和销毁线程是有代价的。每次std::thread构造都要向操作系统申请内核对象和栈空间，销毁时要回收，任务本身却可能只执行几微秒。当任务数量远大于 CPU 核心数时，为每个任务开一个线程还会让调度器忙于切换，缓存局部性变差。线程池的思路是预先创建固定数量的工作线程，让它们从一个共享队列里取任务执行，把「线程的生命周期」和「任务的生命周期」解耦。

关于线程池，最常见的误解有三个。第一，认为线程数越多吞吐越高——实际上超过硬件并发度之后，额外线程只会增加上下文切换和内存占用，对 CPU 密集型任务没有帮助。第二，认为「无锁队列一定更快」——在竞争激烈时自旋和 CAS 失败重试的代价可能超过一把短临界区的互斥量，而且无锁队列的正确性极难保证。第三，认为线程池能自动解决数据竞争——池只负责调度，任务之间共享数据的同步仍然要由调用者负责。

本文按「为什么需要 → 由哪些部件组成 → 完整实现 → 关闭与异常边界」的顺序讲解，给出一个基于 C++17 标准库、可直接放进项目的线程池，并逐条列出实现中最容易踩的坑。文中所有代码都只按标准语义推演，本机没有编译器，不声称任何执行结果。

一、线程池的组成部件

一个最小可用的线程池由四部分组成。

• 
  
• 工作线程集合：一组长期存活的std::thread，每个线程运行同一个循环函数。
• 
  
• 任务队列：存放待执行任务的容器，通常是std::queue<std::function<void()>>。类型擦除让不同签名的任务能排进同一个队列。
• 
  
• 同步原语：一把std::mutex保护队列，一个std::condition_variable在队列为空时挂起工作线程。
• 
  
• 停止标志：告诉工作线程「不会再有新任务」，让它们把剩余任务做完后退出。
• 
  

工作线程的主循环可以概括成一句话：加锁、在条件变量上等待「有任务或要停止」、取一个任务、解锁、执行。解锁必须在执行任务之前完成，否则所有工作线程会被串行化，线程池退化成单线程。

这里有一个关键设计点：队列里存什么。如果只存std::function<void()>，调用者拿不到返回值，也拿不到异常。标准库给出的答案是std::packaged_task<R()>：它把可调用对象包装成一个任务，内部持有一个共享状态，关联一个std::future<R>。任务执行时返回值或异常被写进共享状态，调用者通过 future 取回。线程池只需要把packaged_task再包一层成void()塞进队列即可。

二、任务提交与类型推导

提交接口通常是可变参数模板：

template <class F, class... Args>
auto submit(F&& f, Args&&... args) -> std::future<std::invoke_result_t<F, Args...>>;

返回类型用std::invoke_result_t<F, Args...>推导（C++17 起可用；C++11/14 用std::result_of_t，后者在 C++17 弃用、C++20 移除）。std::invoke_result比decltype(f(args...))更准确，因为它同时支持普通可调用对象、函数指针和指向成员的指针。

参数如何绑定到任务上，有两种写法。第一种是std::bind(std::forward<F>(f), std::forward<Args>(args)...)，第二种是 lambda 捕获。lambda 的完美转发捕获（[f = std::forward<F>(f), ...]这种包展开）需要 C++20，C++17 下写不出来，所以本文用std::bind。但必须知道std::bind的两个限制：它按值 decay-copy 所有实参，引用语义要用std::ref显式表达；它要求被绑定的可调用对象和实参都是可拷贝构造的，因此 move-only 的捕获（比如std::unique_ptr）不能直接走这条路。如果项目里大量使用 move-only 捕获，更稳妥的做法是让submit直接接收一个已经绑定好的std::function<void()>或无参 lambda。

还有一个容易忽略的点：std::bind返回的对象在调用时并不会保留实参的值类别，传进来的右值在绑定那一刻就被移动或拷贝进了 bind 的存储。这对大多数任务没有影响，但如果任务内部依赖引用语义修改外部变量，必须写std::ref(x)。

三、完整实现

下面是一个完整版本，包含构造、提交、工作循环和优雅关闭。

// 适用于 C++17
#include <condition_variable>
#include <functional>
#include <future>
#include <mutex>
#include <queue>
#include <stdexcept>
#include <thread>
#include <type_traits>
#include <utility>
#include <vector>

class ThreadPool {
public:
explicit ThreadPool(std::size_t n = std::thread::hardware_concurrency())
: stop_(false) {
if (n == 0) n = 1; // hardware_concurrency 可能返回 0
workers_.reserve(n);
for (std::size_t i = 0; i < n; ++i) {
workers_.emplace_back([this] { workerLoop(); });
}
}

~ThreadPool() { shutdown(); }

ThreadPool(const ThreadPool&) = delete;
ThreadPool& operator=(const ThreadPool&) = delete;

template <class F, class... Args>
auto submit(F&& f, Args&&... args)
-> std::future<std::invoke_result_t<F, Args...>> {
using R = std::invoke_result_t<F, Args...>;

auto bound = std::bind(std::forward<F>(f), std::forward<Args>(args)...);
auto task = std::make_shared<std::packaged_task<R()>>(std::move(bound));
std::future<R> fut = task->get_future();

{
std::lock_guard<std::mutex> lk(mtx_);
if (stop_) {
throw std::runtime_error("submit on a stopped ThreadPool");
}
// 类型擦除：packaged_task<R()> 不能直接放进 void() 的队列
tasks_.emplace([task] { (*task)(); });
}
cv_.notify_one();
return fut;
}

void shutdown() {
{
std::lock_guard<std::mutex> lk(mtx_);
if (stop_) return;
stop_ = true;
}
cv_.notify_all();
for (auto& t : workers_) {
if (t.joinable()) t.join();
}
}

private:
void workerLoop() {
for (;;) {
std::function<void()> job;
{
std::unique_lock<std::mutex> lk(mtx_);
cv_.wait(lk, [this] { return stop_ || !tasks_.empty(); });
if (stop_ && tasks_.empty()) return; // 停止且已排空
job = std::move(tasks_.front());
tasks_.pop();
} // 先解锁
job(); // 再执行
}
}

std::vector<std::thread> workers_;
std::queue<std::function<void()>> tasks_;
std::mutex mtx_;
std::condition_variable cv_;
bool stop_;
};

几个细节值得展开。

为什么stop_不用std::atomic<bool>。它只在持锁时读写，锁已经提供了同步，普通bool就够。若改成原子变量而仍然在锁外读，就必须自己保证「检查停止标志」和「检查队列」这两步之间不出现竞态，反而更容易写错。

为什么用std::make_shared<std::packaged_task<R()>>。packaged_task不可拷贝，而std::function要求目标可拷贝。把它放进shared_ptr，lambda 捕获的是这个指针，拷贝的是指针本身，任务对象仍然只有一份。make_shared让控制块和对象一次分配，比shared_ptr(new ...)少一次分配，也让异常安全性更好。

等待谓词为什么是stop_ || !tasks_.empty()。条件变量存在虚假唤醒（spurious wakeup），不带谓词的wait返回后条件未必成立。带谓词的重载会在内部循环，只有谓词为真才返回，这是标准库推荐写法。

为什么shutdown里要notify_all而不是notify_one。停止信号是广播性质的：所有工作线程都要醒来检查stop_，只唤醒一个会让其余线程永远睡在条件变量上，join随之卡死。

四、关闭语义与返回值

关闭有两种常见语义。第一种是「排空后退出」：已经入队的任务全部执行完再结束，上面的实现就是这种，判断条件是stop_ && tasks_.empty()。第二种是「立即丢弃」：清空队列直接退出，适合取消场景。两者没有对错，但必须在文档里写清楚，否则调用者无法预期析构要花多久。如果某个任务会阻塞很久（等待网络、等待另一个池的任务），排空式关闭就会让析构函数长时间阻塞。因此生产代码常常再加一个std::atomic<bool> cancelled_，让长任务自己检查取消标志。

返回值路径是这样的：packaged_task::get_future()在提交线程调用，拿到std::future<R>；任务在工作线程执行时把结果写进共享状态；调用线程fut.get()阻塞直到结果就绪。如果任务抛出异常，packaged_task会捕获它并存入共享状态，get()重新抛出——这一点很重要，它意味着工作者线程不会因为任务异常而std::terminate。但前提是任务确实被packaged_task包着。如果队列里存的是裸std::function且直接调用job()，异常会逃出workerLoop，而线程函数抛出未捕获异常会调用std::terminate。

使用示例如下。

// 适用于 C++17
#include <iostream>
#include <string>

int main() {
ThreadPool pool(4);

auto sum = pool.submit([](int a, int b) { return a + b; }, 2, 3);
auto text = pool.submit([] { return std::string("hello"); });
auto boom = pool.submit([]() -> int { throw std::runtime_error("bad"); });

std::cout << sum.get() << '\n'; // 5
std::cout << text.get() << '\n'; // hello

try {
boom.get(); // 异常在这里重新抛出
} catch (const std::exception& e) {
std::cout << "caught: " << e.what() << '\n';
}

pool.shutdown(); // 也可以交给析构
return 0;
}

注意sum.get()与text.get()的先后顺序只影响等待顺序，不影响任务执行顺序——多线程下任务的完成次序本来就不确定。要保证顺序，只能用单工作线程的池，或者在任务之间自行加同步。

常见坑点

1. 
   
2. ❌ 在析构函数里对工作线程调用detach()，然后成员（队列、互斥量）先被销毁。
3. 
   

✅ 析构里先置停止标志、notify_all、再逐个join()，确保线程在成员销毁前退出。

1. 
   
2. ❌cv_.wait(lk)不带谓词，被虚假唤醒后直接tasks_.front()。
3. 
   

✅cv_.wait(lk, [this]{ return stop_ || !tasks_.empty(); })，醒来后条件一定成立。

1. 
   
2. ❌ 持锁执行任务：{ lock_guard lk(mtx_); job(); }，所有工作者被串行化。
3. 
   

✅ 在锁内只取出任务，出作用域解锁后再执行。

1. 
   
2. ❌ 工作线程中抛出异常且没人捕获，程序直接std::terminate。
3. 
   

✅ 用packaged_task包装任务，或在workerLoop里try/catch兜底记录日志。

1. 
   
2. ❌ 任务 lambda 按引用捕获局部变量，submit返回后局部变量已销毁。
3. 
   

✅ 按值捕获，或确保被引用对象的生命周期覆盖任务执行期。

1. 
   
2. ❌ 在池内任务里调用pool.shutdown()，工作线程join自己。
3. 
   

✅ 关闭由池外线程发起；池内任务只设置取消标志。

1. 
   
2. ❌ 用std::thread::hardware_concurrency()直接当线程数，不处理返回 0 的情况。
3. 
   

✅ 判零后回退到 1，或由调用者显式传入。

1. 
   
2. ❌ 丢弃submit返回的 future，任务抛出的异常被静默吞掉。
3. 
   

✅ 需要感知失败时保留 future 并get()，或在任务内部自行处理异常。

总结

线程池的本质是把「线程」这个昂贵资源变成可复用的池化资源，核心难点不在语法，而在同步边界：锁的粒度、条件变量的谓词、关闭时机的定义。把这三件事写对，剩下的就是按业务补充取消、优先级和动态扩缩容。任何涉及共享状态的修改都要在锁内完成，任何可能阻塞的调用都不要持锁执行。