线程池设计：从原理到实战
线程池这东西，说白了就是「提前招一批工人，有活就干，没活就等着」。我在早期做C++服务端开发时，一开始都是来一个任务就new一个线程，结果服务器撑不住，直接OOM了。嗯，从那以后，线程池就成了我工具箱里的标配。
线程池的核心原理
为什么需要线程池？你想想看，每次创建线程都要做系统调用，分配栈空间，调度器还要注册新线程。如果任务本身只执行几毫秒，那创建线程的开销可能比任务本身还大。线程池的核心思路就是：复用线程，减少创建和销毁的开销。
一个典型的线程池包含三个部分：
- 工作线程集合：一组已经创建好的线程，等待任务
- 任务队列：存放待执行的任务，通常是函数对象
- 同步机制：协调任务的生产和消费
核心思想：线程池的生命周期内，线程数量基本固定。任务来了就塞进队列，空闲线程从队列取任务执行。没有任务时，线程阻塞等待，不占用CPU。
我在项目中遇到过一种情况：线程池里的线程数设得太多，结果上下文切换比干活还频繁。后来我总结了一个经验——线程数通常设为 std::thread::hardware_concurrency() 或者略少一点。
简单线程池的实现
我们先写一个最精简的版本。别怕，代码不长，核心逻辑都在里面。
#include <vector>
#include <queue>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <functional>
#include <future>
class ThreadPool {
public:
ThreadPool(size_t threads) : stop(false) {
for (size_t i = 0; i < threads; ++i) {
workers.emplace_back([this] {
while (true) {
std::function<void()> task;
{
std::unique_lock<std::mutex> lock(this->queue_mutex);
this->condition.wait(lock, [this] {
return this->stop || !this->tasks.empty();
});
if (this->stop && this->tasks.empty())
return;
task = std::move(this->tasks.front());
this->tasks.pop();
}
task();
}
});
}
}
template<class F, class... Args>
auto enqueue(F&& f, Args&&... args)
-> std::future<typename std::result_of<F(Args...)>::type> {
using return_type = typename std::result_of<F(Args...)>::type;
auto task = std::make_shared<std::packaged_task<return_type()>>(
std::bind(std::forward<F>(f), std::forward<Args>(args)...)
);
std::future<return_type> res = task->get_future();
{
std::unique_lock<std::mutex> lock(queue_mutex);
if (stop)
throw std::runtime_error("enqueue on stopped ThreadPool");
tasks.emplace([task](){ (*task)(); });
}
condition.notify_one();
return res;
}
~ThreadPool() {
{
std::unique_lock<std::mutex> lock(queue_mutex);
stop = true;
}
condition.notify_all();
for (std::thread &worker : workers)
worker.join();
}
private:
std::vector<std::thread> workers;
std::queue<std::function<void()>> tasks;
std::mutex queue_mutex;
std::condition_variable condition;
bool stop;
};这段代码里，我用了 std::packaged_task 和 std::future 来获取任务的返回值。你可能会问：为什么不用裸的 std::function？嗯，因为我想让调用者能拿到结果。比如你提交一个计算任务，后面需要知道结果，future就是干这个的。
个人习惯：我一般把线程池的析构设计成「等待所有任务完成再退出」。有些场景需要「立即取消所有任务」，那就得加一个 cancel 接口。具体用哪种，取决于业务需求。
任务队列与工作线程的协调
这是线程池最微妙的地方。说白了就是「生产者-消费者」模型。主线程是生产者，工作线程是消费者。协调不好，要么死锁，要么忙等浪费CPU。
关键点有三个：
- 互斥访问：任务队列是共享资源，必须用 mutex 保护
- 条件变量通知：有新任务时，通知一个空闲线程来取
- 优雅退出：线程池销毁时，确保所有线程安全退出
我曾经踩过一个坑：在 enqueue 里先 notify 再解锁。看起来没问题，但实际上可能导致「通知了但线程还没醒来，通知信号就丢了」。正确的做法是：先解锁，再 notify，或者用 notify_one 在锁内调用也没问题，因为条件变量会自己处理。
注意：条件变量的 wait 必须配合一个谓词（lambda）使用。否则可能出现「虚假唤醒」——线程被唤醒了，但队列还是空的。我早期写代码就吃过这个亏，查了半天才发现是谓词没写。
下面这张图展示了线程池的完整工作流程：
从图上你能看到，整个流程是单向的：主线程塞任务，工作线程取任务，执行完返回结果。停止时，主线程设置 stop 标志，通知所有线程，线程检查到 stop 且队列为空就退出。
使用示例
写个简单的测试代码，看看怎么用：
#include <iostream>
int main() {
ThreadPool pool(4); // 4个工作线程
// 提交任务，获取future
auto result = pool.enqueue([](int a, int b) {
return a + b;
}, 10, 20);
std::cout << "10 + 20 = " << result.get() << std::endl;
// 批量提交
std::vector<std::future<int>> results;
for (int i = 0; i < 8; ++i) {
results.emplace_back(
pool.enqueue([i] {
return i * i;
})
);
}
for (auto &res : results) {
std::cout << res.get() << " ";
}
std::cout << std::endl;
return 0;
}避坑指南：我曾经在项目里把线程池声明为局部变量，结果函数返回时线程池析构，但还有任务没执行完。解决方案是：要么保证线程池生命周期足够长，要么在析构里等待所有任务完成。上面代码用的是后者。
性能考量
线程池不是万能的。我总结了几条经验：
| 场景 | 推荐做法 | 原因 |
|---|---|---|
| 任务耗时 < 1ms | 用线程池，但考虑批量提交 | 减少锁竞争 |
| 任务耗时 1ms ~ 100ms | 线程池最合适 | 平衡创建开销和并发度 |
| 任务耗时 > 1s | 线程池 + 动态调整线程数 | 避免线程长时间被占用 |
| IO密集型 | 线程数可以设大一些 | 线程经常阻塞在IO上 |
| CPU密集型 | 线程数 = 核心数 | 避免过多上下文切换 |
嗯，最后说一句：线程池的实现有很多变体。比如有的需要优先级队列，有的需要动态扩容，有的需要任务窃取（work-stealing）。但不管怎么变，核心原理就是「复用线程 + 任务队列 + 条件变量同步」。把这个基础打牢了，其他变体都是锦上添花。