ThreadPoolExecutor 是 Java 中高度定制化的线程池实现，核心在于正确配置七个构造参数，包括 corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory 和 handler，其运行逻辑需注意任务提交时的线程创建与队列填充顺序。
在 Java 中，ThreadPoolExecutor 是 java.util.concurrent 包提供的可高度定制的线程池实现。它比 Executors 工具类创建的线程池更透明、更可控，适合对并发行为有明确要求的场景（比如控制资源占用、避免 OOM、精细化任务调度）。
理解核心构造参数
自定义线程池的关键在于正确设置七个构造参数，最常用的是带全部参数的构造函数：
public ThreadPoolExecutor(
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
各参数含义如下：
-
corePoolSize：核心线程数。即使空闲也不会被回收（除非设置了
allowCoreThreadTimeOut(true)） - maximumPoolSize：最大线程数。仅当队列满且当前线程数
- keepAliveTime + unit：非核心线程空闲后的存活时间。设为 0 表示立即终止
-
workQueue：任务等待队列。常用
LinkedBlockingQueue（无界）、ArrayBlockingQueue（有界）、SynchronousQueue（不存储，直接移交） - threadFactory：用于创建新线程，建议自定义以统一命名、设置守护状态或优先级
-
handler：拒绝策略。默认是
AbortPolicy（抛RejectedExecutionException），也可选CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy
推荐的自定义方式（带命名与拒绝处理）
避免使用 Executors.newFixedThreadPool() 等快捷方法，它们隐藏了关键配置，且部分使用无界队列易引发内存问题。以下是一个生产可用的示例：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
// 自定义线程工厂：统一命名，非守护线程
ThreadFactory namedFactory = r -> {
Thread t = new Thread(r, "biz-task-pool-" + System.currentTimeMillis());
t.setDaemon(false);
return t;
};
// 有界队列 + 拒绝时由调用线程执行（降级兜底）
BlockingQueue<Runnable> queue = new ArrayBlockingQueue<>(100);
RejectedExecutionHandler policy = new ThreadPoolExecutor.CallerRunsPolicy();
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // core: 4 个常驻线程
16, // max: 最多扩到 16 个
60L, // keep-alive: 非核心线程空闲 60 秒后回收
TimeUnit.SECONDS,
queue,
namedFactory,
policy
);
注意：corePoolSize 和 maximumPoolSize 的差值决定了“弹性扩容”能力；队列容量应结合业务吞吐与失败容忍度设定，不宜过大。
关键行为与常见陷阱
ThreadPoolExecutor 的运行逻辑并不完全直观，需特别注意：
- 提交任务时，若当前线程数
- 只有当线程数 ≥ corePoolSize 且队列未满时，任务才会入队；队列满 + 线程数
- 调用
prestartAllCoreThreads()可提前启动所有核心线程（适合预热场景） - 不要忘记在应用关闭时调用
shutdown()或shutdownNow()，否则 JVM 可能无法退出 - 慎用无界队列（如
LinkedBlockingQueue默认容量为Integer.MAX_VALUE），高并发+慢消费极易导致 OOM
补充：监控与调优建议
可通过以下方法获取运行时指标，辅助调优：
-
getActiveCount()：当前正在执行任务的线程数 -
getPoolSize()：当前总线程数（含空闲） -
getCompletedTaskCount()：已完成任务总数 -
getQueue().size()：等待队列中的任务数
建议将这些指标接入 Prometheus 或日志埋点，在压测或上线后观察：队列是否长期积压？是否频繁触发拒绝？线程数是否持续逼近 maximum？据此调整 core/max/queue 三者配比。
