线程池容量动态调整的关键是状态协商而非直接扩容缩容，即用原子变量存储目标容量，由各worker线程主动检查并启停，避免竞态导致的状态撕裂与崩溃。
线程池容量动态调整的关键不是“扩容缩容”，而是避免竞态下的状态撕裂
直接修改线程数量本身不难，难的是让 std::vector<:thread></:thread> 或 std::list 的增删操作与任务队列、唤醒逻辑完全同步。常见错误是：一边在 resize() 线程容器，一边有 worker 正在调用 queue.pop() 或刚被 cv.notify_one() 唤醒却找不到有效任务——结果 crash 或死锁。
真正可行的做法是把“容量变更”转为“状态协商”：新容量只是目标值，实际线程启停由每个 worker 主动检查并退出/启动，主线程只负责广播信号和等待确认。这样所有状态变更都发生在 worker 线程自己的栈上，无需锁住整个池。
- 用
std::atomic<size_t></size_t>存储目标容量（target_size），而非当前活跃数 - 每个 worker 循环开头检查
target_size.load() 且自己是“可退出的空闲线程”，就 clean exit - 主线程调用
set_capacity(n)后，只唤醒所有 waiting worker，不直接join()或detach() - 新增线程由一个专用的
launcher协程或后台线程按需启动，避免在 resize 调用栈里阻塞
任务队列必须支持带超时的 pop，否则缩容时 worker 无法及时感知退出信号
如果用 std::queue + std::condition_variable::wait() 无超时等待，缩容指令发出去后，空闲 worker 会永远卡在 cv.wait()，根本收不到 target_size 变更。这不是设计缺陷，是使用方式错。
正确做法是让 worker 的主循环基于 cv.wait_for()，每次最多等 10–50ms，然后主动检查退出条件。这个“心跳间隔”决定了缩容响应延迟上限。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要用
cv.wait(lock, []{ return !queue.empty(); })这类无超时写法 - 改用
cv.wait_for(lock, 20ms, [&]{ return !queue.empty() || should_exit.load(); }) -
should_exit是 per-worker 标志，由主线程在缩容时对满足条件的 worker 原子置位 - 即使队列为空，只要
should_exit为 true，worker 就执行清理并 return
std::thread 构造失败时必须回滚，否则 resize() 可能导致池处于半残缺状态
C++ 标准不保证 std::thread 构造一定能成功——内存不足、系统线程数达上限、stack size 不足都会抛 std::system_error。如果在 for 循环里批量创建线程，中途失败，已创建的线程没被管理，~ThreadPool() 也无法安全 join，程序大概率在析构时报错。
必须把线程启动封装成原子操作：要么全成功，要么已启线程全部 join 并清空容器。
- 先预留空间（如
workers_.reserve(new_size)），再逐个 try-catch 构造 - 捕获
std::system_error后，立刻对已 push_back 的 thread 对象调用join()，再 clear 容器 - 抛出异常前确保
workers_为空或全部 join 完毕，避免析构时访问 dangling thread - 别依赖 RAII 自动管理——
std::thread移动后原对象变为joinable()==false，但 vector 的 move 析构不会自动 join
Linux 下注意 /proc/sys/kernel/threads-max 和 ulimit -u 的硬限制
即使代码逻辑完美，std::thread 构造仍可能因系统级限制失败。比如默认 Ubuntu 的 threads-max 是 62976，但单进程能创建的线程数还受 ulimit -u（max user processes）约束，通常只有 4096。用户调 set_capacity(10000) 时根本不会报错，而是在第 4097 次构造时抛异常。
这不是 C++ 问题，是部署环境问题。框架里可以加一层探测：启动时用 getrlimit(RLIMIT_NPROC, &rlim) 获取软限，提前 warn 或 clamp 目标容量。
- 读取
/proc/self/status中的Threads:行可获当前线程数，用于 debug 输出 - 生产环境建议在
set_capacity()入口做 soft cap：target = std::min(target, (size_t)rlim.rlim_cur) - 不要尝试
setrlimit()动态提限——需要 root 权限，且影响整个进程，不安全
动态容量的价值不在“无限伸缩”，而在平滑应对突发负载；真正容易被忽略的，是 worker 线程退出时的资源释放顺序——比如 shared_ptr 管理的任务回调里又持有池的 this 指针，就会导致析构卡死。这种循环引用不会报错，但会让缩容 hang 住几秒甚至更久。
