动态线程池必须在任务提交、线程空闲、系统指标三处同时埋点，缺一不可；submit()需实时扩容、worker()需主动检测空闲退出、指标须滑动窗口平滑、resize()须原子+独占锁保障线程安全。
动态线程池不是靠“定时检查+硬编码阈值”就能稳住的，它必须在任务提交、线程空闲、系统指标三处同时埋点，缺一不可。否则扩容滞后、缩容激进、或 CPU 飙高却无响应，都是常见故障。
submit() 里必须触发扩容判断，不能只靠后台线程轮询
很多实现把 adjustPoolSize() 放在独立管理线程里每秒调用一次，这会导致任务积压时响应延迟——比如队列已满 20 个任务，但扩容要等下一秒才发生。正确做法是在每次 submit() 后立刻评估：
- 用
tasks.size()和high_watermark比较，超限就调addWorker() - 避免重复扩容：加锁检查
workers.size() < max_threads再操作 - 不要在
submit()里直接join()新线程，只emplace_back()启动 - 若使用
std::hardware_concurrency()作上限，注意它返回的是逻辑核数，非实时可用核数
worker() 循环中必须嵌入空闲检测与收缩逻辑
工作线程不能只管取任务、执行、再取；它得知道自己“是不是该退了”。常见错误是把收缩全交给管理线程，结果空闲线程堆积、资源不释放。
正确做法是在每个任务执行完后，立即检查是否满足回收条件：
立即学习“C++免费学习笔记（深入）”；
- 记录上一次取到任务的时间戳（
std::chrono::steady_clock::now()） - 用当前时间减去该时间戳，和
idle_timeout比较 - 若超时，调用
removeCurrentWorker()—— 注意这是从vector<thread>中安全移除自身 ID，并调detach()或令其自然退出 - 移除前需再次确认：全局空闲线程数 >
low_watermark，且总线程数 >min_threads
getCPULoad() 和 getAverageTaskTime() 不可简单采样，要带滑动窗口
单次 getCPULoad() 返回值波动剧烈（如瞬时 99%），直接喂给调整逻辑会引发抖动扩缩容。同理，一个慢任务拉高平均耗时，不该让整个池子缩容。
必须用滑动窗口平滑指标：
- CPU 使用率：维护最近 5 秒共 50 个采样点的
std::deque<double>，每次取均值 - 平均任务耗时：对最近 100 个完成任务的耗时做移动平均，丢弃超时异常值（如 > 10× 中位数）
- 任务队列长度：不是只看
tasks.size()，而是每 100ms 记录一次，取过去 1s 内的 P95 值，防突发尖峰误判 - 所有指标采集不得阻塞 worker 线程；建议用无锁环形缓冲区（
boost::lockfree::spsc_queue或自研）异步写入
resize() 操作本身必须线程安全且避免惊群
当多个线程同时触发 resize(8) 和 resize(6)，最终线程数可能变成 7 或崩溃。关键点不在“怎么改数量”，而在“谁来改、何时改、改完怎么同步”。
推荐方案：
- 用原子变量
atomic_current_threads记录当前有效线程数，所有判断基于它 -
resize()是唯一修改workers容器的地方，且必须持独占锁（std::unique_lock<std::mutex>） - 扩容时，用
workers.reserve()预分配内存，避免 vector 扩容重拷贝引发短暂阻塞 - 缩容时不直接 kill 线程，而是向目标 worker 发送退出信号（如设置 per-thread flag +
notify_one()），由其自行退出循环 - 禁止在
worker()中调resize()—— 这会导致锁嵌套死锁
真正难的不是“怎么加线程”，而是“加多少、何时加、加完怎么收、收的时候别卡住其他任务”。毫秒级伸缩的瓶颈往往不在算法，而在指标采集的延迟、锁粒度设计、以及 worker 主动退出的协作机制——这些地方错一点，整池子就飘。
