线程池扩容不等于“动态增加线程”，而是运行时创建新std::thread并纳入任务分发逻辑；需确保队列、条件变量、线程计数等同步，且扩容操作线程安全。
线程池扩容是否等于“动态增加线程”
不是。标准 std::thread 一旦启动就无法被“加入”已有线程池；所谓“动态增加”，实际是线程池对象自身在运行时创建新 std::thread 并纳入其任务分发逻辑——关键在于你用的线程池是否支持运行时扩容。
多数轻量实现（如仅用 std::vector<:thread></:thread> + std::queue）默认不提供安全的扩容接口，强行 push_back 新线程会导致任务调度逻辑错乱或竞态。
- 扩容前必须确保任务队列、唤醒机制（如
std::condition_variable）能被新增线程正确监听 - 已存在的空闲线程不能“接管”新增线程的职责，每个线程需独立等待并消费任务
- 扩容操作本身需加锁，且要避免在调用
notify_one()时目标线程尚未开始 wait
使用 boost::thread_pool 或 progschj::ThreadPool 的扩容方式
第三方库中，progschj::ThreadPool（GitHub 常见轻量实现）支持运行时调整规模，但需手动触发重配置；boost::thread_pool（Boost 1.78+）则通过 resize() 提供线程数变更能力，内部处理了线程启停与状态同步。
以 boost::thread_pool 为例：
立即学习“C++免费学习笔记（深入）”；
boost::thread_pool pool(4); // 运行一段时间后 pool.resize(8); // 安全：新线程自动启动并进入 wait 状态
-
resize(n)是线程安全的，可从任意线程调用 - 若
n < 当前数量，空闲线程会自然退出；忙碌线程不受影响，完成任务后退出 - Boost 内部使用
boost::barrier和条件变量协调，避免“唤醒丢失” - 注意：Boost 线程池不提供任务优先级或延迟执行，仅适用于均匀负载场景
手写线程池实现扩容的关键点
若坚持自研，核心不是“加线程”，而是让新增线程能与原有调度器协同工作。重点不在 std::thread 构造，而在初始化逻辑的一致性。
- 所有线程（包括扩容新增的）必须共享同一
std::queue<std::function<void()>>和同一std::condition_variable - 新增线程启动前，必须确保任务队列已处于可访问状态，且互斥锁未被长期持有
- 推荐用“懒启动”：扩容时不立即创建线程，而是在下次有任务提交且空闲线程不足时，按需唤醒或新建——这比盲目扩容更可控
- 务必检查
std::thread析构：未join()或detach()会触发std::terminate，扩容失败时容易漏掉这个清理
为什么 std::thread 本身不支持“加入线程池”
因为 std::thread 是执行单元抽象，不是调度单元。它没有内置任务队列、唤醒协议或生命周期管理接口。所谓“线程池线程”，本质是运行着固定循环逻辑的 std::thread：
while (!done) {
std::function<void()> task;
{
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, [&] { return !tasks.empty() || done; });
if (done && tasks.empty()) break;
task = std::move(tasks.front());
tasks.pop();
}
task();
}
这段逻辑决定了它“属于哪个池”——不是靠注册，而是靠它执行的代码是否接入了那个池的队列和条件变量。换言之，没有“加入”，只有“写对了逻辑并启动”。
真正容易被忽略的是：扩容后若未同步更新线程计数、未重新广播 cv.notify_all()、或新增线程在旧线程退出前就抢光了任务，都会导致部分线程饿死或任务堆积。这些细节比“怎么 new 一个 thread”重要得多。
