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最大线程数也就是池子里线程数量的上限含核心线程在内。举个例子corePoolSize5maximumPoolSize10意思是正常情况下池子里有 5 个线程待命如果 5 个线程全忙新的任务进来后会先走队列后面细说当队列也满了之后线程池才会在 5 个核心线程的基础上继续创建线程直到总数达到 10 个。这里有个很经典的误区不是任务一来就直接创建线程到 maximumPoolSize。很多初学者以为 max 是“最大并发数任务来了就开线程去跑”实际上线程池的扩容逻辑是分阶段、有条件的而这个条件就是队列满了。这个顺序问题我在下一章讲任务流转时再展开。3.2 keepAliveTime空闲线程存活时间与 unit时间单位keepAliveTime非核心线程空闲多久之后会被回收。unit上面这个时间的时间单位比如TimeUnit.SECONDS、TimeUnit.MILLISECONDS。为什么要回收空闲非核心线程因为线程本身是消耗资源的高峰期临时扩容到 10 个线程业务低谷期只有 2 个任务在跑剩下 8 个线程闲着也是白白占内存。通过设置keepAliveTime60加unitTimeUnit.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)的内部逻辑其实是状态机式地分好几层判断网上有大量源码分析这里我用人类语言把关键路径捋清楚如果当前工作线程数 corePoolSize直接新建一个核心线程执行任务即使池子里已经有空闲线程也一样先新建——因为核心线程是“保底数量”能多攒一个是一个。如果当前工作线程数 corePoolSize尝试把任务放入workQueue队列。入队成功则等待核心线程空闲后取出执行。如果队列已经满了有界队列才会出现尝试新建线程执行任务但要求当前线程数 maximumPoolSize才会创建。如果线程数已经等于maximumPoolSize队列也满触发拒绝策略。这个顺序非常关键它决定了线程池的“脾性”。线程池优先用队列缓冲而不是优先扩容到最大线程数这种设计是为了应对突发但短时的流量——先把任务存起来让请求快速返回再慢慢消费。4.2 无界队列陷阱为什么 maximumPoolSize 可能形同虚设如果你用LinkedBlockingQueue但不指定容量默认是Integer.MAX_VALUE那么队列几乎永远不会满。这意味着什么意味着线程数永远不会超过corePoolSize任务只会无限堆积在队列里。这是很多线上故障的根源明明配置了maximumPoolSize200看起来并发能力很强实际上核心线程只有 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 我实际项目中是怎么选的说了这么多理论直接给结论。我在大多数业务项目里会遵循这样一个选择逻辑业务特点推荐队列原因高并发、任务频繁、要求响应快ArrayBlockingQueue有界控制积压、快速失败大量短小异步任务、不要求排队SynchronousQueue来一个处理一个任务有明确优先级PriorityBlockingQueue支持排序定时/延迟任务ScheduledThreadPoolExecutor 内置 DelayQueue开箱即用完全不允许任务丢失有界队列 自定义拒绝策略存储/重试不推无界队列需要补充的是队列无界带来的最大风险是“系统失控”这种失控往往比拒绝策略更可怕。拒绝是明着告诉你“扛不住了”无界队列是让你在毫无感知的情况下持续恶化。两种我都踩过坑前者好查好补救后者通常要等告警系统报警才发现。6. 线程池大小怎么定别再相信网上的公式6.1 计算密集型与 IO 密集型的经典配比网上流传最广的线程数公式是计算密集型CPU 密集型线程数 ≈ CPU 核数 1IO 密集型线程数 ≈ 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 四种内置策略对比策略行为适用场景风险AbortPolicy默认直接抛 RejectedExecutionException任务丢失可接受、有外部重试机制调用方可能感知不到异常CallerRunsPolicy任务不在线程池执行而是由提交任务的线程直接执行希望降低任务提交速率提交线程会被阻塞DiscardPolicy直接丢弃任务不抛异常任务不重要的场景如打点日志可能丢失关键任务DiscardOldestPolicy丢弃队列中最旧的任务把新任务入队旧任务已无意义的场景处理不当时任务顺序混乱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()等方法支持运行时调整。我自己在项目里实现过一个简单的动态线程池组件核心就这几步监听配置中心的配置变更将新配置同步到ThreadPoolExecutor实例记录调整前后的线程数、活跃数、队列积压数方便对比效果。当线上出现“任务积压变多但线程没跑满”的情况时我可以在几分钟内把核心线程数调大不需要发版。这才是线程池在生产环境里最舒服的使用姿势。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任务堆积可能导致 OOMnewCachedThreadPool使用SynchronousQueue并且maximumPoolSize是Integer.MAX_VALUE高并发下可能创建过多线程导致资源耗尽。所以我在面试时如果被问到一般先正面回答这个问题然后补一句项目里导出的线程池通常都是自己通过ThreadPoolExecutor构造函数创建参数可控、行为可预期、便于监控。9.3 如何合理设置线程池大小这个问题衡量的是你有没有真实落地经验而不是背书能力。我的回答套路是先区分任务类型CPU 密集型任务线程数接近 CPU 核数IO 密集型任务线程数可以设为核心线程数的两倍甚至更多。然后强调这只是一个初始值真实场景必须结合压测结果调整同时考虑多个线程池的总额控制。最后补一句很有分量的经验配置线程池不是一劳永逸的要通过监控数据持续调整最好支持动态下发配置。9.4 什么是线程池的饱和策略拒绝策略先背出四种内置策略然后一定结合实际场景说明。比如默认 AbortPolicy 适合对可靠性要求不高的场景CallerRunsPolicy 适合需要背压降级但不想丢任务的场景自定义拒绝策略适合核心业务把被拒绝的任务存入可靠存储并补偿。关键是要让面试官感觉到“我真的在线上配过、踩过坑”而不是单纯背概念。10. 最后分享一点我的实践心得线程池知识点看起来简单就是七个参数一把梭但实际上手之后你会发现真正难的永远不是参数本身而是对业务场景的理解和取舍。我至今记得那次线程数打满导致服务雪崩的事故。复盘时我们发现配置线程池的人并不是不懂参数而是没有充分考虑“当任务来不及处理时系统应该怎么表现”。后来我们把无界队列换成了有界队列把默认拒绝策略换成了自定义补偿策略加上监控告警和动态配置同样的流量再打过来系统虽然偶尔还是会触发拒绝但每次拒绝都有记录、有补偿不会出现无声无息的任务丢失。如果你现在正准备优化项目里的线程池我建议按这个顺序去检查第一检查所有线程池的队列是不是有界的无界队列直接换掉第二确认拒绝策略有兜底任务不会静默丢失第三加上监控至少覆盖线程数、活跃数、队列积压数、拒绝数第四线程池参数不要写死预留动态调整的能力。等到这些基础问题都处理完再去抠线程数具体是 8 还是 16你会发现那些数字其实没那么重要。线程池的核心价值永远是六个字可控、可观测、可恢复。把这三点做到位多线程并发这道坎你就已经迈过去一大半了。
