当前位置：首页 > news >正文

《Java 100 天进阶之路》第55篇：线程池ThreadPoolExecutor（2026版）

news 2026/7/13 10:14:49

第55篇：线程池ThreadPoolExecutor（2026版）

📌系列导航：《Java 100 天进阶之路》完整目录 |
⬅️ 上一篇：第54篇：AQS抽象队列同步器 |
➡️ 下一篇：第56篇：死锁与排查工具（待发布）

🗺️ 本文阅读地图（3 分钟速览）

第54篇拿下了 AQS，本篇深入并发编程最常用的工具——线程池。掌握了 ThreadPoolExecutor，你就掌握了 Java 并发编程的“生产力工具”：

模块	核心问题	一句话回答
七大参数	线程池由哪些参数控制？	corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler
工作流程	任务提交后怎么处理？	核心线程 → 任务队列 → 非核心线程 → 拒绝策略
四种拒绝策略	线程池满了怎么办？	AbortPolicy（抛异常）、CallerRunsPolicy（调用者执行）、DiscardPolicy（丢弃）、DiscardOldestPolicy（丢弃最旧）
Executors 陷阱	为什么大厂禁止用 Executors？	无界队列 → OOM，无限线程 → 资源耗尽
面试最爱问	高频考点有哪些？	见文末 🎤 小节

文章目录

- 第55篇：线程池ThreadPoolExecutor（2026版）
- - 🗺️ 本文阅读地图（3 分钟速览）
  - 一、核心知识点
  - 二、生活类比：从“互联网公司”到“线程池”
  - 三、七大核心参数详解
  - - 3.1 corePoolSize（核心线程数）
    - 3.2 maximumPoolSize（最大线程数）
    - 3.3 keepAliveTime + unit（空闲存活时间）
    - 3.4 workQueue（工作队列）
    - 3.5 threadFactory（线程工厂）
    - 3.6 handler（拒绝策略）
  - 四、任务执行流程（面试核心）
  - - 4.1 完整流程图
    - 4.2 关键理解
    - 4.3 execute() vs submit()
    - 4.4 线程池生命周期管理
  - 五、Executors 的陷阱（为什么大厂禁用）
  - - 5.1 三大陷阱
    - 5.2 正确做法：手动创建 ThreadPoolExecutor
  - 六、生产级避坑清单
  - 七、面试高频考点
  - 面试官追问陷阱（加分题）
  - 八、练习题
- 📊 你的学习进度
- 👉 下一篇文章预告

一、核心知识点

线程池是什么？

线程池是一种池化资源管理技术，通过预先创建一定数量的线程并统一管理，实现任务的异步执行与资源复用。

四大核心优势：

优势	说明
降低资源消耗	复用已创建的线程，避免频繁创建/销毁的系统开销
提高响应速度	任务到达时无需等待线程创建即可执行
提高线程可管理性	统一分配、调优和监控线程资源
提供附加功能	定时执行、并发控制、任务排队等

核心设计思想：基于生产者-消费者模型——提交任务的线程是生产者，线程池中的工作线程是消费者，任务队列（BlockingQueue）是缓冲区。

七大核心参数：

publicThreadPoolExecutor(intcorePoolSize,// 1. 核心线程数intmaximumPoolSize,// 2. 最大线程数longkeepAliveTime,// 3. 空闲线程存活时间TimeUnitunit,// 4. 时间单位BlockingQueue<Runnable>workQueue,// 5. 工作队列ThreadFactorythreadFactory,// 6. 线程工厂RejectedExecutionHandlerhandler// 7. 拒绝策略)

二、生活类比：从“互联网公司”到“线程池”

线程池就像一家互联网公司的人力资源管理：

corePoolSize（核心线程数）：公司的正式员工。只要公司不倒闭，即使没活干也不会轻易辞退。
maximumPoolSize（最大线程数）：公司能容纳的总人数（正式员工 + 临时工）。当正式员工都在忙，任务积压时，公司会招聘临时工。
workQueue（任务队列）：公司的待办任务池。正式员工忙不过来时，新任务先放进待办池排队。
非核心线程（临时工）：任务池满了，正式员工忙不过来，公司开始招临时工帮忙。任务高峰期过去，临时工空闲太久就会被裁掉（keepAliveTime）。
拒绝策略：正式员工、临时工都在忙，待办任务池也满了，新任务来了怎么办？公司有四种应对方案（见下文）。

线程池初始化时不会立即创建核心线程，而是在任务提交时懒加载创建，正式员工是“入职后才开始干活”。

三、七大核心参数详解

3.1 corePoolSize（核心线程数）

定义：线程池中长期维持的最小线程数量，即使空闲也不会被销毁。

核心行为：

默认情况下，核心线程会一直存活
提交新任务时，如果当前运行线程数 < corePoolSize，立即创建新线程执行任务（即使其他核心线程空闲）
可通过allowCoreThreadTimeOut(true)允许核心线程超时销毁

设置建议：

CPU 密集型（计算为主）：CPU 核数 + 1
IO 密集型（网络/磁盘等待为主）：CPU 核数 * 2或CPU 核数 / (1 - 阻塞系数)

3.2 maximumPoolSize（最大线程数）

定义：线程池允许创建的最大线程数量。

核心行为：

当核心线程已满且工作队列已满时，线程池会创建非核心线程直到达到 maximumPoolSize
包含核心线程和非核心线程两部分

注意事项：

maximumPoolSize 必须 >= corePoolSize
如果队列是无界队列（如LinkedBlockingQueue默认），该参数失效（因为队列永远不会满）

3.3 keepAliveTime + unit（空闲存活时间）

定义：非核心线程空闲后的存活时间。

核心行为：

当线程池中的线程数量超过 corePoolSize 时，多余的空闲线程在终止前等待新任务的最长时间
若设置allowCoreThreadTimeOut(true)，核心线程也会受此参数影响

3.4 workQueue（工作队列）

定义：用于存储等待执行任务的阻塞队列。

常见队列对比：

队列类型	特点	适用场景	风险点
ArrayBlockingQueue	有界阻塞队列，基于数组，FIFO	任务量可控，需限制队列长度	需合理设置队列大小
LinkedBlockingQueue	可选有界（默认无界），基于链表	流量平稳的后台任务	无界队列 → 内存溢出风险
SynchronousQueue	不存储元素，直接交给线程	高吞吐、低延迟场景	需配合足够线程数
PriorityBlockingQueue	支持优先级的无界阻塞队列	需按优先级执行任务	无界队列 → OOM 风险
DelayQueue	延迟队列，元素到期后才能被获取	定时任务、超时处理	无界队列 → OOM 风险

生产环境建议：

避免使用无界队列，推荐设置队列容量为max(核心线程数, 预期峰值 QPS × 平均处理时间)
对于突发流量场景，可采用SynchronousQueue+ 弹性扩容策略

3.5 threadFactory（线程工厂）

定义：创建线程的工厂。

核心作用：

默认是Executors.defaultThreadFactory()
自定义时可设置线程名称、是否为守护线程等

自定义示例：

ThreadFactorynamedFactory=r->newThread(r,"biz-pool-%d");// 或使用 GuavaThreadFactorynamedFactory=newThreadFactoryBuilder().setNameFormat("order-process-pool-%d").build();

3.6 handler（拒绝策略）

定义：当线程池已满（队列满了 + 线程数已达 maximum）且还有新任务时触发的处理策略。

四种内置拒绝策略：

策略	行为	适用场景
AbortPolicy	抛出`RejectedExecutionException`（默认）	需要明确感知任务被拒绝
CallerRunsPolicy	由调用者线程执行该任务	不能丢失任务，可接受调用者阻塞
DiscardPolicy	静默丢弃新任务，不抛异常	可容忍部分任务丢失（如日志）
DiscardOldestPolicy	丢弃队列中最旧的任务，再提交新任务	需要最新任务优先执行

💡AbortPolicy 是默认策略，如果不想任务丢失，应显式设置CallerRunsPolicy。

四、任务执行流程（面试核心）

4.1 完整流程图

线程池执行execute()的四步流程：

4.2 关键理解

⚠️重要：队列满了才创建非核心线程，而不是先扩充到 maximumPoolSize。

设计逻辑：核心线程是“常驻员工”，任务是“待办池”，非核心线程是“临时工”。只有待办池满了，正式员工忙不过来，才招临时工。这避免了过度创建线程带来的资源浪费。

边界情况：

当corePoolSize = maximumPoolSize时，退化为固定大小线程池
设置maximumPoolSize为Integer.MAX_VALUE时，允许无限扩容（需谨慎使用）
无界队列时，maximumPoolSize参数失效（队列永远不会满）

4.3 execute() vs submit()

对比	execute(Runnable)	submit(Callable/Runnable)
返回值	❌ 无返回值	✅ 返回`Future<T>`
异常处理	任务异常直接抛出到控制台	异常封装在 Future 中，调用`get()`时抛出
适用场景	不需要返回结果的任务	需要获取执行结果或处理异常

4.4 线程池生命周期管理

方法	说明
`shutdown()`	优雅关闭——等待已提交任务完成，不再接受新任务
`shutdownNow()`	立即关闭——尝试中断运行中任务，返回未执行任务列表
`isShutdown()`	判断是否已关闭
`isTerminated()`	判断是否已终止
`awaitTermination(timeout, unit)`	阻塞等待线程池终止

五、Executors 的陷阱（为什么大厂禁用）

阿里巴巴《Java开发手册》明确禁止在生产环境使用Executors工厂方法创建线程池。

5.1 三大陷阱

Executors 方法	隐藏的问题	后果
`newFixedThreadPool(n)`	使用无界 LinkedBlockingQueue（容量`Integer.MAX_VALUE`）	任务堆积 →OOM
`newSingleThreadExecutor()`	同上，且单线程处理	积压风险更高 →OOM
`newCachedThreadPool()`	最大线程数`Integer.MAX_VALUE`，无限创建线程	高并发下创建海量线程 →资源耗尽 / CPU 100%
`newScheduledThreadPool(n)`	同样存在线程数失控风险	OOM 或资源耗尽

⚠️结论：Executors 的便利背后是隐患——“无界队列 + 固定线程 = 任务无限堆积 → OOM”，“无界线程数 = 系统资源被耗尽 → OOM 或 CPU 打满”。

5.2 正确做法：手动创建 ThreadPoolExecutor

ExecutorServiceexecutor=newThreadPoolExecutor(10,// corePoolSize20,// maximumPoolSize60L,TimeUnit.SECONDS,// keepAliveTimenewArrayBlockingQueue<>(100),// ✅ 有界队列，防止OOMnewThreadFactoryBuilder()// ✅ 自定义线程名.setNameFormat("biz-pool-%d").build(),newThreadPoolExecutor.AbortPolicy()// ✅ 明确拒绝策略);

六、生产级避坑清单

✅ 线程池生产环境使用规范 1. 禁止使用 Executors 创建线程池 → 手动创建 ThreadPoolExecutor 2. 必须使用有界队列 → ArrayBlockingQueue 或指定容量的 LinkedBlockingQueue 3. 自定义线程名称 → ThreadFactory 设置线程名，便于日志追踪和问题排查 4. 根据场景选择合适的拒绝策略 → 不能丢任务用 CallerRunsPolicy 5. 线程数配置参考： - CPU 密集型：CPU 核数 + 1 - IO 密集型：CPU 核数 * 2 或更高 6. 务必在 finally 中关闭线程池 → 使用 shutdown() + awaitTermination() 7. 任务中必须捕获异常 → 否则异常会丢失，线程被回收

七、面试高频考点

Q1：ThreadPoolExecutor 的七大参数是什么？各自的作用？

corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲存活时间）、unit（时间单位）、workQueue（工作队列）、threadFactory（线程工厂）、handler（拒绝策略）。核心线程是“常驻员工”，非核心线程是“临时工”，工作队列是“待办池”。

Q2：任务提交后线程池的执行流程？

三步判断：① 当前线程数 < corePoolSize → 创建核心线程执行；② 队列未满 → 放入队列等待；③ 线程数 < maximumPoolSize → 创建非核心线程执行；④ 否则执行拒绝策略。队列满了才创建非核心线程。

Q3：为什么禁止使用 Executors 创建线程池？

newFixedThreadPool和newSingleThreadExecutor使用无界 LinkedBlockingQueue，任务堆积会导致OOM。newCachedThreadPool最大线程数为Integer.MAX_VALUE，高并发下会创建海量线程，导致系统资源耗尽或 CPU 100%。生产环境必须手动创建 ThreadPoolExecutor，使用有界队列。

Q4：线程池的拒绝策略有哪些？

四种内置策略：① AbortPolicy（抛异常，默认）；② CallerRunsPolicy（调用者线程执行，可防止任务丢失）；③ DiscardPolicy（静默丢弃）；④ DiscardOldestPolicy（丢弃最旧任务）。

Q5：corePoolSize 和 maximumPoolSize 如何设置？

CPU 密集型：corePoolSize = CPU 核数 + 1，减少上下文切换。IO 密集型：corePoolSize = CPU 核数 * 2 或更高，利用等待 IO 的时间片。maximumPoolSize 根据业务峰值和系统资源调整，一般为核心线程数的 2-4 倍。必须配合有界队列，否则 maximumPoolSize 失效。

面试官追问陷阱（加分题）

追问1：“LinkedBlockingQueue无界时，maximumPoolSize还有意义吗？”

👉没有意义。无界队列永远不会满，线程池永远不会创建非核心线程。maximumPoolSize和拒绝策略都失效，只有 corePoolSize 在工作。这是Executors.newFixedThreadPool()的致命问题。

追问2：“CallerRunsPolicy有什么副作用？什么时候用？”

👉 调用者线程执行任务，会阻塞调用者，可能导致上游系统超时。适用于不能丢失任务的场景（如支付回调、订单确认），且调用者能承受阻塞。

追问3：“线程池中的线程抛异常会怎样？”

👉 任务抛出未捕获异常时，线程会被回收（Worker 退出），线程池会创建新线程补充。这也是为什么需要在任务中自行捕获异常——否则任务失败不会重试，且线程创建销毁有额外开销。

八、练习题

分析题：用Executors.newFixedThreadPool(10)创建线程池，提交大量任务后为什么会 OOM？
💡 思路：newFixedThreadPool底层使用无界 LinkedBlockingQueue，任务处理速度跟不上提交速度时，任务不断在队列中堆积，最终耗尽堆内存。
代码题：手动创建一个线程池，要求：核心线程数 5、最大线程数 20、空闲存活 60 秒、有界队列容量 100、拒绝策略为 CallerRunsPolicy、自定义线程名“biz-pool-%d”。
场景设计：某支付系统需要异步处理订单，任务绝对不能丢失，且系统对延迟不敏感。应该选择什么拒绝策略？为什么？
💡 思路：选择CallerRunsPolicy。调用者线程直接执行任务，确保任务不会丢失。虽然会阻塞调用者，但对延迟不敏感的系统可以接受。