背景与问题

在线上 Java 服务里，线程池几乎无处不在：异步下单、消息消费、批量推送、日志落盘、定时任务执行……它是吞吐能力的放大器，但也是问题放大的入口。

我自己排查过不少“服务没挂，但就是越来越慢”的故障，最后都绕不开一个关键词：任务堆积。

典型现象通常长这样：

接口 RT 持续升高
队列长度不断增加
CPU 不一定高，但线程池活跃线程已满
业务日志出现明显延迟
GC 次数增多，甚至出现 OOM
上游不断重试，进一步放大流量洪峰

很多人第一反应是：“把线程池开大一点。”
这招有时候有效，但也非常容易把问题从“慢”变成“更慢”，甚至直接把机器拖死。

这篇文章我会从排查问题的角度来讲，不只讲参数名是什么，还会讲：

为什么会堆积
怎么复现
如何一步步定位
参数应该怎么调
遇到线上故障如何先止血

背景与问题：任务为什么会堆积

先看一个简化版过程：业务线程把任务提交到线程池，线程池先尝试用核心线程处理，处理不过来就放入队列，队列再满了才考虑扩容到最大线程数，最后实在扛不住才触发拒绝策略。

如果任务生产速度持续大于消费速度，堆积就会出现。

flowchart TD
    A[业务提交任务] --> B{当前运行线程 < corePoolSize?}
    B -- 是 --> C[创建核心线程执行]
    B -- 否 --> D{队列是否可入队?}
    D -- 是 --> E[任务进入阻塞队列]
    D -- 否 --> F{线程数 < maximumPoolSize?}
    F -- 是 --> G[创建非核心线程执行]
    F -- 否 --> H[触发拒绝策略]

关键点在于：

提交速度太快
单个任务执行太慢
下游依赖变慢（数据库、Redis、HTTP、MQ）
队列设置不合理
拒绝策略不合适
线程池被错误复用，多个业务互相影响

很多“线程池调优失败”的根因，其实不是线程数，而是任务本身变慢了。线程池只是把这个问题显性化。

核心原理

1. ThreadPoolExecutor 的核心参数

Java 里最常见的是 ThreadPoolExecutor，重点参数有 7 个：

corePoolSize：核心线程数
maximumPoolSize：最大线程数
keepAliveTime：非核心线程空闲存活时间
unit：时间单位
workQueue：任务队列
threadFactory：线程工厂
handler：拒绝策略

一个典型构造如下：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
        4,
        8,
        60,
        TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(100),
        Executors.defaultThreadFactory(),
        new ThreadPoolExecutor.CallerRunsPolicy()
);

2. 线程池不是“先加线程，再进队列”

这个地方特别容易记混。

实际流程是：

当前线程数 < corePoolSize：直接创建线程
否则任务先入队
队列满了之后，才尝试扩容到 maximumPoolSize
如果最大线程数也满了，才拒绝

这意味着：

大队列 + 小 maximumPoolSize：可能看起来永远不会扩容，只会一直堆队列
SynchronousQueue：几乎不存任务，容易快速扩线程
无界队列：最大线程数往往形同虚设

3. 不同任务类型的调优思路不同

线程池参数不能脱离任务类型来谈。

CPU 密集型

比如：

JSON 编解码
加密解密
图像处理
复杂规则计算

这类任务主要吃 CPU，线程数一般接近 CPU 核数即可。线程太多只会增加上下文切换。

经验值：

线程数 ≈ CPU 核数 或 CPU 核数 + 1

IO 密集型

比如：

访问数据库
调用外部 HTTP 服务
读写文件
查询缓存但伴随网络等待

这类任务大量时间在等待，线程数可以比 CPU 核数大一些，但不能无脑翻十倍。

经验公式常见写法：

最佳线程数 ≈ CPU 核数 * (1 + 等待时间 / 计算时间)

这只是起点，不是最终答案。真正上线还是要看监控数据。

现象复现

先做一个可以运行的小例子，模拟“任务提交很快，但执行很慢”导致的堆积。

示例代码：制造线程池任务堆积

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

public class ThreadPoolBacklogDemo {

    public static void main(String[] args) throws InterruptedException {
        AtomicInteger taskId = new AtomicInteger(0);

        ThreadFactory factory = r -> {
            Thread t = new Thread(r);
            t.setName("biz-pool-" + t.getId());
            return t;
        };

        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                2,
                4,
                30,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(10),
                factory,
                new ThreadPoolExecutor.AbortPolicy()
        );

        ScheduledExecutorService monitor = Executors.newSingleThreadScheduledExecutor();
        monitor.scheduleAtFixedRate(() -> {
            System.out.printf(
                    "[MONITOR] poolSize=%d, active=%d, queueSize=%d, completed=%d, taskCount=%d%n",
                    executor.getPoolSize(),
                    executor.getActiveCount(),
                    executor.getQueue().size(),
                    executor.getCompletedTaskCount(),
                    executor.getTaskCount()
            );
        }, 0, 1, TimeUnit.SECONDS);

        for (int i = 0; i < 50; i++) {
            int id = taskId.incrementAndGet();
            try {
                executor.submit(() -> {
                    String threadName = Thread.currentThread().getName();
                    System.out.println("Task-" + id + " started by " + threadName);
                    try {
                        // 模拟慢任务
                        Thread.sleep(3000);
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    }
                    System.out.println("Task-" + id + " finished by " + threadName);
                });
            } catch (RejectedExecutionException e) {
                System.err.println("Task-" + id + " rejected: " + e.getMessage());
            }

            // 模拟高频提交
            Thread.sleep(100);
        }

        Thread.sleep(20000);
        monitor.shutdown();
        executor.shutdown();
    }
}

运行后你会看到什么

这个例子中：

任务每 100ms 提交一个
每个任务执行 3000ms
消费能力远低于生产能力

所以会出现：

活跃线程很快打满
队列长度快速上升
队列满后扩容到最大线程数
最终开始拒绝任务

这就是线上最常见的“堆积演化路径”。

定位路径：线上怎么一步步查

排查线程池问题，我一般不会上来就改参数，而是按这条路径走。

第一步：看现象是不是线程池问题

先确认是不是这个池子在背锅。关注这些指标：

activeCount
poolSize
largestPoolSize
queueSize
completedTaskCount
taskCount
拒绝次数
平均任务执行时长
最大任务执行时长

可以理解成：

activeCount 接近 maximumPoolSize：说明线程跑满了
queueSize 持续增长：说明消费能力不足
completedTaskCount 增长变慢：说明执行速度下降
拒绝次数开始出现：说明已经顶不住了

第二步：区分是“提交过快”还是“执行变慢”

这个判断特别重要。

提交过快的常见原因

突发流量
上游重试风暴
定时任务批量触发
消费端拉取太猛

执行变慢的常见原因

SQL 变慢
远程接口超时
锁竞争
大对象分配导致 GC 抖动
任务内部又嵌套提交线程池并相互等待

如果只是提交变快，可以做限流、削峰、降级。
如果是执行变慢，不解决下游依赖，光加线程池通常没用。

第三步：抓线程栈

线上很实用的手段是 jstack。

jstack <pid> > threads.log

重点看线程池工作线程在做什么：

是卡在 TIMED_WAITING？
是阻塞在数据库连接池？
是卡在网络读写？
是在等锁？
是在 Future.get() 上等待别的异步结果？

我踩过一个很典型的坑：A 线程池里的任务又提交到 B 线程池，然后同步 get() 等结果；而 B 线程池此时也在等 A 的资源，最后两个池一起拖住。看监控只看到“线程池满了”，真正根因却是线程池间相互等待。

第四步：看队列类型

不同队列，对故障表现差别非常大。

队列类型	特点	风险
`LinkedBlockingQueue`	默认可很大，容易堆积	内存占用增长，最大线程数不生效明显
`ArrayBlockingQueue`	有界、容量明确	容量过小会频繁拒绝
`SynchronousQueue`	不存储任务，直接移交	流量波动时线程数可能快速拉高
`PriorityBlockingQueue`	可按优先级消费	任务可能“饥饿”，且默认无界

如果你用了无界队列，再把 maximumPoolSize 配很大，很多时候其实没意义，因为任务根本不会触发扩容，而是一直进队列。

核心原理图：任务堆积的排查逻辑

flowchart TD
    A[发现 RT 升高/任务延迟] --> B[查看线程池指标]
    B --> C{activeCount 是否接近上限?}
    C -- 否 --> D[先查业务链路其他瓶颈]
    C -- 是 --> E{queueSize 是否持续增长?}
    E -- 否 --> F[关注锁竞争/短时抖动]
    E -- 是 --> G[抓线程栈 + 看下游依赖]
    G --> H{任务执行变慢?}
    H -- 是 --> I[优化任务逻辑/依赖/超时]
    H -- 否 --> J[评估流量突增与限流削峰]
    I --> K[再调线程池参数]
    J --> K

实战代码（可运行）

下面给一个更接近生产实践的版本：带命名线程、拒绝处理、监控输出、优雅关闭。

一个更稳妥的线程池封装示例

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

public class ThreadPoolTuningExample {

    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor executor = buildExecutor("order-dispatch", 4, 8, 200);

        ScheduledExecutorService metricsPrinter = Executors.newSingleThreadScheduledExecutor(r -> {
            Thread t = new Thread(r);
            t.setName("metrics-printer");
            return t;
        });

        metricsPrinter.scheduleAtFixedRate(() -> printStats("order-dispatch", executor),
                0, 2, TimeUnit.SECONDS);

        for (int i = 0; i < 100; i++) {
            final int taskId = i;
            try {
                executor.execute(() -> {
                    long start = System.currentTimeMillis();
                    try {
                        // 模拟混合型任务：部分计算 + IO等待
                        busyCpu(50);
                        Thread.sleep(200);
                        System.out.println(Thread.currentThread().getName()
                                + " processed task-" + taskId
                                + ", cost=" + (System.currentTimeMillis() - start) + "ms");
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        System.err.println("task-" + taskId + " interrupted");
                    } catch (Exception e) {
                        System.err.println("task-" + taskId + " failed: " + e.getMessage());
                    }
                });
            } catch (RejectedExecutionException e) {
                System.err.println("task-" + taskId + " rejected");
            }

            Thread.sleep(30);
        }

        Thread.sleep(10000);
        shutdownGracefully(metricsPrinter);
        shutdownGracefully(executor);
    }

    private static ThreadPoolExecutor buildExecutor(String poolName, int core, int max, int queueSize) {
        AtomicInteger counter = new AtomicInteger(1);

        ThreadFactory factory = r -> {
            Thread t = new Thread(r);
            t.setName(poolName + "-" + counter.getAndIncrement());
            t.setUncaughtExceptionHandler((thread, ex) ->
                    System.err.println("Uncaught exception in " + thread.getName() + ": " + ex.getMessage()));
            return t;
        };

        RejectedExecutionHandler handler = (r, executor) -> {
            System.err.printf("[REJECTED] pool=%s, active=%d, queue=%d%n",
                    poolName, executor.getActiveCount(), executor.getQueue().size());
            throw new RejectedExecutionException("Task rejected from " + poolName);
        };

        return new ThreadPoolExecutor(
                core,
                max,
                60L,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(queueSize),
                factory,
                handler
        );
    }

    private static void printStats(String poolName, ThreadPoolExecutor executor) {
        System.out.printf(
                "[POOL-%s] core=%d, max=%d, pool=%d, active=%d, queue=%d, completed=%d, task=%d%n",
                poolName,
                executor.getCorePoolSize(),
                executor.getMaximumPoolSize(),
                executor.getPoolSize(),
                executor.getActiveCount(),
                executor.getQueue().size(),
                executor.getCompletedTaskCount(),
                executor.getTaskCount()
        );
    }

    private static void busyCpu(long ms) {
        long end = System.currentTimeMillis() + ms;
        while (System.currentTimeMillis() < end) {
            Math.sqrt(System.nanoTime());
        }
    }

    private static void shutdownGracefully(ExecutorService executor) throws InterruptedException {
        executor.shutdown();
        if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
            executor.shutdownNow();
        }
    }
}

这个版本里有几个点比较实用：

自定义线程名，方便 jstack 和日志排查
拒绝策略显式记录上下文
打印核心指标，便于观察变化趋势
优雅关闭，避免应用退出时任务丢失

参数到底怎么调

这里不讲“标准答案”，只讲更接近实战的调法。

场景一：接口异步化，任务短平快

特点：

单个任务几十毫秒到几百毫秒
任务多但相对独立
可接受少量丢弃或降级

建议：

用有界队列
corePoolSize 从 CPU 核数附近起步
maximumPoolSize 适当放大，但不要过高
拒绝策略优先考虑记录日志 + 降级处理
必须配监控

场景二：依赖数据库或外部服务

特点：

任务时间波动大
容易被下游拖慢
盲目加线程可能把数据库打爆

建议：

线程池大小要和下游连接池容量联动
先设置任务超时，再谈扩线程
队列不要过大，否则延迟会被悄悄吞掉
更适合做限流和熔断，而不是无限堆任务

场景三：消息消费堆积

特点：

MQ 消费端拉取速度快
消费逻辑慢
可能造成消息重试和重复消费

建议：

控制消费并发度
线程池与 MQ 拉取批量大小一起调
做好幂等
监控队列积压与消费耗时分位数

常见坑与排查

1. 使用 Executors 工厂方法直接创建线程池

比如：

ExecutorService executor = Executors.newFixedThreadPool(10);

这类写法不是不能用，而是很容易忽略底层细节。
例如 newFixedThreadPool 背后是无界队列，任务堆积时可能不断吃内存。

更推荐直接使用 ThreadPoolExecutor 明确参数。

2. 队列太大，看起来“很稳”，其实在隐藏故障

很多系统平时没问题，一到高峰队列从几百涨到几万，但服务还活着，于是大家觉得线程池挺稳。

实际上这只是把问题从“拒绝任务”变成“超长延迟 + 内存上涨”。

队列不是保险箱，它只是缓冲区。

如果任务已经失去实时价值，比如短信、推送、实时风控校验，队列过长往往意味着结果已经“过期”。

3. 任务内部吞异常

线程池里的异常如果处理不好，很容易悄悄丢失。

错误示例：

executor.submit(() -> {
    int x = 1 / 0;
});

如果你既不 get()，也没有日志，问题可能就这样过去了。

更稳妥的做法：

任务内部捕获并记录关键上下文
自定义 ThreadFactory 设置 UncaughtExceptionHandler
对关键任务使用 Future 并显式检查结果

4. 线程池共享过多业务

一个线程池里同时跑：

用户请求异步任务
导出任务
对账任务
MQ 消费

高峰时一定互相影响。
建议按业务隔离、优先级隔离、资源隔离拆分线程池。

5. 线程数过大导致上下文切换严重

不是线程越多越快。
尤其 CPU 密集任务，把线程数开到几百，经常只会让 CPU 在切换线程而不是处理业务。

6. 忽略了下游资源池限制

这个非常常见：

线程池 100
数据库连接池 20
HTTP 连接池 30

结果就是大量线程堵在连接获取上，活跃线程看着很高，业务吞吐却很低。
这时调大线程池是错方向，应该先看连接池、超时、重试策略。

线程池、队列、下游依赖的关系

sequenceDiagram
    participant Client as 上游请求
    participant Pool as 线程池
    participant Queue as 阻塞队列
    participant Worker as 工作线程
    participant Downstream as DB/HTTP/Redis

    Client->>Pool: 提交任务
    alt 核心线程可用
        Pool->>Worker: 直接执行
    else 无空闲核心线程
        Pool->>Queue: 任务入队
    end

    Worker->>Downstream: 调用下游
    Downstream-->>Worker: 响应变慢/超时
    Worker-->>Pool: 线程长期占用
    Queue-->>Pool: 队列持续堆积
    Pool-->>Client: 拒绝/超时/延迟升高

这张图想表达一个很实战的结论：

线程池问题往往是下游变慢的放大器，而不是唯一根因。

止血方案：线上堆积了先怎么办

如果已经在线上出现任务堆积，不要直接改一堆参数。优先考虑“先恢复服务”。

方案一：限流

适用场景：

突发流量
非核心任务
上游可接受失败或降级

做法：

网关限流
业务接口限流
MQ 降低拉取速度
非核心异步任务暂停提交

方案二：快速失败

如果队列已经满了，与其让请求等 30 秒超时，不如快速拒绝，让上游及时感知。

适用场景：

实时任务
过期后无价值任务
用户可重试场景

方案三：任务降级

例如：

非关键日志异步写本地文件
推送由实时改为批量
风控次级校验暂时关闭
缩短任务执行链路

方案四：隔离慢依赖

如果是某个下游拖慢全部任务：

为该依赖单独拆线程池
设置更短超时
熔断故障依赖
失败快速返回默认值或补偿逻辑

方案五：谨慎扩容

扩线程池只有在以下条件同时满足时才值得做：

机器资源有余量
下游还能承受更高并发
任务确实是等待型而非 CPU 打满
有监控可以观察调整后效果

安全/性能最佳实践

1. 永远使用有界队列

这是我非常建议的一条。
有界队列让系统在压力面前表现得更可控，不会无限吞内存。

2. 线程池参数要和依赖容量对齐

不要只盯线程池本身，还要看：

数据库连接池大小
Redis 连接数
HTTP 客户端连接池
下游限流阈值

3. 给任务设置超时

如果任务里调用外部依赖，没有超时，线程就可能长期不释放。

例如：

HTTP 请求超时
数据库查询超时
Future.get(timeout) 超时
锁等待超时

4. 监控必须覆盖“趋势”而非单点值

要监控这些指标的变化曲线：

队列长度
活跃线程数
任务耗时 P95/P99
拒绝次数
完成任务速率
提交任务速率

只看某一时刻的线程数，经常看不出问题。

5. 线程命名规范化

线程名里建议带上：

应用模块
业务含义
池子用途
编号

比如：

order-dispatch-1
mq-consumer-payment-3
export-worker-2

排查时真的省很多时间。

6. 不要在任务里做无限重试

线程池拥堵时，任务内部再重试，只会雪上加霜。
重试要有限次、带退避、可中断，并且最好与业务线程池隔离。

7. 关键任务与普通任务分池

例如：

用户下单校验
营销推送
报表导出

绝对不应该共用一个线程池。
否则一个低优先级任务洪峰，就能把高优任务挤死。

一份实用排查清单

线上遇到线程池堆积时，可以按下面这个顺序走：

看线程池监控：activeCount、queueSize、拒绝次数
判断是提交过快还是任务变慢
抓 jstack 看工作线程阻塞点
检查下游依赖耗时和连接池
确认队列是否无界
检查是否存在任务嵌套提交、同步等待
评估是否需要限流、熔断、降级
最后再调 corePoolSize / maximumPoolSize / queueSize

如果顺序反过来，上来就加线程，很多时候只会把问题藏起来，等流量再高一点时一次性爆出来。

总结

线程池调优这件事，最忌讳“只会改数字”。

真正有效的思路应该是：

先分清楚是流量问题，还是执行问题
先看任务为什么慢，再看线程池怎么配
用有界队列和合理拒绝策略，让系统可控失败
线程池大小要和 CPU、下游依赖、连接池一起考虑
监控、线程命名、超时、隔离，是排查效率的关键基础设施

如果你只记住一句话，我建议记这个：

线程池不是用来无限兜底的，它只是系统处理能力的边界管理器。

调优的目标，不是把所有任务都吞进去；而是让系统在高压下依然可观测、可退化、可恢复。