线程池这块，可以说是JUC并发编程里面试命中率最高的考点，没有之一。工作里你用不用得上、会不会调优是一回事，但面试官几乎必问“ThreadPoolExecutor的执行流程”“核心参数怎么设置”“为什么阿里规约不推荐Executors创建线程池”这些老掉牙的问题。很多人背得滚瓜烂熟，但一被追问“为什么队列满了才创建新线程”“SynchronousQueue到底在什么场景下用”就露馅了。
这篇帖子我不打算给你列一堆干巴巴的背诵条目，而是把线程池的核心机制、队列选型、参数推导、线上排查这几个关键点拆开揉碎，每个“八股点”都尽量讲清楚背后的逻辑和实际场景。目标很简单：你看完不仅能应付面试，回到项目里也敢自己上手配一个合理的线程池。
1. 从“为什么需要线程池”说起：先搞懂它在解决什么
1.1 线程创建的成本，比你想象的高得多
很多人知道线程池能复用线程，但对“复用”的价值其实没太多体感。我打个比方：每次new Thread都相当于雇一个临时工，雇人要办入职手续，干完活就离职，再招人还得再来一遍入职。线程创建时需要分配栈空间（默认1MB左右）、注册到JVM线程表、建立线程和操作系统的映射，这串动作的CPU开销和内存开销都很实在，高并发场景下大量短生命周期任务频繁创建线程，光这个损耗就能把系统拖垮。
线程池做的事情说白了就是养一批“常驻员工”，任务来了直接分配，干完活继续待命。它不只是省下了线程创建和销毁的开销，更重要的是把“并发度”控制在了可管理的范围之内。不用线程池直接new Thread的话，流量一冲上来线程数量完全失控，CPU上下文切换能把系统搞得比没并发还慢。
还有一个隐藏收益容易被忽略：线程池拥有统一的“队列缓冲”能力。当任务来的速度大于处理速度时，额外的任务可以排队等待，而不是直接把系统打挂，这在削峰填谷的场景里价值极大。
1.2 ThreadPoolExecutor的7大参数，每一处细节都是面试题
ThreadPoolExecutor最核心的构造方法有7个参数，面试考这个，说白了就是考察你有没有真的理解这几个参数之间的联动关系。
| 参数 | 含义 | 说明 |
|---|---|---|
| corePoolSize | 核心线程数 | 即使空闲也保留的线程数量 |
| maximumPoolSize | 最大线程数 | 线程池允许创建的最大线程数量 |
| keepAliveTime | 空闲存活时间 | 非核心线程空闲超过这个时间会被回收 |
| unit | 存活时间单位 | 配合keepAliveTime使用 |
| workQueue | 阻塞队列 | 用于存放等待执行的任务 |
| threadFactory | 线程工厂 | 创建新线程时使用的工厂，建议自定义 |
| handler | 拒绝策略 | 队列满且线程数达到maximumPoolSize时触发 |
这里有个特别容易忽略的细节：核心线程的存活时间。默认情况下核心线程即使空闲也不会被回收，但如果你把allowCoreThreadTimeOut设为true，核心线程在空闲超过keepAliveTime后也会被销毁。CachedThreadPool就是这么干的——它的核心线程数是0，所有线程都可回收，靠SynchronousQueue做直接交付。
1.3 核心执行流程：一个任务进来之后到底走哪条路
这大概是线程池面试里出现频率最高的问题，我建议你闭上眼睛都能把这个流程复述出来。一个任务被submit到线程池后，执行顺序是这样的：
- 如果当前线程数量小于corePoolSize，即使有核心线程空闲，也会新建一个线程来执行这个任务。
- 如果当前线程数量等于corePoolSize，任务会被放入阻塞队列等待。
- 如果队列已满，且当前线程数量小于maximumPoolSize，会创建新线程执行任务。
- 如果队列已满且当前线程数量等于maximumPoolSize，则触发拒绝策略。
注意第二步和第三步的顺序，这是初学者最容易搞混的地方。很多人误以为“核心线程不够了就会创建到最大线程数”，实际上中间还隔着一层队列缓冲。只有当队列也装不下了，线程池才会扩容到maximumPoolSize。这背后的设计思想是：线程是稀缺资源，队列是缓冲地带，先让任务排队而不是急着加线程。
还有一个反直觉的点：如果corePoolSize设成了0，任务提交时不会直接创建线程，而是先尝试放入队列，队列满了才会创建线程执行。用SynchronousQueue的时候效果最明显，因为这种队列没有缓冲容量，插入操作必须等待另一个线程来取，任务提交时如果corePoolSize=0，就会立即触发线程创建逻辑。
2. 阻塞队列：线程池的“缓冲层”怎么选
2.1 常见的几种阻塞队列，适用场景各不同
workQueue是ThreadPoolExecutor最灵活的切入点，它决定了任务的排队方式、允许的积压容量，以及线程池“真正的”行为特征。常见的阻塞队列大概有这几种：
| 队列 | 特性 | 典型场景 |
|---|---|---|
| ArrayBlockingQueue | 有界数组结构，容量固定 | 适合需要明确背压控制的生产环境 |
| LinkedBlockingQueue | 链表结构，默认无界，也可以指定容量 | Executors的FixedThreadPool默认使用无界版本 |
| SynchronousQueue | 不存储元素，直接交付 | CachedThreadPool的默认队列，适合短任务高吞吐 |
| PriorityBlockingQueue | 支持优先级排序的无界队列 | 需要按优先级处理任务的场景 |
| DelayQueue | 延迟队列，元素到时间才能取出 | 定时任务调度场景 |
注意，LinkedBlockingQueue如果是默认构造，容量是Integer.MAX_VALUE，相当于无界。这看起来省事，实际是埋雷。
2.2 为什么固定大小线程池配无界队列是个坑
很多教程讲newFixedThreadPool方便，却没有强调它默认使用的是无界LinkedBlockingQueue。由于队列永远不会满，第4步的拒绝策略永远不可能触发，线程数量也永远不会超过corePoolSize。表面上看线程数是“固定”了，但任务无限制地堆积在队列里，内存被吃光只是个时间问题。
用FixedThreadPool写过爬虫的朋友应该有体会：目标站点响应变慢，任务越积越多，队列里甚至堆了几百万个待处理URL，JVM堆内存嗖嗖往上涨，最后OOM。这个坑在线上非常典型。阿里规约不让用Executors的静态方法创建线程池，核心原因就在于此——不是这些方法写得烂，而是无界队列和过大的maximumPoolSize会让线程池失去自我保护能力。
正确姿势是什么呢？用有界队列。就算任务瞬时暴涨，队列最多只能积压固定数量的请求，超过这个量要么拒绝、要么让调用方自己跑，总比让进程直接挂掉强。有界队列配合合理的拒绝策略，本质上就是一种背压机制，把压力反馈到上游。
2.3 SynchronousQueue：不走队列，直接交付
SynchronousQueue从名字上看是个队列，但它其实不缓存任何任务元素。它一个线程put进去之后必须等另一个线程take出来，否则put会一直阻塞。所以ThreadPoolExecutor用了这个队列之后，任务的“排队”实际上变成了“有没有空闲线程能立刻接手”，如果没有空闲线程且线程数没到max，就立刻创建新线程。CachedThreadPool靠这个特性做到了“任务多则线程多、任务少则线程少”。
它并不适合所有场景。如果任务本身较重、处理比较耗时，SynchronousQueue会因为线程不断创建而失控。如果你的任务轻量、处理极快、并发波动大，那CachedThreadPool这种组合会很舒服。这里要记住一个原则：队列的选择从来不是独立的，它必须和线程数量、任务类型关联起来看。
3. 拒绝策略与线程工厂：容易被忽视，但实战必备
3.1 四种拒绝策略的语义对比
当线程池已经满了、队列也满了，新任务就会触发拒绝策略。ThreadPoolExecutor内置了四个实现：
| 策略 | 行为 | 风险点 |
|---|---|---|
| AbortPolicy | 直接抛出RejectedExecutionException | 默认策略，任务不做处理会丢失 |
| CallerRunsPolicy | 由提交任务的线程自己执行该任务 | 会在调用方线程消耗时间，有背压效果 |
| DiscardPolicy | 静默丢弃任务 | 业务无感知，可能造成数据丢失 |
| DiscardOldestPolicy | 丢弃队列中最旧的任务，再尝试提交 | 可能丢弃关键任务 |
面试如果只让你答这四个策略的名字和含义，那太容易了。如果面试官追问“你们项目用的哪种，为什么”，情况就不一样了。我实际项目里用得最多的是CallerRunsPolicy，原因后面单独展开。
还有一个很多人不知道的冷门策略：可以用RejectedExecutionHandler自定义策略。丢掉任务的时候你可以在自定义策略里写监控日志、打点告警、或者把任务转发到另一个专门处理溢出的降级线程池。这种兜底逻辑线上非常实用，比如促销峰值时订单处理线程池满了，你可以把多余的打包通知任务直接转到MQ，让下游慢慢消费。
3.2 CallerRunsPolicy的价值：把压力传回给调用方
CallerRunsPolicy的官方描述是“由调用线程执行被拒绝的任务”。这意味着执行任务的线程变成了提交任务的线程，比如Web请求线程。这样做的好处有两个：
一方面，任务不会丢失，调用方自己花时间把这个活儿干完了；另一方面，这是一种自然限流——调用方线程忙着执行线程池的积压任务，就会降低它提交新任务的速率，系统就形成了一个“处理慢→提交慢”的负反馈闭环。我有个支付回调处理的场景，回调接口收到下游通知后把任务丢进线程池做异步业务处理，用的就是CallerRunsPolicy，高并发下回调全部被当前请求线程消化掉，反而保证了报文不丢。
当然，它也有代价：如果任务太重，“调用方线程执行任务”的耗时就会影响接口的响应时间。所以使用时要想清楚任务耗时，别让调用方线程背着几个大任务跑。
3.3 自定义ThreadFactory：不只是给线程起个名字
ThreadFactory经常被一笔带过，但在线上一旦出了线程池问题，一个好的线程工厂能让你省下大量排查时间。默认的线程名是“pool-1-thread-1”这种，多个线程池一起跑的时候根本分不清日志到底是哪个池子打的。自定义ThreadFactory给线程起一个业务相关的名字，比如“order-async-handler-thread”，日志排查时一眼就能定位到是哪个线程池的哪个线程。
ThreadFactory还有一个实用场景：设置线程的daemon属性。某些后台任务线程池使用非daemon线程又没有正确关闭，会导致JVM无法退出。另外你还可以在ThreadFactory里给线程设置UncaughtExceptionHandler，当线程因为未捕获异常退出时留一条完整的日志线索，这对线上问题复盘极其有帮助。
3.4 Executors内置线程池的隐患，逐个拆一遍
| 内置线程池 | 线程数设计 | 队列设计 | 主要问题 |
|---|---|---|---|
| newFixedThreadPool | 固定nThreads | 无界LinkedBlockingQueue | 队列无限堆积，OOM风险 |
| newCachedThreadPool | 0核心，Integer.MAX_VALUE最大 | SynchronousQueue | 极端并发下线程数失控，资源耗尽 |
| newSingleThreadExecutor | 单线程 | 无界LinkedBlockingQueue | 队列无界+单线程，积压风险极大 |
| newScheduledThreadPool | core固定，max无限 | DelayedWorkQueue | 最大线程数无限，任务堆积风险 |
这里有个共同点：除了CachedThreadPool的SynchronousQueue，其他几个都用了无界队列。无界队列的问题在于线程池永远不会触发拒绝策略，这看似“永不拒绝”，实际上是让系统丧失了对自身负载的判断能力，风险全部隐藏了。所以那句话是对的：不让用Executors，本质是逼你亲自去思考每个参数的含义。
4. 核心线程数到底怎么定：从经验公式到压测修正
4.1 CPU密集型和IO密集型，走的是两套思路
线程池参数里最被人追问的就是“核心线程数怎么设置”。网上能查到各种公式，我先说两条公认的基准线：
- CPU密集型任务：核心线程数可以设成CPU核数+1。加1是为了应付偶尔的内存页失效或者其他阻塞情况，让多出来的那个线程不被白白闲置。
- IO密集型任务：核心线程数经验公式是CPU核数×(1+IO等待时间/CPU计算时间)。如果IO等待时间和CPU计算时间差不多，那基本就是CPU核数翻倍。
这个公式怎么用？比如一个8核机器，接口里大部分时间在调用远程服务和读写数据库，CPU计算只花了20ms，但等待下游响应花了80ms。线程数就按8×(1+80/20)=40来起步。一个处于等待状态的线程是不消耗CPU的，它只是占着线程栈内存，所以多开几个到几十个线程完全是合理的。
4.2 参数推导的完整思考流程
光会套公式还不行，你还需要把任务总量、允许的排队时间、单任务耗时这三件事串起来。我举一个订单状态同步任务的例子：
假设每秒钟进来1000个订单状态变更任务，每个任务平均耗时50ms，业务方允许任务排队最长时间为5秒。那么队列容量至少要等于5秒内新增的任务量，也就是1000×5=5000个。核心线程数按“单位时间可处理的任务数”反推：每个线程每秒能处理1000/50=20个任务，处理1000个每秒的任务就需要50个线程，这是理想情况。实际上还要考虑任务耗时有波动、GC停顿、下游变慢等额外因素，所以先把核心线程数调到60~80之间去做压测，观察执行耗时和队列积压情况再微调。
这里有一个很多人认识的误区：核心线程数不是越大越好。线程太多，CPU上下文切换成本会超过多线程的收益，尤其在计算密集场景下，线程数超过CPU核数收益反而是负的。IO密集场景线程数多一点没关系，但也要考虑每个线程占用的内存和其他资源开销。
4.3 动态线程池：参数配完了还能不能改
“八股”只讲静态配置，但真实生产环境里流量是波动的，固定的参数往往不够用。ThreadPoolExecutor本身提供了一套动态调整的方法：setCorePoolSize、setMaximumPoolSize、setKeepAliveTime。线程池会根据这些新参数逐步调整线程数量，不用重启应用。
如果你用了Nacos或Apollo这类配置中心，完全可以做一套“参数热更新”的机制：配置中心里维护线程池参数，监听配置变更后直接调用对应方法完成调整，再把核心指标输出到监控系统里。我自己维护过一套类似组件，流程不复杂，但收益很实在——大促前调大容量、流量回落后自动回收，这些都做到了动态生效。
另外一个值得加的监控点是ThreadPoolExecutor暴露的几个方法：getActiveCount()、getQueue().size()、getTaskCount()、getCompletedTaskCount()。把这些指标定时上报到监控平台，你能直观看到线程池有没有打满、队列有没有积压、拒绝有没有发生，这才是调优的数据基础。
4.4 参数调整的经验原则
说到底，参数调整不是一次性行为，而是一个持续调优的过程。我个人的经验是：
先按任务类型套公式算出起点值，然后构造一个流量模拟压测场景，观察线程池的状态指标，一点一点微调。调参的时候每次只改变一个变量，不要多个参数一起动，否则根本说不清楚效果是哪一步产生的。核心线程数、队列容量、拒绝策略这三者的搭配，需要反复实测才能找到最优解。
5. 实操场景与问题排查实录
5.1 场景一：日志异步落地的线程池配置
异步打日志是很常见的需求，核心诉求是“别因为日志拖慢业务”，但也不能让日志丢失得太离谱。我参考过的配置思路如下：
ThreadPoolExecutor logExecutor = new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBolckingQueue<>(10000), new ThreadFactory() { private final AtomicInteger index = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { Thread t = new Thread(r); t.setName("async-log-writer-" + index.getAndIncrement()); t.setDaemon(true); return t; } }, new ThreadPoolExecutor.DiscardOldestPolicy() );日志任务允许丢弃部分旧日志，所以用DiscardOldestPolicy是合理的。线程数不需要多，但队列要给足，保证瞬时高峰时多数日志能落进队列。daemon线程设定成true，避免了线程池没有关闭导致JVM无法退出。
有人可能会问，日志异步写为什么不用消息队列？确实很多项目直接用MQ或者类似Disruptor的高性能队列来做，但线程池方案本身就够用了，重点是线程数和队列容量的配比要符合日志流量的峰值得出的数据。从监控里看一下每秒日志条数和平均单条写入耗时，剂量自然就出来了。
5.2 场景二：秒杀系统的请求处理线程池
秒杀场景比日志更复杂，因为线上流量非常大，而且用户请求需要快速响应，系统必须防止被流量瞬间冲爆。这个场景我见过一种常见的做法：用有界队列+CallerRunsPolicy组合，同时细化分级。
假设商品详情页瞬时QPS是10万，但真正的库存扣减操作只有1000QPS，那扣减库存可以走专门的线程池：核心线程数20、最大线程数50、队列容量2000。超过队列负载的任务触发CallerRunsPolicy，由请求线程自行处理，相当于在入口做了一层限流降级。而库存扣减成功与否通过返回值或者CompletableFuture异步回调告知用户，不会因为线程池满了直接丢失请求。
这个配置并不能解决所有问题，但思路是对的：把不同耗时、不同重要性的任务拆到不同线程池，避免互相影响。最怕的是一个线程池里既有快任务又有慢任务，慢任务把队列占满了，快任务也进不来了。
5.3 线程池常见问题排查技巧一览
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 任务执行被无限拉长 | 队列积压严重，核心线程不足 | 监控getQueue().size()，分析单任务耗时 |
| 拒绝异常频繁出现 | 队列太小或max线程数不够 | 抓RejectedExecutionException日志，观察请求峰值 |
| 线程池核心线程数高但CPU跑不满 | 任务大部分时间在阻塞等待 | jstack查看线程状态分布，确认是否IO密集型任务 |
| 线程数一直没达到maximumPoolSize | 队列还没满，所以不会扩容 | 确认队列容量是否过大、任务是否长期排队 |
| 日志中线程名全部是pool-1-thread-* | 用了默认ThreadFactory | 自定义ThreadFactory，按业务拆分线程池 |
| 线程池任务不执行但线程活着 | 队列为空，所有线程都在等待 | 查看任务提交逻辑，确认是否任务实际没有入池 |
这个表里的现象，我一个一个踩过。尤其是“线程数一直没达到maximumPoolSize”这个现象，很多人看了监控还以为线程池扩不了容，其实只是队列还没满。线程池的正常设计就是如此：扩容是压到极限之后的最后手段，不是繁忙就直接扩。
5.4 线程池关闭的正确姿势
线程池关闭这块，接口层面常常被忽略，但它恰恰是内存泄漏和线程泄漏的常见来源。shutdown()方法会等所有已提交任务执行完才关闭，新任务会被拒绝；shutdownNow()则是立刻中断正在执行的任务并返回队列中还没执行的任务列表。两者语义差别很大，选择取决于你的业务可以容忍哪种停机方式。
关闭之后最好再调用awaitTermination等待一段时间，让线程池真正结束。如果超时还没结束，说明有任务卡住了，这时候可以根据场景决定是否强制shutdownNow。我用过一个简单的“两阶段关闭”策略：先shutdown，等待超时后如果发现线程还活着，再shutdownNow并记录卡住的线程栈，让运维定位问题。
关于线程池如何优雅关闭，其实有很多文章讲，但实操里最常见的错误是：应用停机时线程池还在跑任务，而且没有做任何关闭处理，导致线程被强制结束，任务没有落库或者没推送出去。一定要在Spring的@PreDestroy里做一层兜底，把队列里剩余的任务妥善保存。
5.5 线程复用机制、异常处理和submit与execute的区别
线程池面试还有几个高频细节要提一下。第一个是线程复用。很多文章只是简单说“复用”，但底层的Worker循环值得了解：每个Worker都是一个自带锁的线程，它的run方法里有一个while循环，不断从阻塞队列里getTask()，取到任务就执行run()，取不到就根据超时逻辑退出。理解了这个循环，你就明白为什么核心线程有空闲它也不会去抢任务，因为线程池是先创建新的核心线程，而不是优先复用空闲线程——这正好对应了前面的执行流程。
第二个是异常处理。在runWorker方法里，如果某个任务抛出了RuntimeException，这个线程会退出，线程池会再创建一个新线程来顶替它，前提是当前线程数仍大于corePoolSize的时候会补回到核心数。任务里的异常默认不会经过外层调用方可见，所以如果你不在Runnable内部做try-catch，异常就被静默吃掉或者只打印到stderr。实际项目中建议每个任务内部都包裹自己的异常处理逻辑，或者从自定义ThreadFactory中设置UncaughtExceptionHandler，这样任何一个线程因异常退出时，起码能在日志里看到线索。
第三个是execute和submit的区别。execute接收Runnable，是void方法；submit接收Callable或Runnable，返回Future。用submit传Runnable的话，即使任务内部抛异常也不会立刻让调用方感知，只有调future.get()才会暴露。很多人喜欢用submit，但忘了拿返回值，异常就消失了。如果你不关心异步任务的结果，直接用execute反而更干净，省得future泄漏在内存里。当然，如果你要做监控统计耗时和结果，submit拿Future是必要的，但一定要在任务内部做好异常兜底，别让异常藏到调用get()的时候才爆出来。
最后分享一点我的实际感受
把线程池这些基础点理清楚之后，最明显的感受是：面试里被问“ThreadPoolExecutor执行流程”的时候，我不再只是干巴巴背顺序，而是能像讲自己项目里的代码一样，把队列、扩容、拒绝策略的联动逻辑串起来说。这种“从八股到实战”的转换，靠的是理解每个参数背后的动机，而不只是记住结论。
另外建议新手朋友在线下自己写一个小Demo，把corePoolSize、队列容量、maximumPoolSize设成很极端的值，用Sleep模拟慢任务，然后观察线程池状态纷纷变化。我曾经用一次非常极端的测试，把有界队列容量设为1、线程数设为2，在循环里不断submit慢任务，亲眼看到线程池的变化过程和自定义拒绝策略打出的日志，整个过程对理解线程池机制帮助特别大。这种从“眼睛会了”到“手会了”的过程，单靠背八股可完成不了。
