Java线程池从入门到实战：核心参数、阻塞队列与拒绝策略全解析

1. 先从一次线上事故说起：为什么每个项目都需要线程池

大概两三年前，我接手过一个老项目，核心业务流程里有一步是调用外部 API 拉取数据，然后逐条处理。最初的写法非常简单直接：需要并发的时候就new Thread(() -> { ... }).start()，一个请求进来开几个线程，数据量大就多开几个，看着挺美，直到有一天线上告警直接刷屏——应用无响应，CPU 被打满，紧接着是java.lang.OutOfMemoryError: unable to create new native thread。

事后复盘，原因一点也不神秘：无限制地创建线程，每条线程都要占用独立的栈内存（默认 1MB，甚至可以在 JVM 参数里调大），操作系统层面的线程句柄、上下文切换开销也全部压在服务上。当并发任务远超机器承载能力时，线程还没跑完，内存和句柄先耗尽，整个进程直接瘫了。

从那之后我算是彻底想明白了一个道理：多线程编程里，真正难的不是怎么写并发代码，而是怎么管好线程本身。而线程池，就是用来解决这个问题的标准答案——它把线程的创建、复用、调度、销毁统一收口，你只负责提交任务，什么时候新建线程、什么时候排队、什么时候拒绝，全部交给池子内部去决策。

这篇文章我想把线程池这件事从头到尾聊透，包括七个核心参数各自到底是什么意思、任务提交之后内部是怎么流转的、阻塞队列到底怎么选、最大线程数和 JVM 剩余线程的误解从哪来、拒绝策略在生产环境里怎么配，以及一些单靠看文档根本学不到的踩坑经验。不管你是刚接触多线程的 Java 开发者，还是写 C++、C#、Python 时也遇到类似线程管理问题的同行，这篇内容应该都能帮你少走不少弯路。

2. 理解线程池之前，先理解它到底替你解决了什么

2.1 创建线程的代价比你想象中高得多

很多人对“线程很重”没有直观感受，因为本地随便跑几十个线程毫无压力。但到了生产环境，一台 4C8G 的机器上同时跑几百个任务时，问题就来了。

先看数据：Java 中创建一个线程，本质上是一次pthread_create系统调用，需要完成线程栈分配、线程控制块初始化、调度器注册等一堆操作。这里我拿一个简单的压测数据说明问题——在普通 Linux 机器上，创建并销毁一个线程大约要花 50 到 100 微秒，这还不算 JVM 层面的额外开销。如果你的业务请求平均处理时间只有 10 毫秒，创建一个线程的时间占到了整体耗时的 1%，看起来不多，但当一个接口需要并发处理几十个任务时，线程创建销毁的总耗时就会明显拖慢响应。

更要命的是上下文切换。CPU 核数是固定的（比如 8 核），当活跃线程数超过 8 个时，操作系统就必须不停地让这个线程让出 CPU、让那个线程上 CPU，这个过程需要保存和恢复寄存器、程序计数器、栈指针等一大堆现场状态。有数据显示，频繁的上下文切换会让真实计算吞吐量下降 30% 到 50%。你可以把 CPU 想象成一个只能同时接待一位顾客的柜台，线程就是排队办业务的人，如果顾客每说一句话就要换一个人来接待，效率一定惨不忍睹。

2.2 线程池把"用线程"变成"用池子"

线程池的思路很简单粗暴：提前创建好一批线程放在池子里，有任务来了就从池子里取一个空闲线程去执行，执行完线程不销毁，而是回到池子里继续等待下一个任务。这就把“创建线程→执行任务→销毁线程”的流程，变成了“从池子里借线程→执行任务→归还线程”。

这个模式带来的收益非常直接：

• 线程复用，省掉了频繁创建和销毁的开销；
• 控制并发上限，避免无脑开线程把内存和 CPU 打爆；
• 统一管理生命周期，任务排队、超时、拒绝都有明确的策略可配。

可以这样理解：不使用线程池就像每个顾客来柜台买东西都要现场培训一个新收银员，收银员干完活立刻离职；用了线程池就像店里固定养着一批熟练收银员，顾客再多也只是排队等位，绝对不会出现临时拉壮丁收到一半人跑了的情况。

3. 线程池的七个参数：每一个都值得弄到骨头里

Java 中最常用的线程池实现是ThreadPoolExecutor，它最完整的构造函数需要七个参数，网上把它叫做“线程池的七个参数”。很多面试题和配置指南都会考这个，但大多数人只是死记硬背，不知道每个参数设计出来到底是为了应对什么场景。这里我一个个拆开讲。

3.1 corePoolSize（核心线程数）与 maximumPoolSize（最大线程数）

这两个参数放一起说，因为它们共同决定了线程数的弹性区间。

• corePoolSize：核心线程数，也就是池子平时保底的线程数量。默认情况下，核心线程创建之后即使空闲也不会被销毁。
• maximumPoolSize：最大线程数，也就是池子里线程数量的上限，含核心线程在内。

举个例子：corePoolSize=5，maximumPoolSize=10，意思是正常情况下池子里有 5 个线程待命；如果 5 个线程全忙，新的任务进来后会先走队列（后面细说）；当队列也满了之后，线程池才会在 5 个核心线程的基础上继续创建线程，直到总数达到 10 个。

这里有个很经典的误区：不是任务一来就直接创建线程到 maximumPoolSize。很多初学者以为 max 是“最大并发数，任务来了就开线程去跑”，实际上线程池的扩容逻辑是分阶段、有条件的，而这个条件就是队列满了。这个顺序问题我在下一章讲任务流转时再展开。

3.2 keepAliveTime（空闲线程存活时间）与 unit（时间单位）

• keepAliveTime：非核心线程空闲多久之后会被回收。
• unit：上面这个时间的时间单位，比如TimeUnit.SECONDS、TimeUnit.MILLISECONDS。

为什么要回收空闲非核心线程？因为线程本身是消耗资源的，高峰期临时扩容到 10 个线程，业务低谷期只有 2 个任务在跑，剩下 8 个线程闲着也是白白占内存。通过设置keepAliveTime=60加unit=TimeUnit.SECONDS，意味着非核心线程空闲超过 60 秒就会被回收，这样线程数会自动回落到corePoolSize，实现弹性伸缩。

补充一个细节：通过allowCoreThreadTimeOut(true)可以设置核心线程同样支持超时回收，但一般默认不开启，因为核心线程是需要保底的。

3.3 workQueue（任务队列）

核心线程全部忙碌时，新进入的任务会先放到队列里排队等待。这个队列的类型选择对线程池行为影响极大，我用单独一章专门讲阻塞队列选型，这里先记住一个结论：队列有界还是无界，直接决定了“队列满了之后下一步到底发生什么”。

3.4 threadFactory（线程工厂）

线程工厂的作用是创建线程。为什么需要自定义？因为默认的线程工厂创建的线程名字是pool-N-thread-M，排查问题的时候根本看不出来这个线程是哪个业务模块的。生产环境里，我强烈建议自定义ThreadFactory，至少做两件事：起一个有意义的名字，比如order-async-thread；把线程设置为非守护线程（默认已经是非守护，但显式设置更安全），并设置合理的异常处理逻辑。

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

3.5 RejectedExecutionHandler（拒绝策略）

当队列满了、线程数也到最大值了，再有新任务进来时，线程池会触发拒绝策略。Java 自带了四种实现，后面我会专门拿一章来分析它们在生产环境里的适用场景，这里先提个醒：默认的AbortPolicy会直接抛RejectedExecutionException，大多数业务场景下这个异常如果不处理就是一次隐形的任务丢失。

ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), customThreadFactory, new ThreadPoolExecutor.CallerRunsPolicy() );

上面这段代码是一个基本的线程池配置，把七个参数全用上了。实际项目中需要根据业务调整队列容量和拒绝策略，我后面都会讲。

4. 任务提交之后，线程池内部到底按什么顺序运转

4.1 execute 之后发生了什么

ThreadPoolExecutor.execute(Runnable command)的内部逻辑其实是状态机式地分好几层判断，网上有大量源码分析，这里我用人类语言把关键路径捋清楚：

1. 如果当前工作线程数 <corePoolSize，直接新建一个核心线程执行任务，即使池子里已经有空闲线程，也一样先新建——因为核心线程是“保底数量”，能多攒一个是一个。
2. 如果当前工作线程数 >=corePoolSize，尝试把任务放入workQueue队列。入队成功则等待核心线程空闲后取出执行。
3. 如果队列已经满了（有界队列才会出现），尝试新建线程执行任务，但要求当前线程数 <maximumPoolSize才会创建。
4. 如果线程数已经等于maximumPoolSize，队列也满，触发拒绝策略。

这个顺序非常关键，它决定了线程池的“脾性”。线程池优先用队列缓冲，而不是优先扩容到最大线程数，这种设计是为了应对突发但短时的流量——先把任务存起来，让请求快速返回，再慢慢消费。

4.2 无界队列陷阱：为什么 maximumPoolSize 可能形同虚设

如果你用LinkedBlockingQueue但不指定容量（默认是Integer.MAX_VALUE），那么队列几乎永远不会满。这意味着什么？意味着线程数永远不会超过corePoolSize，任务只会无限堆积在队列里。

这是很多线上故障的根源：明明配置了maximumPoolSize=200，看起来并发能力很强，实际上核心线程只有 10 个，队列无界，高峰期 10 万个任务全堵在队列里。内存没爆（任务对象还在，占着堆空间），但任务的等待时间从几十毫秒变成几十秒，调用方疯狂超时，你以为自己在做异步削峰，实际上只是把“马上失败”变成“慢性死亡”。

我在项目里见过不止一次这种配置，配置的人还特别自豪地跟领导说“我用了无界队列，任务绝不会丢失”。任务确实不丢，但业务的实时性全没了。所以有界队列是生产环境的基本要求，队列容量需要压测后确定。

4.3 为什么要关注队列容量大小

队列容量太小，容易触发扩容甚至拒绝策略；容量太大，任务积压到一定程度后响应时间依然会爆。一个常见的起点是：核心线程数 × (单个任务平均耗时 / 期望的最长排队等待时间)之类的换算，但每个业务差异很大，最好的方式还是压测。

下面这张表列出的是队列选择时需要考量的几个维度：

5. 阻塞队列怎么选：ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue、PriorityBlockingQueue、DelayQueue

聊到线程池，阻塞队列是绕不开的。Java 里可用作线程池队列的类型不少，这里我把常见的几种放一起对比，方便你直接照着选。

5.1 ArrayBlockingQueue：有界数组队列，生产环境默认首选

ArrayBlockingQueue必须指定容量，它是一个由数组实现的有界队列，先进先出。为什么说它是生产环境默认首选？因为“必须有界”这本身就是生产环境最关键的约束，容量一满，多余的请求立刻暴露出来，不会被闷在队列里拖垮整个服务。

它的缺点也很明显：队列容量是固定的，不支持动态扩容。如果你的业务峰值流量和日常流量差距非常大，容量配大了日常内存浪费，配小了高峰期直接拒绝。这种情况下可以用动态队列，我后面讲动态线程池时会提。

5.2 LinkedBlockingQueue：链表队列，有界无界都可以

LinkedBlockingQueue是链表实现，可以指定容量也可以不指定。前面说了，不指定就是无界，有风险；指定容量后，它和ArrayBlockingQueue的区别主要在于底层数据结构带来的吞吐量差异，实际场景里差别通常不大。

LinkedBlockingQueue 在设置容量后，即使入队时线程是并发的，也能保证线程安全，吞吐性能比 ArrayBlockingQueue 略高，因为它的入队和出队使用的是两把不同的锁，并发操作时互不阻塞。

5.3 SynchronousQueue：不存任务的队列

这个队列非常特殊，它内部不存储任何元素。每个入队的操作必须等待另一个线程来取，反之亦然。换句话说，SynchronousQueue就是线程之间交接任务的握手通道，没有缓冲能力。

当线程池使用SynchronousQueue时，提交任务永远入队失败，于是线程池会立刻尝试创建新线程去执行。这个队列配合一个比较大的maximumPoolSize，可以理解为“只要任务来了就直接开线程，不排队”。Executors.newCachedThreadPool()就是这种模式，它给每个任务都创建一个新线程（复用空闲线程），空闲线程 60 秒回收。

这种模式适合大量短小、异步、耗时不稳定的任务，但不适合高并发核心链路，因为线程数量的控制全靠maximumPoolSize，一旦任务量超过承载上限，拒绝策略马上触发，而且线程创建频繁也会带来开销。

5.4 PriorityBlockingQueue：带优先级的无界队列

PriorityBlockingQueue是一个支持优先级排序的无界队列，队列中的元素会按自然顺序或自定义Comparator排列。它一般配合corePoolSize使用，因为无界队列导致maximumPoolSize基本不生效。

使用场景很清晰：任务之间有明确的优先级差异，比如排队请求中 VIP 用户优先处理、系统告警优先于普通日志上报。但要注意，无界队列的任务积压风险依然存在，优先级再高，业务整体吞吐不够时还是会被拖死。

5.5 DelayQueue：延迟执行队列

DelayQueue也是一个无界队列，它的特殊之处在于元素只有到达指定延迟时间后才能被取出。ScheduledThreadPoolExecutor就是用它来实现定时和延迟任务的。

如果你需要“任务提交后延迟 N 秒执行”或者“每隔 N 秒周期执行”，可以直接考虑使用ScheduledThreadPoolExecutor，不需要自己手工搭配 DelayQueue。

5.6 我实际项目中是怎么选的

说了这么多理论，直接给结论。我在大多数业务项目里会遵循这样一个选择逻辑：

需要补充的是，队列无界带来的最大风险是“系统失控”，这种失控往往比拒绝策略更可怕。拒绝是明着告诉你“扛不住了”，无界队列是让你在毫无感知的情况下持续恶化。两种我都踩过坑，前者好查好补救，后者通常要等告警系统报警才发现。

6. 线程池大小怎么定：别再相信网上的公式

6.1 计算密集型与 IO 密集型的经典配比

网上流传最广的线程数公式是：

• 计算密集型（CPU 密集型）：线程数 ≈ CPU 核数 + 1；
• IO 密集型：线程数 ≈ CPU 核数 × 2（或者 × (1 + 等待时间 / 计算时间)）。

这个公式的方向是对的，但如果你直接照抄，很容易翻车。原因在于它忽略了任务队列的作用，也忽略了 JVM 本身的 GC、锁竞争等因素。说白了，公式只能作为初始参考值，真正可靠的方式是压测。

我先解释一下 IO 密集型的底层逻辑。一个 HTTP 请求处理任务，真正耗 CPU 的时间可能只有 5 毫秒，剩下 95 毫秒都在等下游接口返回——这个“等待”期间线程其实是被挂起的，不占用 CPU。所以 IO 密集型任务可以有更多线程同时存在，让 CPU 在等待间隙去执行别的任务。这就是为什么 IO 密集型线程数可以设置得更大。

6.2 最大线程数和 JVM 剩余线程的误解

热搜词里有一条“线程池设置最大线程数是jvm剩余可用线程”，我猜这句话表达的是一个很常见的疑问：既然线程太占资源，那我设置maximumPoolSize的时候，是不是要考虑 JVM 当前还能创建多少线程？

这里需要澄清一个重要事实：JVM 剩余可用线程不是一个稳定的运行时数值，因为 Java 线程和操作系统线程是一一对应的，能创建多少线程取决于操作系统进程级的线程数限制、可用内存、栈大小等多个因素。你不能在代码里写死“最大线程数 = JVM 剩余线程数”，你也不可能在配置线程池时实时去查剩余线程数——这个数本身在并发场景下是动态变化的。

更务实的做法是：根据业务模型压测出一个安全值，再留 30% 到 50% 的余量。在最坏的情况下，就算所有线程池同时达到峰值，总线程数也应该远低于操作系统允许的线程数上限。

可以在生产环境用Thread.activeCount()或ps -eLf | wc -l观察进程总线程数，作为参照，但不要试图把它作为一个精确控制线程池配置的动态依据。

6.3 多线程池共存时的总量控制

一个大型应用往往不止一个线程池：有处理订单的、有处理消息推送的、有做数据同步的。如果每个线程池都按自己的峰值需求去配置，所有线程池同时打满时，总线程数可能远超系统承受能力。

所以总量控制是架构层面必须考虑的事。做法也不复杂：

• 明确每个线程池的核心线程数总和，比如控制在CPU 核数 × 3以内；
• 最大线程数总和控制在CPU 核数 × 10以内（IO 密集型可酌情放宽）；
• 每个线程池设置独立的队列容量，避免任务全部堆积到同一个池子。

我曾经在项目里见过一个服务部署了 8 个线程池，每个池子 maximumPoolSize 都配了 50，总线程数理论上可以到 400。那台机器只有 4 核 8G，结果一到高峰期，400 个线程互相争抢 CPU，整体吞吐反而远低于单线程串行处理。线程不是越多越好，过度并发带来的上下文切换成本会吃掉所有收益。

7. 拒绝策略：生产环境一定要认真对待

7.1 四种内置策略对比

7.2 默认的 AbortPolicy 为什么危险

AbortPolicy的坑在于：很多人在调用execute()提交任务时，压根没有捕获RejectedExecutionException，线程池拒绝后异常直接抛出到上层，但上层往往只打了一行日志，代码继续往后走——任务呢？丢了。

我见过一个典型的案例：一个异步通知服务，使用默认拒绝策略，没人处理异常。高峰期任务一被拒绝，用户收不到通知，业务方反复排查都找不到原因，最后把日志翻出来才发现大量RejectedExecutionException静默吞掉了。这个问题的根子不在线程池配置，而在于没有明确“被拒绝的任务应该去哪儿”。

7.3 生产环境推荐的拒绝策略组合

根据我的经验，生产环境通常需要按业务重要性选择不同的策略：

• 核心业务，任务不能丢：自定义拒绝策略，把任务保存到本地数据库或消息队列，后续补偿重试。比如：

RejectedExecutionHandler customHandler = (r, executor) -> { // 把 r 保存到 MQ 或数据库，稍后重试 saveToRetryQueue(r); };

• 允许降级的业务：使用CallerRunsPolicy，让提交任务的线程自己执行。这个策略有个额外好处：提交方会因此变慢，自然地背压回源，下游系统不会被继续猛灌流量。但它也有代价——提交线程如果是一个 Web 请求线程，这个请求的响应时间会变长。
• 不重要的离线任务：使用DiscardPolicy或DiscardOldestPolicy，保证主链路不受影响。

这里要提醒一件事：CallerRunsPolicy并非在所有场景都安全。如果你的提交线程是 FastJSON 的序列化线程或者主业务线程池中的线程，它执行任务时如果发生阻塞（比如调下游接口超时），会直接把主线程拖死，反而影响正常请求。所以使用之前先想清楚“谁来执行这个被拒绝的任务”会不会引入新的耦合。

8. 实战配置与调优：我用的线程池模板和踩坑记录

8.1 一个可以抄作业的基础配置模板

结合前面所有内容，这里给一个比较稳妥的通用线程池配置方案。以一台 4C8G 的服务器、主要业务是 IO 密集型（调用下游 API、读数据库、写缓存）为例：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 8, // corePoolSize = CPU核数 × 2 16, // maximumPoolSize = CPU核数 × 4 60L, TimeUnit.SECONDS, // 非核心线程空闲60秒回收 new ArrayBlockingQueue<>(500), // 有界队列，容量需要压测确定 new NamedThreadFactory("biz-order"), // 自定义线程工厂 new ThreadPoolExecutor.CallerRunsPolicy() // 降级策略 );

这个配置的逻辑是：

• 核心线程 8 个，保证平时池子里有一批线程随时待命；
• 最大线程 16 个，突发流量时最多翻一倍；
• 队列容量 500，限制任务积压规模；
• 拒绝策略用 CallerRunsPolicy，确保任务不丢，同时通过背压控制提交速度。

8.2 核心线程预热

线程池的核心线程是在任务提交后才开始创建的，不是线程池创建时一次性建好。也就是说，如果项目启动后第一个高峰期在早上 10 点，但第一次真正的数据量暴增发生在 10 点零几分，那这几分钟内线程池还在忙着创建线程，任务执行速度会偏慢。

解决方案很简单：在应用启动后主动调用prestartAllCoreThreads()，把核心线程全部提前初始化好。这个方法适合核心线程数不大（比如 50 以下）的场景，如果你核心线程数配了 500，预热本身就会消耗不少资源，不建议使用。

executor.prestartAllCoreThreads();

8.3 动态线程池：配置不是写死之后就完事

很多团队把线程池参数在代码里写死，上线后就不再动了。等到业务流量涨了，线程池变成瓶颈，才发现要改代码、发版、重启，大动干戈。

成熟的做法是引入动态线程池方案。思路大致是：线程池的配置（核心线程数、最大线程数、队列容量）放到配置中心（如 Apollo、Nacos），修改配置后实时刷新到内存中的ThreadPoolExecutor对象。ThreadPoolExecutor本身提供了setCorePoolSize()、setMaximumPoolSize()等方法，支持运行时调整。

我自己在项目里实现过一个简单的动态线程池组件，核心就这几步：

1. 监听配置中心的配置变更；
2. 将新配置同步到ThreadPoolExecutor实例；
3. 记录调整前后的线程数、活跃数、队列积压数，方便对比效果。

当线上出现“任务积压变多，但线程没跑满”的情况时，我可以在几分钟内把核心线程数调大，不需要发版。这才是线程池在生产环境里最舒服的使用姿势。

8.4 监控线程池运行状态

线程池是黑盒还是白盒，全看你有没有监控。一个标准的线程池监控至少要覆盖以下指标：

• 当前线程数（getPoolSize()）
• 活跃线程数（getActiveCount()）
• 核心线程数、最大线程数（配置值）
• 队列中的任务数（getQueue().size()）
• 已完成任务总数（getCompletedTaskCount()）
• 被拒绝的任务数（需要自己通过RejectedExecutionHandler统计）

我习惯的做法是，每 30 秒采集一次这些指标，上报到 Prometheus 或自研监控系统，并在队列积压数、活跃线程占比超过阈值时发出告警。比如队列积压数持续增长且活跃线程数长期等于最大线程数，基本可以断定线程池已经到瓶颈了，必须赶紧介入。

// 简单示例：定时采集线程池指标 ScheduledExecutorService monitorScheduler = Executors.newScheduledThreadPool(1); monitorScheduler.scheduleAtFixedRate(() -> { int poolSize = executor.getPoolSize(); int activeCount = executor.getActiveCount(); int queueSize = executor.getQueue().size(); // 上报到监控系统 }, 0, 30, TimeUnit.SECONDS);

8.5 踩过的坑：线程池与 ThreadLocal 的恩怨

这里必须单独拎出来说说ThreadLocal在线程池环境下的坑，很多人在这上面栽过跟头。

在线程池中，线程是复用的，不是每次新建。如果你在一个任务里往ThreadLocal里塞了值，任务执行完没有清理，下一个任务（可能是另一个用户的请求）就会读到上一个任务的残留数据。这在 Web 应用中尤其危险：用户 A 的登录信息被用户 B 的请求读到了，轻则数据错乱，重则越权事故。

而且更隐蔽的是，ThreadLocal里通常存的是对象引用，如果这个对象还被其他地方持有，线程池复用时会造成内存泄漏——对象明明已经没用了，却因为线程一直被池子留着，ThreadLocal的 Entry 永远无法被回收。

处理方案就一句话：在线程池中，每个任务结束前必须清理 ThreadLocal。规范做法是 try-finally 包裹：

try { // 业务逻辑 doSomething(); } finally { threadLocal.remove(); }

如果你的项目用了像TransmittableThreadLocal这样的增强组件，也一定要理解底层原理，别指望框架自动处理一切。

9. 面试里那些高频问题，我帮你把答题思路理一遍

9.1 线程池的核心参数和执行流程

这可以说是 Java 多线程面试第一题，答题节奏建议这样：

先说七个参数：核心线程数、最大线程数、空闲时间、时间单位、阻塞队列、线程工厂、拒绝策略。

再说执行流程，按顺序分四步：

• 线程数小于核心线程数时，新建线程执行任务；
• 超过核心线程数时，任务入队；
• 队列满且线程数小于最大线程数时，创建新线程；
• 队列满且线程数已达最大线程数时，执行拒绝策略。

面试官如果追问“那任务入队失败会怎样”，就把第 3 步和第 4 步讲清楚即可。

9.2 为什么不用 Executors 提供的快捷方法

Executors.newFixedThreadPool()、Executors.newCachedThreadPool()、Executors.newScheduledThreadPool()是很多人图方便直接用的工具方法，但《阿里巴巴 Java 开发手册》明确不建议使用，原因是：

• newFixedThreadPool和newSingleThreadExecutor使用的是无界LinkedBlockingQueue，队列容量是Integer.MAX_VALUE，任务堆积可能导致 OOM；
• newCachedThreadPool使用SynchronousQueue，并且maximumPoolSize是Integer.MAX_VALUE，高并发下可能创建过多线程，导致资源耗尽。

所以我在面试时如果被问到，一般先正面回答这个问题，然后补一句：项目里导出的线程池，通常都是自己通过ThreadPoolExecutor构造函数创建，参数可控、行为可预期、便于监控。

9.3 如何合理设置线程池大小

这个问题衡量的是你有没有真实落地经验，而不是背书能力。我的回答套路是：

先区分任务类型：CPU 密集型任务，线程数接近 CPU 核数；IO 密集型任务，线程数可以设为核心线程数的两倍甚至更多。然后强调这只是一个初始值，真实场景必须结合压测结果调整，同时考虑多个线程池的总额控制。

最后补一句很有分量的经验：配置线程池不是一劳永逸的，要通过监控数据持续调整，最好支持动态下发配置。

9.4 什么是线程池的饱和策略（拒绝策略）

先背出四种内置策略，然后一定结合实际场景说明。比如：

• 默认 AbortPolicy 适合对可靠性要求不高的场景；
• CallerRunsPolicy 适合需要背压降级但不想丢任务的场景；
• 自定义拒绝策略适合核心业务，把被拒绝的任务存入可靠存储并补偿。

关键是要让面试官感觉到“我真的在线上配过、踩过坑”，而不是单纯背概念。

10. 最后分享一点我的实践心得

线程池知识点看起来简单，就是七个参数一把梭，但实际上手之后，你会发现真正难的永远不是参数本身，而是对业务场景的理解和取舍。

我至今记得那次线程数打满导致服务雪崩的事故。复盘时我们发现，配置线程池的人并不是不懂参数，而是没有充分考虑“当任务来不及处理时，系统应该怎么表现”。后来我们把无界队列换成了有界队列，把默认拒绝策略换成了自定义补偿策略，加上监控告警和动态配置，同样的流量再打过来，系统虽然偶尔还是会触发拒绝，但每次拒绝都有记录、有补偿，不会出现无声无息的任务丢失。

如果你现在正准备优化项目里的线程池，我建议按这个顺序去检查：

• 第一，检查所有线程池的队列是不是有界的，无界队列直接换掉；
• 第二，确认拒绝策略有兜底，任务不会静默丢失；
• 第三，加上监控，至少覆盖线程数、活跃数、队列积压数、拒绝数；
• 第四，线程池参数不要写死，预留动态调整的能力。

等到这些基础问题都处理完，再去抠线程数具体是 8 还是 16，你会发现那些数字其实没那么重要。线程池的核心价值永远是六个字：可控、可观测、可恢复。把这三点做到位，多线程并发这道坎，你就已经迈过去一大半了。