线程池动态调整

一次真实的翻车现场

一、为什么需要动态调整？

1.1 静态线程池的死穴：根本矛盾

线程池大小定下来之后，它面对的是时变的流量：

• 日内潮汐：白天高峰、凌晨低谷，峰值可能是谷值的 10 倍以上；
• 突发流量：大促、热点事件、定时任务集中触发；
• 任务画像漂移：有的请求命中缓存（纯计算），有的走 DB/RPC（重 IO），同一个线程池在不同时刻的"计算/等待"比例完全不同。

固定一个大小，意味着你只能为"某一个假设的场景"优化，其他场景必然错配。

1.2 经典公式的局限

线程数估算常用这个公式：

• CPU 密集型（W≈0）：N ≈ N_cpu；
• IO 密集型（W≫C）：N 可以远大于 N_cpu（如 2×~数十倍）。

1.3 太小 vs 太大：两种错配的代价

结论：理想的"刚好"只存在于某一瞬间。你需要的是一个能在区间内滑动的线程池，而不是一个定死的数值。

二、动态调整解决什么问题？

三、怎么动态调整？

3.1 底层机制：ThreadPoolExecutor 的可调参数

JDK 的 ThreadPoolExecutor 本身就把线程数暴露成了"运行时可改"的：

3.2 反馈信号：盯哪些指标

动态调整是"闭环控制"，首先得有"眼睛"——监控指标：

• 队列长度 executor.getQueue().size()：最直观的"压力计"；
• 活跃线程数 getActiveCount() 与 getPoolSize()：当前并发度；
• 任务排队等待时间：submit 到真正开始执行（反映队列拥堵）；
• 任务执行耗时（埋点 / Micrometer）：判断是不是慢调用；
• 拒绝次数：扩容失效的硬信号；
• 延迟分位 p95/p99：最该盯的 SLO；
• 饱和度 = activeCount / maxPoolSize。

3.3 调整算法：四种思路

3.4 一个可运行的动态调整实现（Java）

核心思想：定时采集指标 → 决策 → 调用 setter，并加步长限制 + 迟滞防抖动。

// 假设已有一个 ThreadPoolExecutor，core=4, max=64，使用有界队列
ThreadPoolExecutor executor = ...;
int core = 4, max = 64;
ScheduledExecutorService adjuster = Executors.newSingleThreadScheduledExecutor();

adjuster.scheduleAtFixedRate(() -> {
    int q      = executor.getQueue().size();
    int pool   = executor.getPoolSize();
    int target = pool;

    if (q > core) {                       // 队列堆积 → 扩容（每周期 +4，带步长）
        target = Math.min(max, pool + 4);
    } else if (q == 0 && pool > core) {  // 空闲 → 缩容（每周期 -2）
        target = Math.max(core, pool - 2);
    }

    if (target != pool) {
        // 同时调 core 和 max，才能"双向"伸缩
        executor.setCorePoolSize(target);
        executor.setMaximumPoolSize(Math.max(target, max));
    }
}, 0, 5, TimeUnit.SECONDS);

3.5 缩容到底做了什么

• 线程数 > corePoolSize，且某线程空闲超过 keepAliveTime → 回收该线程；
• 核心线程默认不回收；allowCoreThreadTimeOut(true) 后可回收到 0；
• setCorePoolSize 缩小：不会中断正在执行的任务，只影响"新建/补充"行为；
• 所以缩容是渐进、平滑的，不会瞬间把在跑的任务掐掉。

四、业界实践

五、交互演示：动态线程池模拟器

拖动"流量"滑块模拟请求到达速率，切换"动态调整"开关，观察线程池大小、队列、完成数、拒绝数的变化。

六、避坑与最佳实践

七、一图总结