Java 线程池核心参数有哪些？日常应该怎么使用？

面试回答

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

提交任务后，线程池先判断当前工作线程数是否小于核心线程数，是则创建线程执行；否则尝试将任务放入队列。队列已满时，如果线程数还没有达到最大线程数，就继续创建非核心线程；线程数达到最大值后仍无法接收任务，才执行拒绝策略。因此，最大线程数是否生效与队列是否有界密切相关。

日常使用时，应根据任务是 CPU 密集型还是 I/O 密集型划分独立线程池，明确核心线程数、最大线程数和有界队列，设置有业务含义的线程名，并根据业务选择可观测、可补偿的拒绝策略。同时监控活跃线程数、队列长度、拒绝次数、排队耗时和执行耗时，应用停止时进行优雅关闭。线程数和队列容量不能只靠固定公式决定，还要结合机器 CPU、任务等待与计算比例、下游容量及允许的业务延迟进行压测和调整。

一句话总结：

线程池用有限的线程和队列承接任务；日常配置的核心不是把参数设大，而是明确资源上限、过载行为和监控补偿机制。

一张图看懂

详细讲解

一、为什么使用线程池

如果每个任务都创建一个新线程，会带来以下问题：

• 创建和销毁线程需要消耗时间与内存；
• 线程数量缺少上限，突发流量可能耗尽系统资源；
• 大量线程会增加上下文切换和调度开销；
• 无法统一管理任务排队、拒绝、监控和关闭。

线程池的核心价值不是单纯复用线程，而是对并发资源进行治理：

控制线程数量
+ 缓冲暂时处理不了的任务
+ 定义系统过载时的行为
+ 统一监控和生命周期管理

二、ThreadPoolExecutor 的七个核心参数

常用构造方法如下：

public ThreadPoolExecutor(
        int corePoolSize,
        int maximumPoolSize,
        long keepAliveTime,
        TimeUnit unit,
        BlockingQueue<Runnable> workQueue,
        ThreadFactory threadFactory,
        RejectedExecutionHandler handler)

1. corePoolSize：核心线程数

corePoolSize 表示线程池希望长期保留的基本工作线程数量。

默认情况下，核心线程也不是在线程池创建时立即启动，而是在任务到来后按需创建。需要提前完成线程创建时，可以调用：

threadPool.prestartAllCoreThreads();

核心线程默认不会因为空闲而退出。调用以下方法后，核心线程也可以受空闲超时控制：

threadPool.allowCoreThreadTimeOut(true);

此时 keepAliveTime 必须大于零。

2. maximumPoolSize：最大线程数

maximumPoolSize 是线程池允许存在的最大工作线程数量，必须大于或等于核心线程数。

它并不是任务一多就立即生效。只有满足以下条件时，线程池才会创建超过核心数量的线程：

核心线程都在工作
+ workQueue 已满
+ 当前线程数小于 maximumPoolSize

如果使用不会被填满的无界队列，任务会持续进入队列，线程池通常不会扩展到 maximumPoolSize。

3. keepAliveTime：空闲线程存活时间

当工作线程数量超过 corePoolSize 时，多出来的线程如果在指定时间内没有获取到任务，就会被回收。

keepAliveTime 决定空闲等待时长，unit 决定它的时间单位：

60L, TimeUnit.SECONDS

它们共同表示空闲线程最多等待 60 秒。

该参数是在以下两者之间取舍：

• 设置较短：流量下降后能更快释放线程资源，但下一次突发流量需要重新创建线程；
• 设置较长：可以减少线程反复创建，但空闲线程会占用更多内存。

4. unit：时间单位

unit 是 keepAliveTime 的单位，常用值包括：

• TimeUnit.MILLISECONDS
• TimeUnit.SECONDS
• TimeUnit.MINUTES

把时间值和单位拆开传入，可以避免代码中出现含义不清的裸数字。

5. workQueue：任务队列

当核心线程都在工作时，新任务会先尝试进入 workQueue 等待，而不是立即创建非核心线程。

常见队列如下：

队列容量并非越大越好。大队列虽然能暂时降低拒绝次数，却可能带来：

• 任务排队时间不断增长；
• 内存占用上升；
• 故障被延迟暴露；
• 应用关闭时遗留大量未完成任务；
• 请求已经失去业务时效后仍在执行。

有界队列能够让系统在达到承载上限时尽早进入明确的过载处理流程。

6. threadFactory：线程工厂

threadFactory 负责创建工作线程，可以统一设置：

• 线程名称；
• 是否为守护线程；
• 线程优先级；
• 未捕获异常处理器。

线程名应体现业务用途，例如：

order-notify-1
order-notify-2

出现高 CPU、死锁或任务堆积时，有业务含义的线程名能显著降低线程栈排查成本。

7. handler：拒绝策略

当线程池没有运行，或者同时满足“线程数达到最大值、任务队列已满”时，新任务会被拒绝。

JDK 提供四种常用策略：

拒绝策略没有适用于所有业务的统一答案。核心交易任务通常不能静默丢弃，可以抛出异常后进入降级、补偿或持久化重试；允许采样的日志、指标任务才可能接受丢弃。

三、任务提交后的完整流程

调用：

threadPool.execute(task);

ThreadPoolExecutor 的处理流程可以概括为：

1. 当前工作线程数小于 corePoolSize
   → 创建核心工作线程执行任务

2. 当前工作线程数已达到 corePoolSize
   → 尝试将任务加入 workQueue

3. workQueue 已满，且工作线程数小于 maximumPoolSize
   → 创建非核心工作线程执行任务

4. workQueue 已满，且工作线程数已达到 maximumPoolSize
   → 执行拒绝策略

任务成功入队后，线程池还会再次检查运行状态。如果线程池在入队期间已经停止，会尝试移除该任务并拒绝；如果池中没有工作线程，则会补充一个工作线程负责消费队列。

这个二次检查避免了任务已经进入队列，却因为线程池状态变化或没有消费者而一直得不到执行。

四、队列与最大线程数如何相互影响

假设配置如下：

corePoolSize = 8
maximumPoolSize = 16
workQueue 容量 = 500

任务增长过程是：

前 8 个并发任务
→ 创建至 8 个核心线程

核心线程忙碌后的新任务
→ 最多 500 个进入队列

队列满后的新任务
→ 继续创建线程，最多扩展到 16 个

16 个线程都忙且队列仍满
→ 触发拒绝策略

如果把队列改成默认构造的 LinkedBlockingQueue，它的容量接近无界，任务通常只会继续排队，线程数量很难从 8 扩展到 16。

因此不能孤立地解释 maximumPoolSize，必须和 workQueue 一起分析。

五、线程数应该怎么估算

1. CPU 密集型任务

CPU 密集型任务的大部分时间都在执行计算，例如加密、压缩、图像处理和复杂规则计算。

可以把下面的数值作为初始估算：

线程数 ≈ CPU 核数 + 1

线程数明显超过 CPU 并行能力，通常只会增加上下文切换，并不会线性提升吞吐。

2. I/O 密集型任务

I/O 密集型任务会花较多时间等待数据库、网络、文件或远程服务，可以用以下公式进行初始估算：

线程数 ≈ CPU 核数 ×（1 + 平均等待时间 ÷ 平均计算时间）

例如任务平均计算 10 毫秒、等待下游 40 毫秒，机器有 8 个 CPU 核：

8 ×（1 + 40 ÷ 10）= 40

40 只能作为起始测试值，不能直接当作生产结论。真实上限还受以下因素约束：

• 数据库连接池只有多少连接；
• 下游接口允许多少并发；
• 单任务占用多少内存；
• 机器 CPU、内存和网络容量；
• 业务允许的超时和排队时长。

如果数据库连接池只有 20 个可用连接，把线程池配置成 200 个线程，往往只是让更多线程阻塞在等待连接上。

3. 队列容量怎么定

队列容量应结合四个维度：

1. 高峰任务到达速率；
2. 线程池稳定处理速率；
3. 业务允许的最大排队时间；
4. 单个排队任务占用的内存。

假设高峰期每秒比稳定处理能力多出 100 个任务，业务最多允许这种峰值持续 3 秒，可以从约 300 个队列容量开始评估：

暂时积压量
≈（任务到达速率－稳定处理速率）× 峰值持续时间

还必须验证队列排满时的内存占用和最老任务等待时间。容量评估的目标不是永不拒绝，而是在允许的延迟和资源范围内吸收短时突发。

六、日常推荐写法

下面是一个边界清晰的业务线程池示例：

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.RejectedExecutionException;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public final class OrderAsyncExecutor {

    private static final AtomicInteger THREAD_ID = new AtomicInteger();

    private static final ThreadFactory THREAD_FACTORY = task -> {
        Thread thread = new Thread(
                task,
                "order-async-" + THREAD_ID.incrementAndGet()
        );
        thread.setUncaughtExceptionHandler((currentThread, error) ->
                System.err.println(
                        currentThread.getName() + ": " + error.getMessage()
                )
        );
        return thread;
    };

    private static final ThreadPoolExecutor EXECUTOR =
            new ThreadPoolExecutor(
                    8,
                    16,
                    60L,
                    TimeUnit.SECONDS,
                    new ArrayBlockingQueue<>(500),
                    THREAD_FACTORY,
                    new ThreadPoolExecutor.AbortPolicy()
            );

    private OrderAsyncExecutor() {
    }

    public static void execute(Runnable task) {
        try {
            EXECUTOR.execute(task);
        } catch (RejectedExecutionException exception) {
            // 根据业务接入告警、降级、持久化重试或补偿流程
            throw exception;
        }
    }

    public static void shutdown() {
        EXECUTOR.shutdown();
        try {
            if (!EXECUTOR.awaitTermination(30, TimeUnit.SECONDS)) {
                EXECUTOR.shutdownNow();
            }
        } catch (InterruptedException exception) {
            EXECUTOR.shutdownNow();
            Thread.currentThread().interrupt();
        }
    }
}

这个示例体现了几个基本原则：

• 线程池被复用，而不是每次请求临时创建；
• 核心线程、最大线程和队列容量都有明确上限；
• 线程名能够定位到业务；
• 拒绝不会被静默忽略；
• 停止应用时先等待已有任务完成，超时后再中断；
• 捕获 InterruptedException 后恢复当前线程的中断状态。

实际业务应把告警、指标和补偿接入统一基础设施，而不是只输出错误信息。

七、为什么不建议盲目使用 Executors 工厂方法

Executors 提供的工厂方法使用方便，但部分方法隐藏了重要的资源边界。

1. newFixedThreadPool 和 newSingleThreadExecutor

它们使用共享的无界队列。线程数有上限，但任务积压量缺少实际可用的业务上限：

生产速度长期大于处理速度
→ 队列持续增长
→ 排队延迟和内存占用持续上升

2. newCachedThreadPool

它使用 SynchronousQueue 直接移交任务，并允许按需创建大量线程。任务持续阻塞时，线程数量可能快速增长。

因此在资源敏感的服务端业务中，显式创建 ThreadPoolExecutor 通常更容易表达：

• 最多允许多少并发线程；
• 最多允许积压多少任务；
• 超出能力后如何处理。

这并不表示所有 Executors 方法都不能使用，而是需要先理解其内部参数和运行边界。

八、execute 和 submit 有什么区别

execute

threadPool.execute(task);

• 只接收 Runnable；
• 没有任务结果；
• 任务抛出的未捕获异常可以到达线程的未捕获异常处理流程。

submit

Future<Result> future = threadPool.submit(callable);

• 可以接收 Runnable 或 Callable；
• 返回 Future，可以获取结果、等待完成或取消任务；
• 任务异常会被封装在 Future 中，调用 get() 时以 ExecutionException 抛出。

如果调用 submit() 后既不保存 Future，也不检查任务结果，异常很容易被忽略。此时应在任务内部记录异常，或统一检查 Future。

九、不同类型的任务为什么要隔离线程池

把所有异步任务放进同一个线程池，会产生资源相互影响。

例如：

慢第三方接口占满全部线程
→ 订单本地计算任务无法执行
→ 两类本来无关的业务一起超时

可以按资源特征或故障域拆分：

• CPU 计算任务使用计算线程池；
• 数据库写入任务使用受连接池容量约束的线程池；
• 慢第三方接口使用独立线程池；
• 核心交易和非核心通知分开；
• 不同下游服务使用独立的并发上限。

线程池隔离不是越细越好。线程池过多会增加线程总数和管理成本，应围绕“是否共享同一个资源上限、是否应该相互影响”来划分。

十、需要监控哪些指标

线程池上线后至少应监控：

常见告警信号包括：

• 活跃线程数长时间接近最大线程数；
• 队列长度持续上升而不是短时波动；
• 排队耗时接近业务超时时间；
• 拒绝次数持续增长；
• 已完成任务数停止增长；
• 下游连接池和线程池同时耗尽。

只监控线程数量不够。很多线程池故障的第一表现不是线程数异常，而是队列等待时间持续增加。

十一、如何优雅关闭线程池

shutdown() 和 shutdownNow() 的语义不同：

shutdown()
→ 不再接收新任务
→ 继续执行已提交任务

shutdownNow()
→ 尝试中断正在执行的任务
→ 返回队列中尚未开始的任务

常见关闭流程是：

调用 shutdown()
→ 在限定时间内 awaitTermination()
→ 超时后调用 shutdownNow()
→ 再等待一次并记录未完成任务

任务代码还必须正确响应中断。阻塞调用收到 InterruptedException 后，不应随意吞掉中断状态。

十二、常见误区

1. 最大线程数越大，处理能力越强

线程数量超过 CPU、数据库连接池或下游承载能力后，只会增加竞争、等待和上下文切换。

2. 队列越大，越不容易出问题

大队列可能只是把拒绝转化为更长的延迟和更高的内存风险。

3. 使用 CallerRunsPolicy 就解决了限流

CallerRunsPolicy 会让提交线程执行任务，从而减慢生产者，但它不是严格的 QPS 限流器。调用线程可能是 Web 请求线程、消息消费线程或定时调度线程，执行任务会影响这些上游组件的延迟和可用性。

4. ThreadPoolExecutor 线程安全，任务就一定线程安全

线程池只负责安全调度任务，不会自动保护任务访问的共享对象。任务内部仍要正确使用锁、原子类、并发容器或不可变对象。

5. submit 后没有异常日志，就表示任务成功

submit() 会把异常保存到 Future。如果从未调用 get() 或没有统一异常处理，失败可能没有明显日志。

6. 线程池能够无限吸收突发流量

线程池只能在有限线程和有限队列范围内吸收波动。持续过载必须通过限流、降级、削峰、扩容或优化下游能力解决。

十三、日常使用检查清单

• 是否按照任务类型和下游资源进行合理隔离；
• 是否明确设置线程数和有界队列；
• 线程数量是否与 CPU、连接池和下游容量匹配；
• 是否设置可识别的线程名称；
• 拒绝策略是否符合业务语义；
• 被拒绝任务是否有告警、降级或补偿；
• 是否记录排队耗时、执行耗时和拒绝次数；
• submit() 返回的 Future 是否被正确处理；
• 任务是否支持中断，是否会泄漏 ThreadLocal 上下文；
• 应用关闭时是否执行线程池优雅停止。

参考资料

• ThreadPoolExecutor Java 8 API
• Executors Java 8 API
• RejectedExecutionHandler Java 8 API