背景与问题

线上接口偶发超时，最开始大家都怀疑是数据库慢、Redis 抖动，甚至怀疑网络波动。但排查几轮之后，真正的罪魁祸首却是一个“看起来很正常”的线程池配置。

这个坑我自己也踩过：业务为了“提升吞吐”，把原本串行的逻辑改成线程池并发执行。上线初期效果不错，请求响应时间明显下降。可一到高峰期，问题就来了：

接口 RT 从几百毫秒涨到十几秒
超时率飙升
堆内存持续上涨，Full GC 频繁
机器 CPU 不一定高，但服务已经开始“不回话”

最后定位发现：线程池使用方式不当，导致任务堆积、请求链路阻塞、队列对象撑爆内存。

这类问题非常典型，因为它不是“线程池不能用”，而是用了一个默认看似安全、实际上风险极大的配置。

典型线上现象

先把症状讲清楚，方便你对号入座：

接口超时集中发生在流量高峰
应用日志里没有明显异常，只是响应越来越慢
jstack 能看到大量线程在等待 Future.get()
jmap -histo 或 MAT 分析发现大量：
- java.util.concurrent.FutureTask
- java.util.concurrent.LinkedBlockingQueue$Node
- 业务请求对象、DTO、上下文对象被队列持有
Full GC 次数增加，但回收效果一般

如果你也看到这些信号，线程池基本就值得重点怀疑了。

现象复现

先看一个很常见、也很危险的写法。

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;

public class BadThreadPoolDemo {

    // 危险点：固定线程数 + 无界队列
    private static final ExecutorService EXECUTOR =
            Executors.newFixedThreadPool(8);

    public static void main(String[] args) throws Exception {
        for (int round = 0; round < 1000; round++) {
            handleRequest(round);
            if (round % 50 == 0) {
                System.out.println("submitted request batch: " + round);
            }
        }

        Thread.sleep(60000);
        EXECUTOR.shutdown();
    }

    private static void handleRequest(int requestId) throws Exception {
        List<Future<String>> futures = new ArrayList<>();

        // 模拟一个接口请求里并发拆 50 个子任务
        for (int i = 0; i < 50; i++) {
            int taskId = i;
            futures.add(EXECUTOR.submit(() -> {
                // 模拟慢调用
                Thread.sleep(1000);
                return "req=" + requestId + ", task=" + taskId;
            }));
        }

        // 主线程阻塞等待所有子任务
        for (Future<String> future : futures) {
            future.get(3, TimeUnit.SECONDS);
        }
    }
}

这段代码的问题不在语法，而在运行时行为：

每个请求拆成 50 个任务
线程池只有 8 个工作线程
newFixedThreadPool(8) 底层是 无界队列
当请求速度 > 线程处理速度时，任务无限堆积
每个任务又持有请求上下文、参数对象，最终推高内存
调用方还在 Future.get() 阻塞等待，接口超时就出现了

问题演化过程

flowchart TD
    A[请求流量上升] --> B[请求内拆分大量异步任务]
    B --> C[线程池核心线程耗尽]
    C --> D[任务进入无界队列持续堆积]
    D --> E[请求线程阻塞等待 Future.get]
    E --> F[接口RT升高/超时]
    D --> G[队列持有大量任务对象]
    G --> H[堆内存上涨/GC频繁]
    H --> I[系统雪崩风险增加]

核心原理

1. `Executors.newFixedThreadPool` 为什么容易埋雷

很多人以为固定线程池就是“最多只会有这么多线程，很稳”。但它真正的实现是：

核心线程数 = 最大线程数
工作队列 = LinkedBlockingQueue
默认容量 = Integer.MAX_VALUE

也就是说，线程数是固定了，但任务队列几乎无限大。

当任务处理不过来时，不会立刻拒绝，也不会扩容，而是继续往队列里塞。短期看起来系统没报错，长期就会变成：

队列越来越长
延迟越来越高
对象越积越多
内存越涨越快

这是最隐蔽的一类问题：不是“炸得快”，而是“拖着你慢慢死”。

2. 为什么接口会超时

接口超时往往不是线程池线程不够这么简单，而是下面这条链路：

sequenceDiagram
    participant Client as 调用方
    participant API as 接口线程
    participant Pool as 线程池
    participant Worker as 工作线程

    Client->>API: 发起请求
    API->>Pool: submit 多个子任务
    Pool-->>API: 返回 Future
    Worker->>Worker: 执行慢任务
    API->>Pool: future.get() 等待结果
    Note over Pool: 队列堆积，调度变慢
    Worker-->>API: 结果迟迟返回
    API-->>Client: 超时/慢响应

本质上是：请求线程把自己变成了“等待线程”。
一旦底层线程池堵住，请求线程也跟着卡住，Tomcat/Jetty/Netty 的业务处理线程会被进一步占满，最后放大成整体接口雪崩。

3. 为什么内存会飙升

线程池队列里排队的不是简单的数字，而是完整任务对象。一个排队任务常常会间接引用：

请求参数
用户信息
traceId / 上下文
大对象缓存
lambda 捕获的外部变量

所以你以为只是“排队几万个任务”，实际上可能是几万个完整请求上下文常驻堆内存。

最常见的内存链路是：

classDiagram
    class ThreadPoolExecutor
    class LinkedBlockingQueue
    class FutureTask
    class BizCallable
    class RequestContext

    ThreadPoolExecutor --> LinkedBlockingQueue
    LinkedBlockingQueue --> FutureTask
    FutureTask --> BizCallable
    BizCallable --> RequestContext

定位路径

遇到这种问题，我一般按这个顺序查，效率比较高。

第一步：看线程池配置

重点找这几类代码：

Executors.newFixedThreadPool(...)
Executors.newCachedThreadPool(...)
Executors.newSingleThreadExecutor(...)
new ThreadPoolExecutor(...)

尤其要警惕：

使用 Executors 工厂方法创建线程池
队列没有设置容量
没有自定义拒绝策略
请求线程里大量 future.get()

第二步：看 JVM 线程栈

使用：

jstack <pid>

重点关注：

大量线程阻塞在 FutureTask.get
工作线程在执行慢 IO / 外部调用
线程池线程名是否集中卡死

例如你可能看到：

"http-nio-8080-exec-42" waiting on condition
    at java.util.concurrent.FutureTask.get(FutureTask.java:...)
    at com.example.OrderService.query(OrderService.java:...)

这说明请求线程正在等异步结果，所谓“异步”其实并没有让链路更快。

第三步：看堆内存对象

使用：

jmap -histo:live <pid> | head -50

或者导出堆后用 MAT 分析。

重点看这些对象是否异常多：

FutureTask
LinkedBlockingQueue$Node
Runnable / Callable 实现类
业务 DTO、上下文对象

如果 LinkedBlockingQueue$Node 很多，基本就是任务积压了。

第四步：看监控指标

线程池问题不靠猜，最好直接看监控：

活跃线程数
队列长度
任务提交速率
任务完成速率
拒绝次数
平均执行时长
最大执行时长

如果没有这些指标，线上排查会特别痛苦。

实战代码（可运行）

下面给一个相对合理的修复版本，重点是：

显式创建 ThreadPoolExecutor
使用有界队列
设置拒绝策略
给异步任务设置超时
减少请求线程无意义阻塞
补充线程池监控信息

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

public class GoodThreadPoolDemo {

    private static final AtomicInteger THREAD_ID = new AtomicInteger(1);

    private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
            8,                         // corePoolSize
            16,                        // maximumPoolSize
            60L, TimeUnit.SECONDS,     // keepAliveTime
            new ArrayBlockingQueue<>(200), // 有界队列，避免无限堆积
            r -> {
                Thread t = new Thread(r);
                t.setName("biz-pool-" + THREAD_ID.getAndIncrement());
                return t;
            },
            new ThreadPoolExecutor.CallerRunsPolicy() // 让提交方感知压力
    );

    public static void main(String[] args) throws Exception {
        for (int i = 0; i < 30; i++) {
            int requestId = i;
            try {
                String result = handleRequest(requestId);
                System.out.println("request " + requestId + " result: " + result);
            } catch (Exception e) {
                System.out.println("request " + requestId + " failed: " + e.getMessage());
            }

            printStats();
        }

        EXECUTOR.shutdown();
        EXECUTOR.awaitTermination(1, TimeUnit.MINUTES);
    }

    private static String handleRequest(int requestId) throws Exception {
        List<CompletableFuture<String>> futures = new ArrayList<>();

        for (int i = 0; i < 10; i++) {
            int taskId = i;
            CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
                try {
                    // 模拟慢任务
                    Thread.sleep(300);
                    return "req=" + requestId + ", task=" + taskId;
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    throw new RuntimeException("task interrupted", e);
                }
            }, EXECUTOR).orTimeout(1, TimeUnit.SECONDS);

            futures.add(future);
        }

        CompletableFuture<Void> all = CompletableFuture.allOf(
                futures.toArray(new CompletableFuture[0])
        );

        try {
            all.get(2, TimeUnit.SECONDS);
        } catch (TimeoutException e) {
            throw new RuntimeException("request timeout");
        }

        int successCount = 0;
        for (CompletableFuture<String> future : futures) {
            try {
                future.join();
                successCount++;
            } catch (CompletionException e) {
                // 记录失败任务，按业务决定是否降级
            }
        }

        return "success tasks = " + successCount;
    }

    private static void printStats() {
        System.out.printf(
                "poolSize=%d, active=%d, queue=%d, completed=%d%n",
                EXECUTOR.getPoolSize(),
                EXECUTOR.getActiveCount(),
                EXECUTOR.getQueue().size(),
                EXECUTOR.getCompletedTaskCount()
        );
    }
}

修复点说明

这段代码不是“万能模板”，但能解决最核心的问题。

1. 有界队列

new ArrayBlockingQueue<>(200)

有界队列的意义不是让系统处理更多任务，而是明确容量边界。
如果处理不过来，就尽早暴露，而不是无限排队。

2. 合理拒绝策略

new ThreadPoolExecutor.CallerRunsPolicy()

它的效果是：线程池忙不过来时，由提交任务的线程自己执行任务。

好处：

对上游形成反压
不会悄悄无限堆积
能在压力大时自然“降速”

但边界也要清楚：

如果提交方是请求线程，可能拉长当前请求耗时
不适合特别重的任务

如果你的业务更适合快速失败，也可以用：

new ThreadPoolExecutor.AbortPolicy()

然后在上层统一兜底降级。

3. 显式超时控制

.orTimeout(1, TimeUnit.SECONDS)

线程池只是执行容器，不会自动帮你处理超时。
如果下游慢调用没有超时，任务就会一直占线程。

所以要做到两层超时：

任务本身超时
整个请求聚合超时

4. 不要盲目并发拆分

很多接口本身只有 3~5 个外部调用，却拆成几十个任务，这是典型过度设计。

经验上：

CPU 密集型任务：线程数接近 CPU 核数
IO 密集型任务：可以适当放大，但必须压测
单请求拆分任务数：越少越容易控住风险

常见坑与排查

坑 1：把 `Executors` 当成生产环境推荐方案

这是最常见的误区。

错误示例

ExecutorService executor = Executors.newFixedThreadPool(20);

问题：

默认无界队列
容量不可控
风险在线上高峰期集中爆发

建议

始终优先自己创建 ThreadPoolExecutor，把这些参数写明白：

核心线程数
最大线程数
队列容量
线程工厂
拒绝策略

坑 2：异步里套同步等待

比如：

Future<Result> f1 = executor.submit(() -> queryA());
Future<Result> f2 = executor.submit(() -> queryB());

Result r1 = f1.get();
Result r2 = f2.get();

表面是异步并发，实际上主线程还是同步阻塞。
如果任务池一堵，这里就会把接口线程也拖死。

排查要点

看是否大量使用 get() / join()
看是否在 Web 请求线程中等待全部结果
看是否可以部分返回、超时降级、异步回填

坑 3：线程池共用，互相干扰

例如：

查询接口任务
MQ 消费任务
报表导出任务

都丢进同一个线程池。

结果就是：一个慢任务高峰，拖垮全部业务。

建议

按业务类型隔离线程池：

IO 查询池
计算池
定时任务池
消息消费池

不要让慢任务污染核心请求链路。

坑 4：任务里做不可控的阻塞调用

比如：

没超时的 HTTP 调用
没超时的数据库查询
锁等待
长时间休眠

线程池再合理，也架不住任务本身不释放线程。

建议

所有下游调用都要配置：

连接超时
读取超时
总超时
熔断/降级策略

坑 5：线程池参数照抄网上模板

很多文章喜欢给出固定值，比如：

核心线程数 16
最大线程数 64
队列 1000

但这些值脱离业务没有意义。

正确思路

参数要结合：

机器 CPU 核数
请求 QPS
平均任务时长
峰值任务数
可接受超时比例
下游依赖能力

止血方案

如果线上已经出现接口超时和内存飙升，先别急着“大重构”，优先止血。

短期止血

限制流量
- 网关限流
- 热点接口降级
缩小单请求并发拆分数
- 从 50 降到 10，立竿见影
为慢调用补齐超时
临时切换成有界队列 + 拒绝策略
对非核心功能快速失败
必要时重启实例释放堆积任务
- 但这只是恢复手段，不是根治

中期修复

业务线程池隔离
建立线程池监控
按压测数据重设参数
优化下游慢调用
减少不必要的异步拆分

安全/性能最佳实践

1. 线程池一定要有边界

至少边界要体现在三个地方：

最大线程数
队列容量
任务超时

没有边界，问题只是迟早出现。

2. 为线程池命名

自定义线程工厂时，一定给线程起业务名：

t.setName("order-query-pool-" + id);

这样 jstack 一眼就能看出来是谁在堵。

3. 核心链路与非核心链路隔离

比如：

下单接口查询库存：核心链路
发通知、写审计日志：非核心链路

不能共用一个池。非核心任务最多失败重试，核心链路超时就是事故。

4. 监控要覆盖“线程池四件套”

建议至少监控：

activeCount
poolSize
queueSize
rejectCount

更进一步可以加：

任务耗时分布
超时次数
最大等待时长

5. 避免大对象进入异步任务闭包

例如：

executor.submit(() -> process(bigRequest));

如果 bigRequest 很大，任务排队时它就会一直被引用，增加堆压力。

更好的做法：

只传必要字段
提前提取轻量参数
避免把整个上下文对象塞进任务

6. 不要把线程池当成削峰无限缓冲区

线程池能削峰，但只能在容量明确、波峰可控的前提下削峰。
如果上游长期超出下游处理能力，再大的队列也只是延后崩溃时间。

一个实用的参数思考框架

如果你不知道线程池该怎么配，可以先按下面的方法估算：

明确任务类型：CPU 密集还是 IO 密集
估算平均耗时和峰值耗时
估算单请求会提交多少任务
估算峰值 QPS 下每秒新增任务数
用压测验证线程数和队列上限

一个简单判断：

如果任务平均 200ms，每秒提交 1000 个任务
系统每秒需要消费 1000 个任务
单线程每秒最多处理 5 个任务
理论上至少要约 200 个并行处理能力

如果你的线程池只有 16 个线程，那不管队列多大，都会积压。

所以线程池问题本质上是容量问题 + 阻塞问题 + 边界问题，不是单纯改个参数就完事。

总结

这次排障的核心结论可以浓缩成一句话：

线程池不是性能优化银弹，配置不当时，它会把“局部慢”放大成“全链路超时 + 内存飙升”。

真正的问题通常是这几项叠加：

使用了无界队列
请求内过度并发拆分
主线程同步等待异步结果
下游慢调用没有超时
缺少监控与容量边界

如果你想避开这个坑，我建议直接执行这几条：

生产环境别直接用 Executors 默认工厂
统一改成显式 ThreadPoolExecutor
队列必须有界
设置拒绝策略，让系统能感知压力
异步任务和请求聚合都要有超时
按业务隔离线程池
上线前做压测，盯线程池指标而不只是接口 RT

最后强调一个边界条件：
如果你的任务本质上是重 IO 阻塞、下游能力又不稳定，那么再怎么调线程池，也只是缓解，不是根治。真正的修复，还得回到业务模型本身，比如限流、降级、批处理、缓存、异步化解耦。

线程池该用，但一定要带着敬畏心去用。很多事故，真的只是因为一个“默认配置看起来没问题”。