文日小栈

1. 完整回答

Java 线程池是一种统一管理和复用线程的并发执行机制，核心实现类是 ThreadPoolExecutor。

它主要解决两个问题：一是频繁创建和销毁线程带来的资源开销，二是高并发场景下线程数量失控，导致 CPU 频繁切换、内存占用过高，甚至系统资源耗尽。

线程池的核心思想是线程复用、任务排队和并发控制。

任务提交后，如果当前线程数小于核心线程数，就创建线程执行；达到核心线程数后，任务优先进入阻塞队列；如果队列满了，就继续创建线程，直到达到最大线程数；如果线程数和队列都达到上限，就触发拒绝策略。

工作线程执行完任务后，还会继续从队列中获取新任务。对于超过核心线程数的空闲线程，线程池会根据存活时间进行回收。

线程池的优势是能够减少线程创建开销，控制系统并发度，还能通过队列和拒绝策略应对突发流量。

2. 核心原理与关键概念

核心原理：任务提交与调度流程

ThreadPoolExecutor 采用核心线程数、阻塞队列、最大线程数和拒绝策略共同控制任务执行。

判断核心线程数：如果当前工作线程数小于 corePoolSize，优先创建新线程执行任务。
尝试加入队列：达到核心线程数后，优先将任务放入 workQueue，等待空闲线程处理。
尝试扩容线程：如果任务无法入队，并且线程数小于 maximumPoolSize，就创建新的工作线程。
触发拒绝策略：如果任务无法入队，并且线程数达到上限，就执行 RejectedExecutionHandler。
复用与回收线程：工作线程循环获取任务，超过核心线程数的空闲线程在达到存活时间后可以被回收。

整体流程：

提交任务 → 核心线程数检查 → 尝试入队 → 扩容至最大线程数 → 拒绝策略

如果线程池已经关闭，新提交的任务也会进入拒绝处理流程。

七个核心参数

参数	作用
`corePoolSize`	核心线程数，决定线程池优先维持的工作线程数量
`maximumPoolSize`	最大线程数，限制线程池能够创建的工作线程总数
`keepAliveTime`	超过核心线程数的空闲线程可等待的最长时间
`unit`	空闲存活时间的单位
`workQueue`	保存等待执行任务的阻塞队列
`threadFactory`	负责创建线程，可以配置线程名称等属性
`handler`	任务无法接收时执行的拒绝策略

默认情况下，核心线程按需创建，并且不会因为空闲而超时退出；通过 allowCoreThreadTimeOut(true) 可以允许核心线程超时回收。

工作线程的执行机制

线程池内部通过 Worker 管理工作线程。

创建 Worker → 执行当前任务 → 从队列获取任务 → 执行下一个任务 → 满足退出条件后回收

因此，一个工作线程可以连续执行多个任务，实现线程复用。

3. 高频面试追问

3.1 为什么使用线程池，直接创建 Thread 有什么问题？

主要是为了降低线程管理开销，并控制系统资源消耗。

直接使用 new Thread()，每个任务通常都需要创建一个新线程。线程创建涉及内存分配和操作系统资源，执行结束后还要回收。如果并发量很大，容易产生大量线程，增加内存占用和上下文切换开销。

线程池通过复用工作线程减少这些成本，并且可以限制线程数量、控制任务排队和处理过载。

例如批量处理一万个任务，使用固定数量的工作线程循环执行，通常比同时创建一万个平台线程更容易控制资源消耗。

3.2 如果核心线程数为 2、最大线程数为 4、队列容量为 3，提交 8 个任务会怎样？

假设线程池初始没有工作线程，并且前面的任务一直没有执行完成：

第 1、2 个任务：分别创建核心线程执行。
第 3、4、5 个任务：进入阻塞队列等待。
第 6、7 个任务：队列已满，继续创建两个工作线程。
第 8 个任务：线程数达到 4，队列也已满，触发拒绝策略。

所以，线程池的执行顺序是先达到核心线程数，再排队，队列满后扩容，最后拒绝。

实际运行时，如果某个任务提前结束并腾出了队列空间，后续任务就可能正常入队。

继续追问：线程池能够保证任务按照提交顺序执行吗？

一般不能保证。多个工作线程可以并发执行任务，任务耗时也可能不同。即使使用先进先出队列，也无法保证任务按照提交顺序完成。如果业务要求严格串行执行，可以使用单线程执行器，同时需要注意排队延迟。

3.3 为什么设置了最大线程数，线程池却始终只有核心线程数？

通常是因为使用了无界任务队列。

ThreadPoolExecutor 达到核心线程数后，会优先尝试把任务放入队列。只有入队失败，才会尝试继续创建线程。

如果使用默认容量的 LinkedBlockingQueue，容量上限非常大，正常情况下任务会持续排队，几乎不会触发扩容。

这会带来两个问题：最大线程数基本发挥不了作用；当任务提交速度长期超过处理速度时，队列持续增长，可能导致内存不足。

因此，生产环境通常会根据任务量和延迟要求设置有界队列。

继续追问：SynchronousQueue 为什么能让线程池更容易扩容？

SynchronousQueue 不存储任务，每次提交都需要直接交给等待接收的工作线程。如果没有线程能够立即接收，入队就会失败，线程池会尝试创建新线程。

它适合需要直接移交任务的场景，但必须控制最大线程数，否则高并发下仍然可能创建过多线程。

3.4 线程池有哪四种拒绝策略？实际应该怎么选？

ThreadPoolExecutor 内置四种拒绝策略：

策略	处理方式
`AbortPolicy`	默认策略，抛出 `RejectedExecutionException`
`CallerRunsPolicy`	线程池未关闭时，由提交任务的线程直接执行
`DiscardPolicy`	直接丢弃当前任务
`DiscardOldestPolicy`	丢弃队列头部等待的任务，再尝试提交当前任务

实际选择要看任务是否允许丢失，以及系统是否允许提交线程被阻塞。

核心业务通常需要明确感知拒绝，可以使用 AbortPolicy，配合异常处理、限流或降级。

如果允许提交方承担执行成本，可以考虑 CallerRunsPolicy。它会减慢任务提交速度，形成一定的反压效果，但也会拉长调用线程的响应时间。

对于允许丢弃的低优先级任务，可以考虑丢弃策略，不过最好配合监控。

另外，CallerRunsPolicy 在线程池已经关闭时会直接丢弃任务，因此不能把它当成任务可靠执行的保证。

3.5 execute() 和 submit() 有什么区别？任务发生异常怎么办？

主要区别是是否返回 Future，以及任务异常的处理方式。

execute() 接收 Runnable，没有任务结果返回。如果任务抛出未捕获异常，异常会导致当前工作线程异常结束，线程池会按需要补充工作线程。

submit() 可以提交 Runnable 或 Callable，并返回 Future。任务执行过程中发生的异常会被封装，调用 Future.get() 时会以 ExecutionException 的形式体现。

例如执行一个需要返回计算结果的任务，可以使用 submit()，之后通过 Future 获取结果。

如果是无需返回值的异步任务，可以使用 execute()。

实际开发中，无论采用哪种方式，都应该明确异常处理机制。特别是使用 submit() 时，如果从不检查 Future，任务失败就可能没有被及时发现。

3.6 线程池的核心线程数、最大线程数和队列容量应该怎么设置？

线程池参数需要结合任务类型、实际耗时、并发量以及下游资源容量来确定。

对于 CPU 密集型任务，比如复杂计算、数据加密，线程数通常可以从 CPU 核心数附近开始设置。线程过多会增加上下文切换，未必提高吞吐量。

对于 I/O 密集型任务，比如数据库查询、远程接口调用，线程经常处于等待状态，可以适当增加线程数，提高 CPU 利用率。

如果需要初步估算，可以参考：

线程数 ≈ CPU 核心数 × (1 + 等待时间 / 计算时间)

但这个公式只是起点，实际还需要受到数据库连接池、下游并发限制以及内存资源的约束。

队列容量主要根据峰值任务量和可接受的等待时间设置。队列过小容易频繁拒绝，过大则可能导致任务延迟不断增加。

最终需要通过压测观察 CPU 利用率、任务执行时间、队列等待时间和拒绝数量，再调整参数。

3.7 为什么生产环境通常不建议直接使用 Executors 创建线程池？

主要原因是部分工厂方法采用了近似无界的队列或者非常大的线程数量上限，在突发流量下存在资源耗尽风险。

例如：

newFixedThreadPool() 使用固定数量的线程，但采用无界队列，任务积压可能占用大量内存。
newCachedThreadPool() 使用 SynchronousQueue，空闲线程可以复用，但线程数量上限非常大，高并发下可能创建过多线程。
newSingleThreadExecutor() 保证任务串行执行，但同样使用无界队列。

这些方法本身可以正常使用，只是缺少部分生产场景需要的资源限制。

因此，业务线程池通常更适合显式配置 ThreadPoolExecutor，明确核心线程数、最大线程数、队列容量、线程名称和拒绝策略。

对于定时任务，可以使用 ScheduledThreadPoolExecutor；对于 Java 21 及以上版本的部分阻塞 I/O 场景，还可以考虑虚拟线程执行器。

3.8 shutdown() 和 shutdownNow() 有什么区别？怎样优雅关闭线程池？

区别在于如何处理已经提交但尚未完成的任务。

shutdown() 会停止接收新任务，但已经提交的任务，包括队列中等待的任务，仍然可以继续执行。

shutdownNow() 会尝试中断正在执行的任务，同时停止处理队列中的等待任务，并返回尚未开始执行的任务列表。

需要注意，Java 中断是一种协作机制。如果任务不响应中断，调用 shutdownNow() 也无法保证立即停止。

实际开发中，优雅关闭一般采用：

shutdown() → awaitTermination() → 超时后按需调用 shutdownNow()

也就是先等待已有任务完成，如果超过规定时间，再尝试中断剩余任务，并处理未执行的任务。

3.9 线上线程池任务大量积压，应该怎么排查？

首先要判断任务生产速度是否持续超过处理速度，然后确认是线程池配置问题，还是任务本身执行过慢。

通常会观察几个指标：

活跃线程数：判断工作线程是否长期处于繁忙状态。
当前线程数：判断线程池是否已经扩容到上限。
队列长度和等待时间：判断任务是否持续积压。
任务执行耗时：排查慢 SQL、接口超时、锁竞争等问题。
拒绝次数：判断线程池是否已经进入过载状态。

如果线程都在等待数据库连接，单纯增加线程数可能使问题更加严重，需要优先排查数据库连接池和下游性能。

如果是突发流量导致积压，可以考虑限流、缩短超时时间、优化任务处理逻辑，或者根据资源容量调整线程池参数。

另外，线程池最好按业务隔离，避免低优先级的耗时任务占满线程，影响核心业务。

继续追问：为什么线程池中使用 ThreadLocal 需要特别注意？

因为线程池会复用工作线程，而 ThreadLocal 中的数据与线程绑定。

如果前一个任务设置了用户信息但没有清理，后续任务复用同一个线程时，就可能读取到之前的数据，也可能导致对象被长时间持有。

因此，任务结束时通常需要在 finally 中调用 ThreadLocal.remove()，清理当前任务保存的上下文。

3.10 Java 21 的虚拟线程和传统线程池有什么区别？

核心区别在于线程资源的使用方式和并发模型。

传统线程池主要复用平台线程。平台线程与操作系统线程关联，创建和维护成本较高，所以通常需要限制线程数量。

Java 21 正式引入的虚拟线程由 JVM 调度，创建成本更低。大量虚拟线程可以共享较少的平台线程，在支持的阻塞操作中，虚拟线程能够挂起，让底层平台线程继续执行其他任务。

因此，虚拟线程特别适合存在大量阻塞等待的场景，比如高并发 HTTP 调用和数据库访问。

通过 Executors.newVirtualThreadPerTaskExecutor()，可以为每个任务创建一个新的虚拟线程，通常没有必要对虚拟线程本身进行池化。

不过，虚拟线程不会增加 CPU 的实际计算能力。对于 CPU 密集型任务，并发数量增加不一定能提高吞吐量。

同时，数据库连接、外部接口等资源仍然需要限流，可以使用信号量等机制控制并发访问量。

4. 易混淆概念对比

4.1 核心线程数与最大线程数

对比项	corePoolSize	maximumPoolSize
含义	核心线程数量	线程数量上限
作用	处理常规任务负载	应对任务高峰
创建时机	优先创建至核心数量	任务无法入队时才尝试扩容
空闲回收	默认不因空闲超时	超额空闲线程可以超时回收

4.2 常见阻塞队列

队列	核心特点	适用情况
`ArrayBlockingQueue`	数组实现，固定容量	需要明确限制排队数量
`LinkedBlockingQueue`	链表实现，可设置容量	需要任务缓冲，注意显式设置容量
`SynchronousQueue`	不存储任务，直接移交	希望任务快速交给线程执行

4.3 Runnable 与 Callable

对比项	Runnable	Callable
执行方法	`run()`	`call()`
返回结果	无返回值	可以返回结果
检查型异常	不能直接声明抛出	可以声明抛出
常见用途	无结果任务	有结果的计算任务

4.4 execute() 与 submit()

对比项	execute()	submit()
返回值	无	返回 `Future`
任务类型	`Runnable`	`Runnable`、`Callable`
执行异常	未捕获异常会影响工作线程	异常保存在 `Future` 中
常见用途	无需获取执行结果	需要获取结果或检查任务状态

4.5 传统线程池与虚拟线程

对比项	传统平台线程池	虚拟线程执行器
线程创建成本	相对较高	相对较低
主要机制	复用有限的平台线程	通常每个任务创建一个虚拟线程
适用场景	需要明确控制工作线程数量	大量阻塞 I/O 并发任务
并发限制	线程数和队列容量	通常通过独立限流机制限制资源访问
主要限制	平台线程资源相对昂贵	不直接提升 CPU 计算能力

5. 总结

Java 线程池主要用于统一管理和复用线程，减少线程创建开销，同时控制任务并发数量和系统资源消耗。

它的核心实现是 ThreadPoolExecutor，任务提交后按照核心线程、阻塞队列、最大线程、拒绝策略的顺序进行处理，工作线程通过循环获取任务实现复用。

实际使用中，最关键的是根据任务类型合理配置线程数，使用有界队列控制任务积压，并选择适合业务的拒绝策略。

对于 CPU 密集型任务，需要控制线程数量；对于 I/O 密集型任务，可以适当增加并发。Java 21 之后还可以考虑虚拟线程来提高大量阻塞任务的并发能力，但数据库连接、下游接口等资源仍然需要独立控制。