背景与问题

线上接口突然“越来越慢”，通常不是最可怕的。真正可怕的是：前几分钟只是 RT 抖动，接着超时开始堆积，最后整个服务像被拖进泥潭，所有接口一起雪崩。

我踩过一次很典型的坑：某个聚合查询接口在高峰期调用下游服务较慢，我们为了“提升吞吐”临时把线程池参数调大，结果当天晚上直接把应用打趴了。

当时的现象很像这样：

接口平均响应时间从几十毫秒上涨到几秒
Tomcat 工作线程逐步占满
业务线程池队列暴涨
CPU 不一定高，但线程数飙升
GC 次数增加，内存占用抬高
下游一慢，上游全部跟着超时
重试叠加后，雪崩更快

这类问题的本质通常不是“线程不够”，而是：

线程池配置不合理 + 请求模型不匹配 + 缺少限流/超时/拒绝策略，最终把局部慢请求放大成系统性故障。

先给一个简化后的事故链路图。

flowchart TD
    A[流量上升] --> B[下游接口变慢]
    B --> C[业务线程执行时间变长]
    C --> D[线程池活跃线程打满]
    D --> E[任务进入队列堆积]
    E --> F[请求等待时间变长]
    F --> G[上游超时/重试]
    G --> H[更多请求涌入]
    H --> D
    E --> I[内存占用上升]
    I --> J[GC变频繁]
    J --> F

这篇文章我会按“现象复现 -> 定位路径 -> 原理解释 -> 修复方案 -> 最佳实践”的顺序带你走一遍，重点讲线程池为什么会把一个普通慢接口演变成接口雪崩。

现象复现

先复现一个常见错误配置：线程池核心线程数不大，但队列巨大，拒绝策略又没有明确兜底。

很多项目里都能看到类似代码：

ExecutorService executor = new ThreadPoolExecutor(
        16,
        64,
        60,
        TimeUnit.SECONDS,
        new LinkedBlockingQueue<>(10000),
        Executors.defaultThreadFactory(),
        new ThreadPoolExecutor.AbortPolicy()
);

这段配置看起来“很稳”，实际问题不少：

LinkedBlockingQueue 很大时，线程池会优先入队，而不是继续扩容到 maximumPoolSize
一旦下游变慢，任务会在队列中排队，延迟被静默放大
请求线程如果还在等待 Future.get()，Tomcat/NIO 工作线程也会被拖住
队列积压多了，内存压力上升，系统进入恶性循环

简单说：大队列不是缓冲区，而是延迟放大器。

核心原理

1. ThreadPoolExecutor 的工作规则

线程池接收任务时，核心流程可以概括为：

当前线程数 < corePoolSize：创建新线程执行
否则尝试放入阻塞队列
如果队列满了，且线程数 < maximumPoolSize：继续创建线程
如果线程数也到上限了：执行拒绝策略

很多人误以为把 maximumPoolSize 调大就能提升并发，但如果队列很大，任务早就进队列了，根本不会触发扩容。

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

2. 为什么会“雪崩”而不是“单点变慢”

线程池问题最容易被低估的一点，是它会跨层传染。

假设一次请求链路如下：

用户请求进来
Controller 调用 Service
Service 用线程池并发查 3 个下游
其中一个下游突然变慢

如果 Service 线程池排队严重：

业务任务拿不到执行线程
主请求线程还在等并发结果
Web 容器线程被占住
新请求进来继续积压
上游网关开始重试
数据库连接池、HTTP 连接池也被连带拖慢

于是故障不再局限于那个“慢下游”，而变成全站问题。

3. 几个关键参数的真实影响

`corePoolSize`

常驻线程数。适合稳定负载，但不是越大越好。线程过多会增加上下文切换。

`maximumPoolSize`

只有在队列满了之后才可能起作用。如果队列非常大，这个参数几乎形同虚设。

`workQueue`

最容易踩坑的地方：

过大：延迟堆积、内存膨胀、故障放大
过小：容易触发拒绝，需要业务兜底
无界队列：风险最高，尤其在慢调用场景

`RejectedExecutionHandler`

它决定系统“满载时怎么失败”。

常见策略：

AbortPolicy：直接抛异常，最容易感知问题
CallerRunsPolicy：由提交线程执行，可能反压调用方
DiscardPolicy：直接丢弃，不建议业务场景使用
DiscardOldestPolicy：丢掉最旧任务，适合部分弱一致场景

定位路径

线上排查时，我一般不先看代码，而是先看“系统像什么病”。

第一步：确认是不是线程池堵住了

先看几个监控指标：

线程池活跃线程数 activeCount
队列长度 queueSize
任务总数、完成数
接口 RT、超时数、错误率
JVM 线程总数
GC 次数与停顿时间

如果出现这种组合，基本就八九不离十：

activeCount 接近 maximumPoolSize 或长期满载
queueSize 持续上涨且不回落
请求 RT 越来越高
错误率后期突然抬头

第二步：抓线程栈

用 jstack 看线程状态非常关键。

常见现象：

一批业务线程卡在 HTTP 调用、DB 查询、远程 RPC
一批请求线程卡在 Future.get() / CompletableFuture.join()
还有一些线程在阻塞队列等待

示意关系如下：

sequenceDiagram
    participant U as 用户请求线程
    participant S as Service
    participant P as 业务线程池
    participant D as 下游服务

    U->>S: 请求接口
    S->>P: 提交异步任务
    P->>D: 调用下游
    D-->>P: 响应变慢
    S->>S: 等待 Future.get()
    Note over P: 活跃线程越来越多
    Note over P: 队列持续堆积
    U-->>U: 请求超时

第三步：判断是“线程太少”还是“任务太慢”

这个判断特别重要。

如果任务本身很快，只是瞬时流量高，可能是容量问题。

但如果任务执行时间显著变长，比如从 50ms 变成 2s，那盲目加线程等于：

给慢请求更多执行位
对下游施加更大压力
更快进入雪崩

线程池不是性能放大器，它只是并发调度工具。

实战代码（可运行）

下面用一个可运行示例模拟“错误线程池配置导致请求堆积”的情况，再给出改进版。

1. 错误示例：大队列掩盖问题

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

public class BadThreadPoolDemo {

    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                4,
                8,
                60,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(1000),
                new NamedThreadFactory("bad-pool"),
                new ThreadPoolExecutor.AbortPolicy()
        );

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

        // 模拟高并发请求涌入，每个任务都很慢
        for (int i = 0; i < 300; i++) {
            final int taskId = i;
            executor.submit(() -> {
                try {
                    // 模拟下游慢调用
                    Thread.sleep(3000);
                    System.out.println("task-" + taskId + " finished");
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });

            // 持续快速提交
            Thread.sleep(20);
        }

        executor.shutdown();
        executor.awaitTermination(10, TimeUnit.MINUTES);
        monitor.shutdown();
    }

    static class NamedThreadFactory implements ThreadFactory {
        private final String prefix;
        private final AtomicInteger index = new AtomicInteger(1);

        NamedThreadFactory(String prefix) {
            this.prefix = prefix;
        }

        @Override
        public Thread newThread(Runnable r) {
            return new Thread(r, prefix + "-" + index.getAndIncrement());
        }
    }
}

运行后你会看到什么

poolSize 长时间维持在 4
queue 很快堆积
maximumPoolSize=8 基本没机会发挥作用

原因就是：队列没满之前，不会继续扩容。

2. 改进示例：小队列 + 明确拒绝 + 超时控制

修复思路不是“无限加线程”，而是让系统在压力上来时能尽早反压、尽早失败、尽早止损。

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

public class BetterThreadPoolDemo {

    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                4,
                8,
                30,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(20),
                new NamedThreadFactory("better-pool"),
                new ThreadPoolExecutor.CallerRunsPolicy()
        );

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

        for (int i = 0; i < 100; i++) {
            final int taskId = i;
            try {
                CompletableFuture
                        .supplyAsync(() -> slowCall(taskId), executor)
                        .orTimeout(1500, TimeUnit.MILLISECONDS)
                        .exceptionally(ex -> {
                            System.out.println("task-" + taskId + " fallback: " + ex.getMessage());
                            return "fallback";
                        });
            } catch (Exception e) {
                System.out.println("submit failed, task-" + taskId + ", ex=" + e.getMessage());
            }

            Thread.sleep(20);
        }

        executor.shutdown();
        executor.awaitTermination(5, TimeUnit.MINUTES);
        monitor.shutdown();
    }

    private static String slowCall(int taskId) {
        try {
            Thread.sleep(3000);
            return "task-" + taskId + "-ok";
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return "interrupted";
        }
    }

    static class NamedThreadFactory implements ThreadFactory {
        private final String prefix;
        private final AtomicInteger index = new AtomicInteger(1);

        NamedThreadFactory(String prefix) {
            this.prefix = prefix;
        }

        @Override
        public Thread newThread(Runnable r) {
            return new Thread(r, prefix + "-" + index.getAndIncrement());
        }
    }
}

这个版本解决了什么

用 ArrayBlockingQueue 限制排队长度
队列小了，线程池更容易扩容到 maximumPoolSize
用 CallerRunsPolicy 给调用方施加反压
用 orTimeout 控制等待上限
出现异常时走降级逻辑，而不是一直耗着

3. 一个更贴近业务的封装示例

如果你在 Spring Boot 里做业务线程池，建议显式配置而不是直接 Executors.newFixedThreadPool()。

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.util.concurrent.*;

@Configuration
public class ThreadPoolConfig {

    @Bean("orderQueryExecutor")
    public ExecutorService orderQueryExecutor() {
        return new ThreadPoolExecutor(
                8,
                16,
                60,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(100),
                r -> {
                    Thread t = new Thread(r);
                    t.setName("order-query-" + t.getId());
                    return t;
                },
                new ThreadPoolExecutor.AbortPolicy()
        );
    }
}

业务代码中配合超时和降级：

import java.util.concurrent.*;

public class OrderService {

    private final ExecutorService executorService;

    public OrderService(ExecutorService executorService) {
        this.executorService = executorService;
    }

    public String queryOrderDetail() {
        CompletableFuture<String> userFuture = CompletableFuture
                .supplyAsync(this::queryUser, executorService)
                .completeOnTimeout("user-fallback", 300, TimeUnit.MILLISECONDS)
                .exceptionally(ex -> "user-fallback");

        CompletableFuture<String> couponFuture = CompletableFuture
                .supplyAsync(this::queryCoupon, executorService)
                .completeOnTimeout("coupon-fallback", 300, TimeUnit.MILLISECONDS)
                .exceptionally(ex -> "coupon-fallback");

        return userFuture.thenCombine(couponFuture, (u, c) -> u + " | " + c).join();
    }

    private String queryUser() {
        sleep(200);
        return "user-ok";
    }

    private String queryCoupon() {
        sleep(1000); // 模拟慢调用
        return "coupon-ok";
    }

    private void sleep(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

常见坑与排查

坑 1：使用 `Executors` 快捷工厂直接建线程池

这是老生常谈，但仍然很常见。

例如：

ExecutorService executor = Executors.newFixedThreadPool(20);

问题在于它底层通常使用无界队列，在慢任务场景下非常危险。任务不会被拒绝，只会不断堆积。

排查方式

看线程池实现是否是 ThreadPoolExecutor
打印队列类型与容量
关注是否是 LinkedBlockingQueue 默认无界

坑 2：把队列设得特别大，以为“更稳”

很多人会说：队列大一点，峰值可以扛住。

这句话只对短时突发、任务可快速消化的场景成立。
如果任务本身在变慢，大队列只是在延后爆炸时间。

判断边界

适合较大队列的场景：

异步削峰
任务可丢或可延后
消费速率稳定可预估

不适合大队列的场景：

同步接口链路
用户实时请求
下游服务有明显波动
请求超时成本高

坑 3：线程池和连接池容量不匹配

很典型的一种情况：

业务线程池 100
HTTP 连接池只有 20
DB 连接池只有 30

结果就是线程很多，但大部分在等连接，系统并不会更快，反而线程上下文切换更多。

flowchart TD
    A[业务线程池 100] --> B[HTTP连接池 20]
    A --> C[DB连接池 30]
    B --> D[线程阻塞等待连接]
    C --> D
    D --> E[接口RT升高]
    E --> F[请求堆积]

排查方式

同时查看：

线程池活跃数
HTTP 客户端连接池使用率
数据库连接池等待时间
下游接口超时数量

坑 4：没有设置超时，或者超时层层不一致

例如：

HTTP 客户端超时 5 秒
业务 Future 等待 10 秒
网关超时 3 秒

这会出现很尴尬的情况：
网关早超时了，但应用内线程还在继续干活，资源白白被占着。

建议

超时要分层设计，原则是：

外层超时应略大于内层
下游超时必须小于上游总超时
超时后要支持取消或降级

坑 5：拒绝策略选错了

比如在 Web 请求线程里使用 CallerRunsPolicy，如果提交线程本身就是处理请求的工作线程，那么高压下它会自己去执行任务，可能导致入口线程也被拖慢。

怎么选

强实时接口：优先快速失败，配合兜底
后台任务：可考虑 CallerRunsPolicy 做反压
可丢任务：定制拒绝策略 + 监控告警

止血方案

事故发生时，目标不是“优雅”，而是先别让系统继续恶化。

我一般按这个顺序止血：

1. 限流

先把入口流量压下来，避免线程池继续堆积。

可选方案：

网关限流
热点接口降级
租户/用户维度限流

2. 缩短超时

如果下游已经明显变慢，继续等只会拖垮更多线程。此时应临时收紧超时，让请求尽快失败。

3. 开启降级

非核心字段、非核心依赖，先返回默认值或缓存值。

4. 调整线程池参数，但别盲调

临时调整时，优先考虑：

减小队列长度
适度增加核心线程
明确拒绝策略
增加监控暴露

而不是简单把最大线程数翻倍。

5. 关闭重试风暴

如果调用链上有自动重试，必须确认是否会放大流量。
很多雪崩不是第一次超时造成的，而是第二次、第三次重试打出来的。

安全/性能最佳实践

这里的“安全”主要指系统稳定性安全，也包括避免资源耗尽。

1. 线程池参数要和任务类型匹配

CPU 密集型任务

建议线程数接近 CPU 核数：

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

IO 密集型任务

可适当高一些，但不要脱离下游容量、连接池容量和超时模型单独设置。

2. 为每类业务隔离线程池

不要一个大线程池承载所有任务。

例如：

查询类接口一个线程池
导出类任务一个线程池
回调通知一个线程池

这样某个慢业务不至于拖死全站。

3. 必须加监控指标

建议至少暴露：

poolSize
activeCount
queueSize
taskCount
completedTaskCount
largestPoolSize
rejectCount

如果能配合 Prometheus / Micrometer 就更好了。

4. 拒绝要可观测

不要只抛异常然后没人看见。
至少要记录：

哪个线程池
哪个业务
当前活跃线程数
队列长度
请求上下文

示例：

RejectedExecutionHandler handler = (r, executor) -> {
    System.err.printf(
            "Task rejected. poolSize=%d, active=%d, queue=%d%n",
            executor.getPoolSize(),
            executor.getActiveCount(),
            executor.getQueue().size()
    );
    throw new RejectedExecutionException("thread pool is exhausted");
};

5. 业务超时要早于用户超时

如果用户接口 SLA 是 1 秒，那内部聚合逻辑就不能每个下游都等 1 秒。
要做预算拆分，比如：

总超时：1000ms
下游 A：200ms
下游 B：300ms
下游 C：200ms
预留组装和网络抖动：300ms

6. 不要迷信异步并发

异步并发适合：

多个独立下游调用
能降级
有明确超时与隔离

不适合：

下游本身已很脆弱
请求必须强一致完成
没有监控和容量评估

7. 做容量压测，而不是靠经验拍脑袋

上线前至少验证这些问题：

峰值 QPS 下线程池是否持续扩容
队列是否可控
下游变慢 3 倍时是否还能退化运行
超时与拒绝是否按预期触发
错误率上升时是否会出现重试放大

总结

这次“线程池配置不当导致接口雪崩”的坑，核心教训其实很朴素：

线程池不是越大越好
大队列会隐藏问题、放大延迟
maximumPoolSize 不是随便设了就会生效
没有超时、隔离、降级，局部慢请求一定会扩散
真正的修复是反压与止损，不是盲目加线程

如果你现在要落地，我建议直接按这个检查清单过一遍：

是否还在用 Executors.newFixedThreadPool()？
队列是不是无界或过大？
是否有线程池监控和拒绝计数？
业务是否设置了明确超时？
下游变慢时是否能降级？
线程池、连接池、下游容量是否匹配？
是否做过高峰压测和慢依赖演练？

最后给一个边界判断：

如果你的任务是“用户实时请求链路上的慢 IO 调用”，那线程池的首要目标不是吞掉所有请求，而是用可控的方式保护系统活下来。

这也是我后来做并发设计时最看重的一点：宁可有限失败，也不要无限排队。

《Java 开发踩坑实录：排查并修复线程池配置不当导致的接口雪崩问题》

背景与问题

现象复现

核心原理

1. ThreadPoolExecutor 的工作规则

2. 为什么会“雪崩”而不是“单点变慢”

3. 几个关键参数的真实影响

corePoolSize

maximumPoolSize

workQueue

RejectedExecutionHandler

定位路径

第一步：确认是不是线程池堵住了

第二步：抓线程栈

第三步：判断是“线程太少”还是“任务太慢”

实战代码（可运行）

1. 错误示例：大队列掩盖问题

运行后你会看到什么

2. 改进示例：小队列 + 明确拒绝 + 超时控制

这个版本解决了什么

3. 一个更贴近业务的封装示例

常见坑与排查

坑 1：使用 Executors 快捷工厂直接建线程池

排查方式

坑 2：把队列设得特别大，以为“更稳”

判断边界

坑 3：线程池和连接池容量不匹配

排查方式

坑 4：没有设置超时，或者超时层层不一致

建议

坑 5：拒绝策略选错了

怎么选

止血方案

1. 限流

2. 缩短超时

3. 开启降级

4. 调整线程池参数，但别盲调

5. 关闭重试风暴

安全/性能最佳实践

1. 线程池参数要和任务类型匹配

CPU 密集型任务

IO 密集型任务

2. 为每类业务隔离线程池

3. 必须加监控指标

4. 拒绝要可观测

5. 业务超时要早于用户超时

6. 不要迷信异步并发

7. 做容量压测，而不是靠经验拍脑袋

总结

`corePoolSize`

`maximumPoolSize`

`workQueue`

`RejectedExecutionHandler`

坑 1：使用 `Executors` 快捷工厂直接建线程池