ThreadPoolExecutor 就是 Java 并发界的金牌包工头手里攥着一批现成的工人核心线程门口还蹲着一群临时工非核心线程来活了不用现招工新建线程直接派活活少了还能裁人把线程的创建、销毁、调度玩出花来 —— 彻底解决 “每次来活都现拉人干完活就散伙” 的资源浪费问题主打一个高效、省钱、不内卷老板喜欢。这包工头够狠因为它解决了线程的两大致命问题 ——线程创建 / 销毁的高昂开销系统创建线程要分配栈空间、寄存器等资源销毁也要回收反复操作极耗性能线程数量失控的并发灾难线程过多会导致 CPU 上下文切换频繁内存占用飙升系统直接卡死)主打一个资源复用、高效调度、稳控并发让多线程任务执行告别混乱全程井井有条。就像工地不能来 1 个小活招 100 个工人也不能永远养着 100 个工人干闲活ThreadPoolExecutor 就是那个能精准控人数、巧调度的包工头。一、调度管家的核心工作规则7 大核心参数ThreadPoolExecutor 的核心就是 7 个参数相当于包工头的招工规则、场地大小、临时工制度、辞退规则少一个都玩不转。// 核心构造方法7个参数一个不能少 public ThreadPoolExecutor( int corePoolSize, // 核心线程数正式工数量 int maximumPoolSize, // 最大线程数工地最多能容下的工人总数正式工临时工 long keepAliveTime, // 空闲时间临时工没活干的超时时间到点就裁狠吧 TimeUnit unit, // 时间单位秒/毫秒配合空闲时间用 BlockingQueueRunnable workQueue, // 任务队列待搬的砖堆正式工忙不过来就堆这 ThreadFactory threadFactory, // 线程工厂招工的人给工人起名字、定规矩 RejectedExecutionHandler handler // 拒绝策略砖太多堆不下、工人也满了怎么处理新砖 )当然这老板有多少个固定员工多少个外包这根据自己的业务都有定数你不能一心想成为那个包工头并为此奋斗不息把一个线程当3个线程用还经常一言堂、动不动就搞压榨机机器都干冒烟了这是不是很过分1. corePoolSize正式工铁饭碗不辞退核心固定线程资源核心正式工只要线程池处于运行状态哪怕没任务执行也会一直保留除非手动开启allowCoreThreadTimeOut来活了新任务到来先看正式工有没有闲着的有就直接派活正式工全忙了才会把活堆到任务队列而不是立马招临时工。比如corePoolSize5就是固定养 5 个正式工常年在岗随叫随到。2. maximumPoolSize线程池最大规模工地最大容纳人数能调度的线程资源天花板包工头的招工上限一旦任务队列堆满了正式工全在忙才会开始招临时工直到工人总数达到这个数该数值必须≥corePoolSize不然临时工没名额否则临时线程没有创建空间临时线程只是 “应急人手”没活干到点就被裁任务量下降后会被及时回收不会长期占用资源。比如corePoolSize5maximumPoolSize10就是管家最多可创建 5 个临时线程线程池内总线程数绝不超过 10。3. keepAliveTime unit临时线程的空闲回收时限临时工的下岗倒计时只要临时工没活干的时间达到这个值直接裁掉节省工地成本对临时线程的资源回收规则如果临时线程空闲无任务的时间达到这个值直接回收该线程释放系统资源做到 “人走茶凉不浪费资源”这事放到人身上、充满了无奈努力成为核心现在这个大环境自己才能保住自己再说有本事在哪也不怕共勉吧大家若调用executor.allowCoreThreadTimeOut(true)正式工没活干也会被裁相当于包工头连正式工都敢开主打一个极致省钱、不要脸。比如keepAliveTime60unitTimeUnit.SECONDS就是临时工闲 1 分钟就卷铺盖走人。4. workQueue任务队列待搬的砖堆正式工全忙了之后新任务不会立马招临时工而是先堆到任务队列里等正式工干完活再从队列里取活干。这是线程池的核心缓冲机制避免一点活就招临时工频繁招工裁人。常用的队列就 3 种各有脾气ArrayBlockingQueue有界数组队列固定大小的砖堆满了就不能堆了适合控制任务量避免内存溢出LinkedBlockingQueue无界链表队列无限大的砖堆能一直堆活缺点是活太多会把内存撑爆此时 maximumPoolSize 相当于失效永远招不到临时工SynchronousQueue同步队列没地方堆砖急性子、等不来一点来活了必须立马有工人干没工人就招临时工直到达到最大数适合任务需要快速处理的场景。5. threadFactory线程工厂招工的 HR负责创建新线程相当于工地的 HR给工人线程起名字、设置优先级、是否为守护线程等。JDK 默认提供Executors.defaultThreadFactory()但实际开发建议自定义 —— 比如给线程起名字pool-1-thread-1方便排查问题总不能出问题了连哪个工人干的活都不知道import java.util.concurrent.ThreadFactory; import java.util.concurrent.atomic.AtomicInteger; public class CustomThreadFactory implements ThreadFactory { private final String namePrefix; private final AtomicInteger threadNumber new AtomicInteger(1); public CustomThreadFactory(String poolName) { this.namePrefix poolName -thread-; } Override public Thread newThread(Runnable r) { Thread t new Thread(r); // 关键设置可读性强的线程名方便出问题时 grep 日志 t.setName(namePrefix threadNumber.getAndIncrement()); // 设置为非守护线程确保任务能执行完 t.setDaemon(false); // 设置优先级 (可选) t.setPriority(Thread.NORM_PRIORITY); return t; } }6. handler拒绝策略砖太多了装不下咋处理当任务队列堆满 工人总数达到最大值新任务再来包工头就没辙了只能执行拒绝策略这是线程池的最后一道防线避免任务无限积压搞崩系统。JDK 默认提供 4 种拒绝策略全是狠角色按需选择AbortPolicy默认直接抛异常RejectedExecutionException主打一个 “老子不干了报错给你看”CallerRunsPolicy让提交任务的线程自己干比如主线程提交任务被拒绝主线程就自己执行主打一个 “谁派活谁干别难为我”DiscardPolicy直接丢弃新任务悄无声息主打一个 “眼不见心不烦丢了也不告诉你”DiscardOldestPolicy丢弃任务队列里最老的任务把位置让给新任务主打一个 “喜新厌旧留新丢旧”。import java.util.concurrent.RejectedExecutionHandler; import java.util.concurrent.ThreadPoolExecutor; import lombok.extern.slf4j.Slf4j; Slf4j public class CustomRejectedHandler implements RejectedExecutionHandler { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 1. 记录详细日志 (核心数、最大数、队列大小) log.error(线程池已满任务被拒绝。核心数{}, 最大数{}, 队列大小{}, 活跃线程{}, executor.getCorePoolSize(), executor.getMaximumPoolSize(), executor.getQueue().size(), executor.getActiveCount()); // 2. 业务降级策略 (三选一) // 策略 A: 丢弃并通知 (静默失败适用于非核心业务) // return; // 策略 B: 让调用者自己跑 (适用于实时性要求高不能丢失的任务) // r.run(); // 策略 C: 抛出自定义业务异常 (适用于核心业务需前端感知) throw new RuntimeException(系统繁忙请稍后重试 [CustomReject]); // *生产环境最佳实践*: 这里通常会写入 MQ 或 Redis后续异步补偿 // mqProducer.sendRetryTask(r); } }实际开发中默认的 AbortPolicy 慎用容易抛异常崩业务一般自定义拒绝策略 —— 咱一般把任务丢到消息队列MQ里后续慢慢处理主打一个 “留后路”来一个标准线程池吧import java.util.concurrent.*; public class ProductionThreadPool { // 单例线程池实例 private static final ThreadPoolExecutor EXECUTOR; static { int cpuCores Runtime.getRuntime().availableProcessors(); EXECUTOR new ThreadPoolExecutor( // 1. 核心线程数 (IO 密集型) cpuCores * 2, // 2. 最大线程数 cpuCores * 4, // 3. 空闲存活时间 60L, TimeUnit.SECONDS, // 4. 有界队列 (防止 OOM) new ArrayBlockingQueue(1000), // 5. 自定义线程工厂 (好名字) new CustomThreadFactory(BizOrderPool), // 6. 自定义拒绝策略 (留后路) new CustomRejectedHandler() ); // 7. 允许核心线程超时回收 (极致省钱模式可选) // EXECUTOR.allowCoreThreadTimeOut(true); } /** * 提交任务 */ public static void execute(Runnable task) { EXECUTOR.execute(task); } /** * 提交带返回值任务 */ public static T FutureT submit(CallableT task) { return EXECUTOR.submit(task); } /** * 【关键】打印监控指标 (对接 Prometheus 或定时日志) */ public static void printMetrics() { System.out.println( 线程池监控指标 ); System.out.println(核心线程数: EXECUTOR.getCorePoolSize()); System.out.println(当前线程数: EXECUTOR.getPoolSize()); System.out.println(最大线程数: EXECUTOR.getMaximumPoolSize()); System.out.println(活跃线程数: EXECUTOR.getActiveCount()); System.out.println(队列等待任务: EXECUTOR.getQueue().size()); System.out.println(队列剩余容量: (1000 - EXECUTOR.getQueue().size())); System.out.println(已完成任务: EXECUTOR.getCompletedTaskCount()); System.out.println(总任务数: EXECUTOR.getTaskCount()); System.out.println(); } /** * 优雅关闭 */ public static void shutdown() { EXECUTOR.shutdown(); try { if (!EXECUTOR.awaitTermination(60, TimeUnit.SECONDS)) { EXECUTOR.shutdownNow(); } } catch (InterruptedException e) { EXECUTOR.shutdownNow(); Thread.currentThread().interrupt(); } } // 测试入口 public static void main(String[] args) throws InterruptedException { // 提交 10 个任务 for (int i 0; i 10; i) { execute(() - { try { Thread.sleep(2000); } catch (Exception e) {} System.out.println(执行任务 by: Thread.currentThread().getName()); }); } // 等待一秒看监控 Thread.sleep(1000); printMetrics(); shutdown(); } }二、包工头的派活流程一步都不能乱包工头派活的逻辑特别简单就5 步按顺序来绝不乱搞说完大家都去当包工头哦来活提交任务→ 看正式工是否空闲 → 闲则派活忙则堆队列 → 队列满了则招临时工 → 临时工招满则拒绝线程池刚创建正式工还没启动懒加载第一次来活才创建正式工提交任务判断核心线程数是否达到 corePoolSize没达到创建新的正式工执行任务达到了走下一步判断任务队列是否满没满把任务加入队列满了走下一步判断工人总数是否达到 maximumPoolSize没达到创建临时工执行任务达到了走下一步执行拒绝策略处理新任务。划重点先核心线程再任务队列最后临时工这个顺序是线程池的灵魂别搞反了注意corePoolSize5workQueue 是无界队列那永远不会招临时工因为队列能一直堆活maximumPoolSize 就成了摆设。三、线程池的核心状态包工头的工地运营模式ThreadPoolExecutor 内部用一个32 位的 int 变量 ctl做状态 线程数的双重管理和 ReentrantReadWriteLock 的 state 位拆分异曲同工高 3 位表示线程池状态低 29 位表示当前工作线程数。RUNNING运行中包工头正常营业能接活能派活默认状态SHUTDOWN关闭中包工头不接新活了但会把队列里的活干完工人干完活再下班STOP强制停止包工头不接新活也不处理队列里的活直接让所有工人停手下班打断正在执行的任务TIDYING整理中所有工人都下班了任务也全处理完了线程池进入整理状态准备收尾TERMINATED已终止整理工作完成线程池彻底凉凉无法再使用。状态之间是单向切换的不能回滚比如 RUNNING 能切到 SHUTDOWN/STOP但 STOP 不能切回 RUNNING就像工地关了就不能再开除非重新建一个。触发状态切换的核心方法shutdown()温柔关闭对应 SHUTDOWN 状态不杀工人干完活再走shutdownNow()暴力关闭对应 STOP 状态直接杀工人中断任务awaitTermination()等待线程池进入 TERMINATED 状态相当于等工地彻底清场。四、为啥不用 Executors 创建线程池包工头的坑要避开DK 给了一个工具类Executors能快速创建线程池比如Executors.newFixedThreadPool()、Executors.newCachedThreadPool()但阿里开发手册明令禁止使用原因就一个底层参数写死容易搞崩系统相当于包工头的规则被硬编码遇到特殊情况直接翻车。newFixedThreadPool(n)核心线程数 最大线程数 n使用无界队列 LinkedBlockingQueue→ 坑任务无限积压直接撑爆内存OOMnewCachedThreadPool()核心线程数 0最大线程数 Integer.MAX_VALUE约 21 亿使用 SynchronousQueue→ 坑来活就招临时工工人数量直接失控CPU 被占满newSingleThreadExecutor()单线程无界队列→ 坑和 FixedThreadPool 一样任务积压导致 OOM。结论手动创建 ThreadPoolExecutor自定义 7 个核心参数根据业务场景调整核心线程数、队列大小、拒绝策略这才是并发开发的正确姿势。五、实战技巧包工头的最优管理方案光懂原理不够实际开发中把线程池用好才是真本事分享几个金牌包工头的运营技巧全是干货1. 核心线程数怎么配别拍脑袋看业务核心线程数是线程池的核心配少了任务积压配多了线程竞争一般分两种场景CPU 密集型任务比如计算、排序核心线程数 CPU 核心数 1因为 CPU 核心数是硬件上限多了线程会抢 CPU上下文切换开销大1 是为了防止某个线程阻塞导致 CPU 空闲IO 密集型任务比如数据库查询、网络请求核心线程数 CPU 核心数 ×2因为 IO 操作时线程会空闲多配点线程能充分利用 CPU也可以按CPU 核心数 /(1 - 阻塞系数)计算阻塞系数一般 0.8~0.9。实用小技巧用Runtime.getRuntime().availableProcessors()获取当前机器的 CPU 核心数动态配置避免硬编码。2. 任务队列用有界的别用无界的无论如何都要使用ArrayBlockingQueue这类有界队列设置合理的队列大小比如 1000原因无界队列会导致任务无限积压最终 OOM有界队列能配合最大线程数触发临时工招聘和拒绝策略形成 “缓冲 - 限流 - 拒绝” 的完整机制。3. 自定义线程工厂给线程起名字默认的线程名字是pool-1-thread-1如果项目中有多个线程池排查问题时根本分不清是哪个线程池的线程出了问题。ThreadFactory customFactory new ThreadFactory() { private final AtomicInteger count new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread thread new Thread(r); thread.setName(biz-pool-thread- count.getAndIncrement()); // 业务相关的名字 thread.setDaemon(false); // 非守护线程避免被JVM随意杀死 return thread; } };4. 自定义拒绝策略别直接抛异常默认的 AbortPolicy 直接抛异常会导致业务报错实际开发中建议自定义拒绝策略比如把任务写入 MQ/Redis后续消费重试记录日志 告警通知开发人员处理降级返回给用户友好提示。RejectedExecutionHandler customHandler (r, executor) - { log.error(线程池已满核心数{}最大数{}队列大小{}任务被拒绝, executor.getCorePoolSize(), executor.getMaximumPoolSize(), executor.getQueue().size()); throw new CustomBizException(系统繁忙请稍后再试); };5. 监控线程池别当甩手掌柜线程池用起来后必须加监控不然出问题了都不知道核心监控指标核心线程数、当前工作线程数、最大线程数任务队列的已排队数、剩余容量已完成任务数、被拒绝的任务数线程池的运行状态。JDK 提供了线程池的获取方法直接用就行getCorePoolSize()、getActiveCount()、getQueue().size()、getRejectedExecutionCount()等把这些指标暴露到 Prometheus/Grafana或打印到日志实时监控。6. 线程池用完要关闭别内存泄漏线程池的核心线程是常驻的若线程池是局部变量不用了不关闭会导致核心线程一直占用资源内存泄漏若线程池是全局单例比如项目启动时创建一直用到项目关闭则不用手动关闭项目停止时会自动销毁。executor.shutdown(); // 温柔关闭不接新活干完队列里的活 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { executor.shutdownNow(); // 60秒还没干完暴力关闭 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { log.error(线程池关闭失败); } }六、最后总结ThreadPoolExecutor 的核心价值ThreadPoolExecutor 本质是线程的池化技术和数据库连接池、连接池的思想一致都是为了解决资源的创建 / 销毁开销大、资源数量失控的问题用核心线程保基础效率用任务队列做缓冲用临时工应对峰值用拒绝策略做限流用监控做兜底最终实现线程资源的高效利用让并发业务既不卡壳也不崩掉。而它和 synchronized、AQS、CAS 的关系就是 Java 并发的 “全家桶”synchronized 是基础锁CAS 是无锁并发的核心AQS 是锁和线程池的底层框架ThreadPoolExecutor 是 AQS 的上层高级应用 —— 懂了底层再看线程池就像看包工头搬砖一眼看透本质。最后补一句线程池不是银弹合理配置才是王道别指望一个线程池走天下根据业务拆分成多个线程池比如核心业务池、非核心业务池才是高级架构师的操作