ThreadPoolExecutor是Java并发包中真正承担线程池调度工作的核心类，Executors工具类提供的newFixedThreadPool、newCachedThreadPool等方法本质上都是对它的封装。这种封装屏蔽了关键参数，比如固定线程池用的是无界队列，缓存线程池允许线程数无限增长，两者在生产环境高负载场景下都容易引发OOM。所以想真正掌控线程池的行为，直接使用ThreadPoolExecutor自定义各个参数是更稳妥的做法。
一、深入理解ThreadPoolExecutor的构造参数
自定义线程池的第一步是弄清楚七个构造参数各自的职责。完整构造方法如下：
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)corePoolSize表示核心线程数，即使线程空闲也会保留的数量；maximumPoolSize是线程池能创建的最大线程数；keepAliveTime和unit共同决定非核心线程空闲多久后被回收；workQueue是任务缓冲队列；threadFactory负责创建线程，可以用它给线程命名，方便排查问题；handler则是队列满了且线程达到上限时的拒绝策略。
这里有一个很多人容易搞混的地方：任务提交的顺序是先判断核心线程是否已满，未满则创建核心线程执行；核心线程满了之后，新任务先进队列排队；只有队列也满了，才会继续创建非核心线程，直到maximumPoolSize；此时如果还有任务进来，才触发拒绝策略。也就是说队列的优先级高于最大线程数，把队列设置得太大，最大线程数基本形同虚设，这是实际配置中最常见的误区之一。
拒绝策略有四种内置实现：AbortPolicy直接抛出RejectedExecutionException，适合需要快速暴露问题的场景；CallerRunsPolicy让提交任务的线程自己执行，能起到天然的限流和反压作用；DiscardPolicy静默丢弃任务，几乎没有使用价值；DiscardOldestPolicy丢弃队列头部最老的任务再重试提交。生产环境更常见的做法是实现RejectedExecutionHandler接口，把被拒绝的任务记录日志或写入降级存储，便于后续补偿。
二、线程数与队列的估算思路
线程数不是拍脑袋定的，需要结合任务类型分析。CPU密集型任务线程大部分时间在做计算，线程数设为CPU核心数加1即可，多出来的那个线程在偶发的缺页中断或线程暂停时能补上空缺。IO密集型任务线程经常阻塞在网络或磁盘等待上，可以适当放大，一个常用的经验公式是线程数等于CPU核心数乘以（1加平均等待时间与平均计算时间的比值）。
int cores = Runtime.getRuntime().availableProcessors(); // CPU密集型任务 int cpuThreads = cores + 1; // IO密集型任务，假设等待时间是计算时间的10倍 int ioThreads = cores * (1 + 10);
队列的选择同样有讲究。有界的LinkedBlockingQueue或ArrayBlockingQueue能限制堆积任务的数量，防止内存被无限占用；SynchronousQueue不存储任务，提交必须立即交给线程执行，适合任务执行快、追求低延迟的场景；PriorityBlockingQueue可以让重要的任务优先执行，但要注意任务必须实现Comparable接口，且相同优先级下的执行顺序不保证。
需要强调的是，任何公式都只是起点。线程数、队列容量最终要靠压测验证：观察线程池的活跃线程数、队列长度、任务执行耗时等指标，在吞吐量和响应时间之间找到平衡点，并且留出应对流量高峰的余量。
三、完整示例：一个可用于生产的自定义线程池
下面这段代码演示了如何组合各个参数，搭建一个带监控日志、自定义拒绝策略和优雅关闭的线程池。
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;
public class CustomThreadPool {
public static ThreadPoolExecutor create() {
// 自定义线程工厂，给线程编号便于排查问题
ThreadFactory factory = new ThreadFactory() {
private final AtomicInteger seq = new AtomicInteger(1);
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r, "order-pool-" + seq.getAndIncrement());
t.setDaemon(false);
return t;
}
};
// 自定义拒绝策略：记录日志，可在此接入降级逻辑
RejectedExecutionHandler handler = (r, executor) -> {
System.err.println("任务被拒绝，队列长度=" + executor.getQueue().size());
};
return new ThreadPoolExecutor(
8, // 核心线程数
16, // 最大线程数
60L, TimeUnit.SECONDS, // 非核心线程空闲回收时间
new LinkedBlockingQueue<>(1000), // 有界队列，容量1000
factory,
handler);
}
public static void main(String[] args) throws InterruptedException {
ThreadPoolExecutor pool = create();
for (int i = 0; i < 50; i++) {
final int taskId = i;
pool.submit(() -> {
System.out.println(Thread.currentThread().getName()
+ " 执行任务 " + taskId);
});
}
// 优雅关闭：不再接收新任务，等待已提交任务完成
pool.shutdown();
if (!pool.awaitTermination(30, TimeUnit.SECONDS)) {
// 超时后强制关闭
pool.shutdownNow();
}
}
}关闭环节值得展开说明。shutdown方法只是标记线程池为关闭状态，已提交的任务会继续执行完；shutdownNow会尝试中断正在执行的任务并返回尚未开始的任务列表。推荐的流程是先调用shutdown，再用awaitTermination等待一段时间，超时后再调用shutdownNow兜底。如果任务里包含IO操作，还要注意响应中断标志，否则中断信号可能被吞掉。
另一个实用技巧是让核心线程也允许超时回收，调用allowCoreThreadTimeOut(true)即可，适合流量有明显波峰波谷、低谷期不想空耗线程的业务。此外prestartAllCoreThreads()可以在服务启动时提前创建全部核心线程，避免流量刚进来时的创建开销。
四、动态调参与运行时监控
ThreadPoolExecutor提供了setCorePoolSize、setMaximumPoolSize、setKeepAliveTime等方法，支持运行时调整参数，配合配置中心就能做到不停机改配置。调整核心线程数时，如果新值小于旧值，多余的线程会在空闲后被终止；如果新值大于旧值且队列中有任务，会立即创建新线程来处理排队任务。
// 运行时动态调整线程池参数
pool.setMaximumPoolSize(32);
pool.setCorePoolSize(16);
// 获取监控指标，可上报到监控系统
System.out.println("活跃线程数: " + pool.getActiveCount());
System.out.println("已完成任务数: " + pool.getCompletedTaskCount());
System.out.println("当前队列长度: " + pool.getQueue().size());
System.out.println("历史最大线程数: " + pool.getLargestPoolSize());监控方面重点盯三个信号：活跃线程数长期等于最大线程数说明计算资源吃紧；队列长度持续增长说明消费速度跟不上生产速度，需要扩容或降级；任务执行耗时明显上升可能是下游依赖变慢。把这几个指标接入Prometheus之类的监控系统并配置告警，才能在线程池真正出问题前发现苗头。
最后提醒两个容易踩的坑。一是不要用Executors的便捷方法创建线程池，阿里巴巴Java开发手册明确禁止这条，原因前面已经分析过。二是提交任务时优先用submit而不是execute，因为submit返回Future，任务抛出的异常会被封装在Future中，调用get时能拿到异常信息；而execute执行的任务如果抛出未捕获异常，线程会直接终止，线程池再创建新线程补位，反复创建销毁会带来额外开销。给线程工厂里的线程设置UncaughtExceptionHandler也是稳妥的兜底手段。
ThreadPoolExecutorJava线程池并发编程修改时间：2026-09-08 05:48:30