1. Java线程池到底解决了什么问题：先算算手动new Thread的账

大家最开始写Java并发代码，八成都是这个路子：来一个请求就new Thread(() -> doSomething()).start()。本地跑着没问题，功能也正常，等上了生产环境，用户一多，服务就开始不对劲了——CPU飙高、内存报警、接口超时，严重的直接OOM。

这不是段子，是我早年真实踩过的坑。后来才明白，手动创建线程的问题根本不是"代码能不能跑"，而是成本被完全忽略了。

每一个线程背后都是一套完整的操作系统资源：线程栈默认要占1MB左右的内存空间，创建和销毁需要触发系统调用，频繁切换线程还会带来上下文切换的开销。假设你的接口QPS是2000，每个请求都新建线程处理，线程对象本身要等GC回收，JVM里瞬时可能堆积数百上千个线程。我见过最夸张的一次，生产环境线程数到了3000多，Full GC一天十几次，服务基本处于半瘫痪状态。

线程池（Thread Pool）就是来治这个病的。它的核心思路是：先把一批线程创建好放在池子里，任务来了直接复用线程执行，执行完线程不销毁，继续等下一个任务。这样线程的创建成本被分摊到多次任务执行中，同时通过限制池子里线程的数量，把并发度控制在一个系统能承受的范围里。

用个生活化的类比：餐厅高峰期的翻台压力大，如果每来一桌客人就临时招一个服务员，客人走了就辞退，那光招人、培训的成本就够餐厅破产。聪明的做法是固定养一批服务员，高峰期排队叫号，实在忙不过来了再临时加人，忙完再让人休息。Java线程池的corePoolSize就是固定服务员数量，workQueue就是排队叫号的候餐区，maximumPoolSize是能临时扩容的上限，handler则是"餐厅真的坐不下了"的时候怎么办的策略。

对于Java开发者来说，线程池不只是面试八股文里的常客，更是生产环境并发编程的基石。JDK在java.util.concurrent包下提供了成熟的线程池框架，核心类是ThreadPoolExecutor，它把线程的创建、调度、回收、队列管理全部封装好了。这一篇我会把线程池的知识点完整梳理一遍，从核心参数到执行流程，从内置线程池的坑到阻塞队列的选型，再到实战配置和面试问答，一次性讲透。

2. ThreadPoolExecutor的七大参数：每个参数都在回答一个具体问题

线程池的核心类ThreadPoolExecutor构造方法有多个重载版本，最完整的那个有七个参数。很多开发者初学线程池，这七个参数背得滚瓜烂熟，但真到要自己配置的时候就傻眼了。原因很简单：只知道参数名，不知道每个参数背后在回答什么问题。

2.1 corePoolSize：稳定在编员工数

corePoolSize是核心线程数，也就是池子里始终保留的线程数量。默认情况下，即使这些线程没有任务可做，它们也不会被销毁（除非设置了allowCoreThreadTimeOut(true)）。

这个值怎么定？它是线程池性能调优的第一个关键决策点。如果设置得太小，高并发时任务会在队列里积压，处理不过来；设置得太大，空闲线程会白白占用内存和CPU调度资源。后面我专门用一节讲它的估算方法，这里先记住一个概念：核心线程数代表系统正常负载下期望维持的并发处理能力。

2.2 maximumPoolSize：忙不过来的临时扩编上限

maximumPoolSize是线程池允许的最大线程数。当核心线程全部忙碌且工作队列已经满了，线程池没办法再让新任务排队了，此时会创建新线程来执行新任务。但新线程数量达到maximumPoolSize之后，就不会再创建了，再多的任务就只能走拒绝策略。

注意一个非常容易误解的点：最大线程数不是"平时都能用的线程数"，而是在队列满了之后的兜底扩容上限。很多初级开发者把corePoolSize和maximumPoolSize当成"最小并发数和最大并发数"来理解，这个理解在宏观上没错，但忽略了中间的触发条件——不是任务一多就立刻扩容，而是队列满了才扩容。这个触发顺序直接决定了任务的执行延迟和系统负载，后面讲执行流程时会详细展开。

2.3 keepAliveTime与TimeUnit：临时工的闲置淘汰时间

keepAliveTime配合TimeUnit使用，控制的是非核心线程的空闲存活时间。当一个非核心线程空闲了这么久，就会被回收销毁。

有个细节值得注意：JDK 1.6之后，如果调用allowCoreThreadCoreTimeout(true)，这个超时机制也会作用于核心线程，让核心线程在空闲一定时间后被回收。这样在低峰期可以进一步释放系统资源。

实际配置中，keepAliveTime不宜设得太短。比如CachedThreadPool把超时时间设为60秒，意味着一个临时线程空闲超过60秒就会被回收。如果设成1秒，高并发场景下线程频繁创建销毁，反而造成资源抖动。

2.4 workQueue：任务排队等候区

workQueue是线程池的阻塞队列，用来缓存等待执行的任务。

这里的关键认知是：队列不仅缓冲了任务压力，还决定了线程池的扩容时机。如果用的是有界队列（比如ArrayBlockingQueue），队列满了线程池才会扩容到maximumPoolSize。如果用的是无界队列（比如LinkedBlockingQueue，默认容量是Integer.MAX_VALUE），队列永远都不会"满"，那么maximumPoolSize这个参数就形同虚设了，因为永远没有扩容的触发条件。

这直接引出了内置线程池的一个大坑：FixedThreadPool和SingleThreadExecutor用的都是无界队列，所以它们的maximumPoolSize参数实际上不起任何作用，而且无界队列可能导致任务无限积压，最终内存耗尽。第五部分我会专门详细讲阻塞队列的选型。

2.5 threadFactory：线程的出身设定

threadFactory是线程工厂，用来创建线程池里的线程。不传的话，JDK会使用默认的Executors.defaultThreadFactory()。

这个参数平时最容易被忽略，但在生产环境监控排障时却极其重要。默认线程工厂创建的线程名字是pool-1-thread-1这种格式，如果你有多个线程池，线上出问题后jstack打印出来的线程栈，根本无法区分线程属于哪个业务线程池。经验做法是自定义ThreadFactory，给线程起一个有业务含义的名字，并设置好优先级：

ThreadFactory customThreadFactory = new ThreadFactory() { private final AtomicInteger count = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { Thread t = new Thread(r, "order-query-thread-" + count.getAndIncrement()); t.setDaemon(false); t.setPriority(Thread.NORM_PRIORITY); return t; } };

如果你用Spring框架，ThreadPoolTaskExecutor还提供了setThreadNamePrefix方法，更简单。给线程起好名字，是线程池实践中成本最低、收益最高的小技巧，没有之一。

2.6 RejectedExecutionHandler：队伍满员后的处理方式

当核心线程、工作队列、最大线程全都满了，新提交的任务会交给RejectedExecutionHandler来处理。JDK内置了四种拒绝策略，后文会细讲。这里只强调一点：拒绝策略是线程池最后的防线，它不能根本解决压力问题，但可以决定"系统撑不住时以什么方式失败"。是抛异常让调用方感知，还是静默丢弃，还是让提交任务的线程自己执行，这个选择要结合业务场景来定。

2.7 参数速览表

这几个参数的组合行为，就是线程池的全部秘密。理解了每个参数背后的"问题"，再看执行流程和内置线程池的源码，就会通透很多。

3. 任务从提交到执行：核心线程、队列、最大线程、拒绝策略的完整流转

线程池的参数不是孤立存在的，它们的配合关系决定了任务的生命周期。我先把完整的执行流程写出来，这是面试手撕源码时的标准答案，也是实际调优时判断性能瓶颈的地图。

3.1 任务提交后的四步判断

当你调用executor.execute(task)时，ThreadPoolExecutor内部执行的是极其精密的四步判断逻辑：

第一步：判断核心线程是否还有空闲

如果当前工作线程数小于corePoolSize，线程池会创建一个新线程来执行这个任务，即使已经有核心线程处于空闲状态，也不让新任务去排队。这一点很多人有误解，以为"核心线程有空闲，新任务直接复用不就行了"——但JDK的设计是：在核心线程数没达到corePoolSize之前，每来一个任务就新开一个线程，目的是让线程池尽快达到设定的核心并发能力。

第二步：尝试把任务放入工作队列

如果当前线程数已经大于等于corePoolSize，线程池会把任务交给workQueue.offer(task)，由阻塞队列暂存。队列操作成功，任务就排队等待核心线程执行完成后来取。

第三步：队列满了，尝试扩容

如果队列已经满了，offer失败，线程池会判断当前线程数是否小于maximumPoolSize。如果是，创建新线程直接执行这个刚提交的任务（注意不是去执行队列里排队的旧任务，这是按任务提交顺序的自然逻辑，新线程会继续从队列头部取任务执行）。

第四步：扩容也到上限了，执行拒绝策略

如果线程数已经到了maximumPoolSize，新任务会被交给RejectedExecutionHandler处理。

把四步判断抽象一下，就是面试题里最常问的那句话：先核心线程，再工作队列，再最大线程，最后拒绝策略。这个顺序就是线程池行为特性的核心所在。

3.2 触发扩容的条件与常见误解

我经常会问身边同事一个问题：核心线程数4，最大线程数10，队列容量100，现在一下来了50个任务，线程池会怎么处理？

不少人的答案是"创建10个线程，50个任务分成几批执行"。但正确答案是：前4个任务创建4个核心线程执行，后面46个任务全部放进队列排队。线程池不会因为任务多就立刻扩到10个线程，因为队列还没满，offer是成功的。

只有任务量超过了104个（4个核心线程都忙 + 队列100个排满），第105个任务到来时才会触发扩容，创建第5个线程。如果后续任务持续到来，线程数会一路涨到10，第11个以上新任务才走拒绝策略。

这个"队列未满不扩容"的机制，对系统负载有重要意义：短时间突发的任务会被队列吸收掉，系统不会因为瞬时的流量尖峰就疯狂创建线程，这实际上是一层缓冲保护。

3.3 四种拒绝策略：各自的适用场景

JDK在ThreadPoolExecutor内部类中定义了四种拒绝策略：

• AbortPolicy（默认）：直接抛出RejectedExecutionException异常。这是最"诚实"的策略——明确告诉调用方线程池已经扛不住了，你的任务我没有接收。适合那些任务丢失会造成严重后果的业务，宁可报错也不能静默丢掉。

• CallerRunsPolicy：不抛异常，而是让提交任务的线程自己执行这个任务。比如主线程调用execute提交任务，被拒绝后这个任务就在主线程里run()。这种策略的暗含逻辑是"谁提交谁执行"，用提交方的线程来消化压力，同时天然形成了一种背压机制——如果主线程被任务拖慢，提交新任务的速度自然就降下来了。适合低吞吐、对延迟不敏感但对任务完成率有要求的场景。

• DiscardPolicy：静默丢弃任务，不抛异常。这个策略我实际项目中基本不用，因为"任务消失"对业务是不可接受的，排查问题也极难发现。

• DiscardOldestPolicy：丢弃队列里最老的任务，然后重新尝试提交当前任务。这个策略适合允许丢弃一些旧任务、优先处理新任务的场景，比如实时性要求高的数据推送服务，旧数据晚推送还不如不推送。

3.4 自己改写拒绝策略的实操

内置的四种策略常常不够用。我有一个实际项目，要求线程池满载时，新任务不丢弃也不抛异常，而是降级走一条备用的消息队列通道，让下游慢慢消化。这种情况我就自己实现RejectedExecutionHandler：

public class MqFallbackPolicy implements RejectedExecutionHandler { @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { if (r instanceof TaskWrapper) { TaskWrapper task = (TaskWrapper) r; mqProducer.send(task.getPayload()); // 降级发消息 } else { throw new RejectedExecutionException("Unknown task type"); } } }

写自定义策略要注意两点：一是拿到executor参数后不要尝试再次调用execute()，否则可能造成递归；二是任务类型最好做一层包装，让拒绝策略能识别任务并提取必要的上下文信息。

执行流程这一整块内容，几乎覆盖了线程池面试八股文的60%，也是线上排查问题的主线索。比如你发现任务大量进入拒绝策略，按这个流程反射一遍就能定位：是核心线程数配得小了，还是队列配置不合理，还是瞬时流量真的超出了整个系统的承载上限，各有各的解法。

4. 内置四种线程池的翻车现场：快捷方式背后的真实代价

JDK的Executors工具类提供了一堆现成的线程池静态方法，用起来确实方便，一行代码就能拿到一个能跑的线程池。但麻烦也藏在这里——内置线程池封装好了参数，同时也封装了风险。阿里《Java开发手册》里明确禁止使用Executors创建线程池，更推荐直接使用ThreadPoolExecutor，原因就在它们默认的队列策略上。

4.1 FixedThreadPool：看起来稳，实则无界队列隐患

newFixedThreadPool(int nThreads)创建的线程池，核心线程数等于最大线程数，也就是说线程数量是固定的，不会扩容。

问题出在它的工作队列上，源码是：

new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());

用的是LinkedBlockingQueue，没指定容量——默认容量是Integer.MAX_VALUE，这意味着队列实际上是无界的。

这个设计初看很合理：线程数固定，任务多就排队慢慢执行。但在高并发场景下，如果任务产生速度长期大于消费速度，队列里的任务会一路堆积。每个Runnable对象都要占内存，堆积到百万级别时就会内存溢出（OOM）。最要命的是，这种OOM不是突然发生的，而是服务越来越慢，GC时间越来越长，最终在某一次高峰彻底崩溃。

4.2 CachedThreadPool：弹性最大，风险也最大

newCachedThreadPool()的参数配置：

new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());

核心线程数为0，最大线程数为Integer.MAX_VALUE，SynchronousQueue不存储任何任务——每个任务提交后必须立即有一个线程接收处理，否则就创建新线程。空闲线程超过60秒被回收。

这个"来多少任务就开多少线程"的设计，优点是响应极快，适合大量短时异步任务的场景。但风险也极其明显：如果提交任务的速度超过处理速度，线程数会无限增长，直接导致线程资源耗尽、CPU上下文切换开销失控，最终系统被压垮。我见过某个定时任务框架里误用了CachedThreadPool处理消息推送，高峰期瞬间创建了几千个线程，把一台8核16G的机器直接打到卡死。

4.3 SingleThreadExecutor：单线程的"串行"承诺也可能是坑

newSingleThreadExecutor()按名字理解，就是池子里只有一个线程，任务一个个串行执行，保证顺序性。它的实现也是无界队列。

单核线程池最容易被忽略的问题有两个。一是在某些JDK版本中，它是用FinalizableDelegatedExecutorService包装的，用来屏蔽掉ThreadPoolExecutor的setCorePoolSize等方法，确保使用者无法改成多线程。二是有界队列的不在场仍然会造成OOM风险，任务积压场景下和FixedThreadPool一样危险。

4.4 ScheduledThreadPool：延迟任务也要警惕队列积压

newScheduledThreadPool(int corePoolSize)是定时任务线程池，核心线程数可指定，用于执行延迟任务和周期任务。它的工作队列是DelayedWorkQueue，里面按任务的执行时间排序，到点了才会被取出执行。

DelayedWorkQueue的问题在于，它本质上也是无界的，如果不断有延迟时间很长的任务被提交，同样会堆积。另外要注意，调度线程池的maximumPoolSize默认是Integer.MAX_VALUE，虽然DelayedWorkQueue理论上不会触发扩容，但一切都要看实际使用的重载方法。

4.5 内置线程池速查对比

看到这里应该明白了，问题不在Executors本身，而在于默认参数不一定适合你的场景。最稳妥的做法是直接new ThreadPoolExecutor(...)并显式指定有界队列，每个参数根据自己的业务特性和流量模型来决定。

5. 阻塞队列的选择：队列的形状决定了线程池的性格

工作队列是线程池最容易被低估的组件。我做了几年并发编程后才深刻体会到：线程池的参数决定了它有多少人力，队列则决定了任务如何排队、会排多久、会不会把内存耗尽。不同类型的阻塞队列，直接塑造了线程池的行为特征。

5.1 有界队列 vs 无界队列，怎么选

队列选型的第一原则，就是明确自己能不能承受任务积压。

无界队列（如默认容量的LinkedBlockingQueue）的优点是任务不会被拒绝，提交方不用处理RejectedExecutionException。但代价是任务全部堆在内存里，一旦积压速度大于处理速度，系统内存就是唯一的上限。线上生产环境，我几乎不会用无界队列，原因很简单：宁可让服务及时报错，也不要让它拖着内存隐患慢慢走向OOM。

有界队列（如ArrayBlockingQueue）则把积压量限制在一个可控范围内，队列满了之后触发扩容和拒绝策略，形成一道明确的背压信号。缺点是如果队列容量设置不合理，可能出现频繁扩容和拒绝，但这是可以通过配置调优来解决的，不是结构性问题。

5.2 五种常用队列逐个拆

ArrayBlockingQueue

基于数组实现的有界队列，创建时必须指定容量。容量固定后，队列底层是一个环形数组，入队和出队操作共享同一把锁。

它的特点是一旦创建容量不可变，适合对任务积压量有严格上限的场景。我通常用它作为默认队列，比如订单处理线程池，队列容量设200，最多积压200个任务，再多就触发扩容或者拒绝策略，整个流程是可控的。

LinkedBlockingQueue

基于链表实现的队列，可以指定容量也可以不指定（不指定就是无界）。内置的FixedThreadPool使用的就是无界版本。

有界的LinkedBlockingQueue和ArrayBlockingQueue在功能上大致相当，但内部实现不同：LinkedBlockingQueue的入队和出队用了两把锁，理论上并发吞吐更高。不过它默认的Integer.MAX_VALUE容量是个隐形炸弹，创建时要格外注意显式指定容量。

SynchronousQueue

这个队列很特殊，它的内部容量为0，不存储任何任务。每个入队操作必须等待一个对应的出队操作，否则就会阻塞。

线程池用SynchronousQueue时，提交任务必须有一个线程立即来取，否则就创建新线程。配合CachedThreadPool的无限容量，形成了"任务一到必须立刻有人处理"的效果。它适合任务处理时间极短、且不能容忍排队等待的场景。代价就是线程数量完全跟着任务节奏走，没有缓冲。

PriorityBlockingQueue

支持按优先级排序的无界队列，任务可以是Runnable的实现类，通过实现Comparable接口或者在构造时传入Comparator来定义优先级。

它适合有优先级属性的任务场景，比如后台任务里，紧急的系统监控任务需要优先于普通的数据清理任务执行。注意两点：一是无界队列全部用同一个默认容量陷阱；二是优先级排序是全局的，如果低优先级任务长期占据队列，高优先级任务可能一直被跳过，这是优先级反转的一种形式，需要监控任务的海量程度。

DelayedWorkQueue

ScheduledThreadPoolExecutor专用的延迟队列，只在延迟时间到达后才把任务交给线程执行。内部实现是堆结构，任务的getDelay时间越小，越先被取出。

5.3 队列和线程池参数的配合节奏

队列选型不是独立的，它要和corePoolSize、maximumPoolSize配合起来看。

举个实际案例。我做过一个文件解析服务，每天定时有大批解析任务涌入，任务时长大约2秒左右。我最初配置的是核心线程8、最大线程16、队列容量1024，结果高峰期任务排队时间长达数十分钟。

后来分析了一下场景特征：任务数量大但单个耗时不长，突发性强但持续时间有限。这个场景的合理配置应该是让队列只承担极短时间的缓冲，快速扩容到maximumPoolSize去消化高峰。于是我把队列容量改成了64，核心线程数调到4，最大线程数调到20，结果排队时间降到秒级，CPU负载反而因为及时扩容更平稳了。

这就是队列和参数的动态平衡：队列越长，扩容越慢，排队延迟越大，系统越倾向于平滑；队列越短，扩容越快，资源消耗越激进，任务延迟越低。没有绝对正确的配置，只有适合场景的配置。

6. 线程池状态与优雅关闭：从RUNNING到TERMINATED的完整路径

线程池的关闭是生产环境最容易出事故的环节之一。很多线上故障的根本原因，是服务重启或发布时线程池被强杀，丢了一堆正在执行或排队中的任务。这一节把线程池的状态流转和关闭机制讲透。

6.1 五种运行状态

ThreadPoolExecutor内部用AtomicInteger的高3位来记录线程池状态，低29位记录工作线程数。五种状态分别是：

• RUNNING：正常运行状态，能接收新任务，也能处理队列中已有任务。
• SHUTDOWN：关闭状态，不再接收新任务，但会继续处理队列中已排队的任务。
• STOP：停止状态，不再接收新任务，不处理队列中的旧任务，且会中断正在执行的任务线程。
• TIDYING：所有任务已结束，工作线程数为0，线程池正在执行terminated()钩子方法。
• TERMINATED：terminated()方法执行完成，线程池彻底终止。

状态间的迁移路径是：RUNNING -> SHUTDOWN -> TIDYING -> TERMINATED，或者RUNNING -> STOP -> TIDYING -> TERMINATED。理解这套状态机，对正确使用shutdown和shutdownNow至关重要。

6.2 shutdown与shutdownNow：温柔关闭和暴力关闭

shutdown()是温柔关闭，它会将状态置为SHUTDOWN，然后等待队列中的任务全部执行完毕，线程池才自然过渡到TIDYING和TERMINATED。期间如果还有新任务提交，会被拒绝。

shutdownNow()是暴力关闭，将状态置为STOP，立即中断所有正在执行任务的线程，并返回队列中尚未执行的任务列表，让调用方可以自行处理这些遗留任务。

实际调用shutdownNow()的场景非常少。我记得有一次线上有个任务卡死了，无法自动结束，而发布窗口只有几分钟，才用了shutdownNow()硬杀，然后把遗留任务记录成日志，发布完成后手动补跑。大部分情况下优先用shutdown()。

6.3 awaitTermination：给线程池一个善后的宽限期

光调用shutdown()还不够，因为它是异步方法，调用完立即返回，线程池可能还在慢慢消化队列里的任务。如果这时候主程序直接退出，JVM一终止，线程池里的任务照样会丢失。

正确的关闭流程是配合awaitTermination来等待：

executor.shutdown(); if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { executor.shutdownNow(); if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { // 记录日志，标记线程池未能及时终止，需要人工介入 } }

这段代码的含义是：先温柔关闭，等待30秒看线程池是否结束；如果没结束说明有任务卡住了，升级为暴力关闭；再等30秒还不行，基本可以断定线程卡死在不可中断的阻塞操作里（如数据库连接等待、网络IO阻塞），只能记录日志走其他补偿流程。

我在用Spring的DisposableBean或者@PreDestroy做优雅停机时，都是这么处理线程池的。没有这个习惯之前，我在一次版本发布中直接丢了上千条未处理的业务消息，后续对账补了整整一天。从那以后，"关线程池必等、必中断保护"就成了我的铁律。

6.4 给线程池增加钩子方法做监控

ThreadPoolExecutor提供了三个可重写的钩子方法：beforeExecute、afterExecute、terminated。这三个方法平时是空实现，用来给子类做扩展的。

我最常用的是afterExecute，在里面统计任务执行时间和异常信息，喂给监控系统：

public class MonitoredThreadPoolExecutor extends ThreadPoolExecutor { private final MetricsRegistry metrics; @Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); long cost = ThreadLocal取到的任务开始时间差; metrics.histogram("task.cost").update(cost); if (t != null) { metrics.counter("task.exception").inc(); } } }

需要提醒一个细节：afterExecute拿到异常有个陷阱。当你的任务是Runnable直接提交时，如果任务内部抛了未捕获异常，异常会被FutureTask包装，不会直接通过Throwable t参数传递给你。只有当你提交的是Callable，且调用Future.get()时，异常才会从ExecutionException中暴露出来。所以想用钩子方法全面捕获异常，任务最好包装成Callable。

7. 实战配置线程池：核心线程数、队列长度、拒绝策略的经验公式

很多人学完线程池参数，到了真正配置的时候还是慌，不知道从哪里下手。我自己的经验是分三步走：先根据任务类型估算线程数，再确定队列容量和拒绝策略，最后留出监控和动态调整的后手。

7.1 线程数估算：CPU密集型和IO型任务的标准打法

业界流传一个经验公式：CPU密集型任务，核心线程数设为CPU核数+1；IO密集型任务，核心线程数设为CPU核数×2。

这个公式在大多数场景下是能用的，但我们应该理解它背后的原理。CPU密集型任务（如下载图片后做压缩、复杂计算），线程基本在占用CPU计算，线程数超过CPU核数之后，多出来的线程只能排队等待被调度，反而增加上下文切换开销。设成核数+1，是为了让某个线程因为页缺失、缓存未命中而短暂阻塞时，另一个线程能立刻顶上。

IO密集型任务（如发送HTTP请求、读写数据库），线程执行过程中有大量时间在等待网络或磁盘IO。这个等待时间CPU是空闲的，完全可以多开线程来利用这段空闲时间处理其他任务。所以理论上更精确的线程数是：

线程数 = CPU核数 * (1 + 等待时间 / 计算时间)

比如一个任务计算耗时20ms，IO等待耗时80ms，那么等待时间是计算时间的4倍，线程数应该是核数×5。这个公式每个项目差别很大，但给了我们一个估算的正确姿势：先测出任务的计算占比，再决定线程数。

7.2 队列长度设计：从业务容忍延迟倒推

队列长度没有统一标准，我的习惯是从业务角度倒推。核心问题是：这个任务最多能等多久？

假设核心线程数4，单任务执行时间200ms，队列容量N，那排在队尾的任务等待时间大约是N×200ms/4。如果业务要求任务提交后1秒内必须开始执行，那么N×200ms/4要小于1000ms，N最大取19左右，我一般保守取N=16。

项目里我还会做一个保守兜底：队列容量不大于corePoolSize的4倍（经验值，不是死规则）。队列太长，线程池就变成"任务堆积池"了。

7.3 拒绝策略选型的业务判断

拒绝策略的选择，我建议按业务的容忍度来分：

• 任务不能丢、报错后可以重试：用AbortPolicy，让调用方捕获RejectedExecutionException做重试或降级。
• 任务不能丢、可以延迟执行：用CallerRunsPolicy，提交线程自己消化，形成背压。
• 实时性要求高、旧任务价值低：考虑DiscardOldestPolicy，优先处理新的任务。
• 有独立的降级通道：自定义策略，如前面提到的发消息队列。

最不建议的是DiscardPolicy。它让任务悄无声息消失，没有日志、没有异常、没有回调，排查问题如大海捞针。

7.4 配置动态化：prestartAllCoreThreads与动态调参

一个常见的认知误区是：线程池配置好之后就死板了。其实ThreadPoolExecutor提供了强大的动态调节能力：

• prestartAllCoreThreads()：启动时立即创建所有核心线程，避免任务一到才创建线程的冷启动延迟。
• setCorePoolSize(int)：动态修改核心线程数。
• setMaximumPoolSize(int)：动态修改最大线程数。
• setKeepAliveTime(long, TimeUnit)：动态修改空闲回收时间。

利用这些方法，可以做一个简单的动态线程池管理器：后台定时监控队列积压量，积压超过阈值就把maximumPoolSize调大，空闲稳定后再回调。很多开源框架（如美团动态线程池组件）做的就是这套事情，但原理并不复杂，自己动手也能实现。

8. 面试高频问题：真正拉开差距的思考深度

线程池是Java面试八股文的重灾区，网上总结的面试题一抓一大把。但根据我自己面试候选人的经验，能够把线程池讲得出彩的人，靠的不是背答案，而是对源码和场景的理解深度。这一部分列出几个常见问题和我认为真正有价值的回答思路。

8.1 线程池的核心参数有哪些，你是怎么理解的

这个问题的标准答案是七大参数，但拉开差距的是对参数之间关系的理解。比如要主动提到："核心线程和最大线程之间还隔着一个工作队列，队列没有满之前线程池不会扩容，所以maximumPoolSize的生效条件是队列满。"再补一句："所以如果用了无界队列，maximumPoolSize就等于废掉了。"这几句话能直接展示你用过、思考过，而不是背书。

8.2 提交一个任务到线程池，内部经历了哪些过程

这题考的是执行流程。最好按四步判断来答：先判断核心线程；核心线程满了尝试入队；队列满了尝试扩容；扩容到上限走拒绝策略。每个步骤都可以追问细节。比如面试官问"入队失败意味着什么"，你要能答出"队列是有界的，且已经满了，此时系统需要更激进的方式处理压力"。

8.3 为什么不建议用Executors创建线程池

这个问题已经快变成标准面试题了。回答要点有两层：第一层是缺陷层面，FixedThreadPool和SingleThreadExecutor的无界队列会导致OOM，CachedThreadPool的最大线程数无上限会导致线程爆炸；第二层是方法论层面，直接使用ThreadPoolExecutor可以让参数显式化、可控化，规避这些隐含风险。如果能补一句"具体风险取决于业务场景，比如我的某类业务任务量小、量可控，用内置线程池问题也不大"，反而显得你辩证看待问题。

8.4 线程池的线程数应该怎么设置

这一题最能区分实战经验和理论派。建议回答按场景分：CPU密集型、IO密集型分别怎么算；IO密集型可以用任务的计算和等待时间比例来估算；然后补充一句"配置之后要用压测和监控来验证，不是写完就完事了"。压测里如果ThreadPoolExecutor的getTaskCount和completedTaskCount差距持续增大，就说明处理不过来，需要优化。

8.5 如果线程池中的任务抛异常了，会发生什么

这题的坑点在于execute()和submit()行为不同。用execute()提交任务时，如果任务中抛出运行时异常，线程会退出，ThreadPoolExecutor会创建新线程顶上，但你拿不到这个异常（除非设置UncaughtExceptionHandler）。用submit()提交时，异常被FutureTask捕获，会封装成ExecutionException，但需要调用Future.get()才会被抛出。如果不调用get()，异常就静默吞掉，这是很多线上诡异问题的一个重要来源。答题时把这个细节说清楚，基本就是满分。

8.6 线程池的关闭方法有哪些，区别是什么

shutdown()和shutdownNow()的区别是最常考的点。回答时我会带上状态机的迁移、awaitTermination的作用，以及自己项目里怎么用"先shutdown、再等待、再shutdownNow"的三段式关闭。这个回答既有源码依据，又有实践场景，比单纯背两个方法名的区别高出很多。

这些问题的回答思路，其实本质就是这篇文章的内容——参数怎么配，任务怎么流转，内置线程池埋了什么坑，队列怎么选，关闭怎么处理。把这些真正理解了，面试不是背出来的，是用经历喂出来的。