线程池这东西Java面试十次有八次会问工作里十个线程池有七个参数是从网上抄的。我刚开始写Java那会儿也是这样corePoolSize、maximumPoolSize、workQueue、handler背得滚瓜烂熟interview的时候能把“线程池的七大参数”倒着背出来可真到线上排查问题的时候照样满头问号——为什么任务积压了就是不发散为什么核心线程设置成10个跑起来一直是1个后来把ThreadPoolExecutor源码从头到尾翻了几遍又在生产环境观察了各类业务线程池的指标波动才算真正把这套机制串起来。这篇不是想复制一遍官方注释而是从“线程池到底在解决什么问题”讲起再把参数、队列、拒绝策略、常见坑逐个拆开揉碎最后聊点参数配置的经验。无论你是准备面试还是被线上线程池坑过应该都能在里面找到一点能直接拿去用的东西。1. 先搞明白线程池到底在解决什么问题1.1 从手动创建线程的痛说起先想一个最原始的场景请求来了就new Thread(...).start()任务跑了就完事。这种写法在并发量小的时候没毛病但并发一上来问题立刻暴露。第一线程创建和销毁是有开销的。JVM创建一个线程涉及到操作系统分配内核线程、分配栈内存默认1MB、注册到线程调度器频繁创建销毁对GC和CPU都是不小的负担。打个比方你不可能每一次面试都临时租个办公室大概率是长期租一间会议室随用随进。第二并发数不可控。没有上限地new Thread一旦请求洪峰来了几百个几千个线程同时跑CPU疯狂上下文切换内存也扛不住直接OutOfMemoryError: unable to create new native thread服务当场躺平。第三缺乏统一的任务管理与调度。你想优雅停掉一批任务想限制同时执行的任务数想做个任务队列让高峰期排队手写new Thread全都要自己实现而且极容易出bug。线程池把这三件事一次解决了复用线程、控制并发规模、通过队列缓冲任务。这就是它存在的意义。1.2 ThreadPoolExecutor的七大参数别只背定义Java标准的线程池实现是ThreadPoolExecutor它的构造参数有七个网上八股文都快背烂了。但很多人背完定义依然不知道怎么配问题出在只记了名词没理解参数之间的协作关系。表格先给出来后面我挨个讲参数作用corePoolSize核心线程数默认常驻存活即使空闲也不回收除非设置allowCoreThreadTimeOutmaximumPoolSize最大线程数线程池允许创建的最大线程数量keepAliveTime非核心线程空闲存活时间如果allowCoreThreadTimeOuttrue也作用于核心线程unitkeepAliveTime的时间单位workQueue任务队列核心线程忙不过来时任务先塞到这里threadFactory线程工厂决定线程名前缀、是否daemon强烈建议自定义handler拒绝策略任务太多队列也满线程也满时的处理方式参数之间不是孤立的。核心线程数决定“常备兵力”最大线程数是“战时可扩编的上限”任务队列是“缓冲区”拒绝策略是“缓冲区也满了的兜底方案”。1.3 别直接抄Executors的快捷方法Executors类提供了一堆现成方法比如newFixedThreadPool、newCachedThreadPool、newSingleThreadExecutor很多人图省事直接用它。但这里面坑很大。newFixedThreadPool用的队列是LinkedBlockingQueue默认容量是Integer.MAX_VALUE也就是说队列几乎无界。任务疯狂往里塞核心线程Reject了也不会创建更多线程因为队列永远没满最大线程数形同虚设。newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUESynchronousQueue又不会积压任务请求一多线程数直接奔着几千上万去了。真实项目中我个人的习惯是直接用new ThreadPoolExecutor(...)手动配置把ThreadFactory也一起实现了。这样参数是显式的每个线程池承担什么业务、允许什么行为一眼就能看清。2. 核心机制原理参数之间如何配合2.1 一个任务从提交到执行的完整闭环理清线程池执行逻辑最简单的方式就是跟随一个任务的“视角”走一遍完整闭环。假设我们配置了corePoolSize2、maximumPoolSize4、队列容量3线程池刚启动任务A到E先后提交。任务A进来发现当前工作线程数0小于corePoolSize直接创建一个核心线程去执行。任务B同理。此时两个核心线程都在忙任务C进来了。线程数已经等于核心线程数任务不会立刻再创建线程而是放进队列。任务D、E也是进队列排队。任务F进来时队列已经满了容量3。此时线程数2小于max4触发扩容创建一个非核心线程线程3去执行任务F。任务G进来队列满再扩容创建线程4。任务H进来队列满、线程数4已经到顶所有线程都在忙走拒绝策略。这个流程就是ThreadPoolExecutor最核心的判断逻辑先看核心线程满了再看队列队列满了再看能不能扩到最大线程数扩不了就拒绝。记住这个顺序绝大多数的参数配置问题都能理清。注意任务进队列而不是立刻创建新线程是刻意的设计选择。队列的本质是“缓冲”它让线程池在突发流量下不会瞬间把线程数拉到峰值而是给线程利用率和响应速度之间留了一个动态调节区间。先用缓冲把任务接住能消化的消化消化不了再扩兵这种“先排队再扩编”的思路远比无脑拉满线程数要稳。2.2 为什么“先放队列再扩线程”而不是直接扩线程很多人第一次看到这个执行逻辑时会疑惑既然队列满了才扩容为什么不在核心线程满了之后立刻创建新线程线程数上去了处理速度不是更快吗这个问题要分场景看。假如你不设队列、或者队列特别小线程池会非常敏感任何短时流量波动都会触发线程扩容。比如核心线程2个突然来了几十个请求线程数立刻拉到最大但很快流量降下来这些线程又在keepAliveTime内空闲销毁。线程的创建和销毁本身就是成本高频扩缩容会让系统的线程抖动非常剧烈整体性能反而下降。加入队列后线程池面对突发流量有了“缓冲带”。任务先排队用户请求不会直接被打回去而是等待核心线程逐步消化。只有持续的高流量让队列真正“溢出”线程池才会逐步扩容到最大值。这是对任务调度的一种平滑处理。另外队列的容量大小直接决定了“缓冲区”的深度。队列配得越大任务等待时间越长线程扩容越“迟钝”队列配得太小甚至为0线程池又几乎没有缓冲能力。配置的时候这两者必须联动考虑。2.3 线程池状态与线程数为什么藏在一个int里ThreadPoolExecutor里有个非常巧妙的设计用一个AtomicInteger ctl同时保存线程池的运行状态runState和工作线程数workerCount。其中高3位用来存runState低29位存workerCount。之所以这么干是为了让这两个状态可以原子地一起更新。比如一次CAS就能把“线程池变成STOP状态”和“线程数重置为0”的操作合在一起避免分布式锁或者多步同步带来的状态不一致。线程池的状态包括RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED。SHUTDOWN后不再接收新任务但会继续处理队列里的已提交任务STOP会直接中断任务并清空队列TIDYING时任务清零正在执行terminated()钩子方法TERMINATED是最终结束状态。日常使用中我们最常看到的是RUNNING状态。当调用shutdown()方法线程池进入SHUTDOWN处理完队列里已有的任务后才会真正结束。这也是为什么“优雅停机”需要时间不可能调一个方法线程池立刻消失。3. 从源码看工作流程execute()那几步到底干了什么3.1 execute()的四个分支前面讲的执行闭环对应到源码里就是execute()方法。把核心逻辑简化一下大概是这个样子public void execute(Runnable command) { if (command null) throw new NullPointerException(); int c ctl.get(); // 1. 工作线程数小于核心线程数直接新增核心线程 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 2. 线程池还在RUNNING尝试入队 if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); // double-check入队后线程池被SHUTDOWN了要回滚并拒绝 if (!isRunning(recheck) remove(command)) reject(command); // 线程没崩但没有工作线程就补一个空任务的Worker else if (workerCountOf(recheck) 0) addWorker(null, false); } // 3. 入队失败比如队列已满尝试增加到非核心线程 else if (!addWorker(command, false)) { // 4. 扩容失败拒绝 reject(command); } }第一步看核心线程是否饱和饱和了才走队列入队成功之后还有个double-check避免入队后线程池刚好被关掉或者线程数异常为0出现“任务放进了队列但没人消费”的情况入队失败才尝试加非核心线程加不进去就拒绝。这里面最妙的是addWorker(command, true)和addWorker(command, false)的布尔参数它标记是否为核心线程。核心线程和非核心线程的差别主要体现在闲置回收策略上普通情况下非核心线程空闲超出keepAliveTime会被回收核心线程则不会。但这个差别不在addWorker里而在后面Worker从队列取任务的环节中。3.2 Worker干活与线程复用的真相线程池里的线程被封装成了Worker对象。每个Worker内部持有一个Thread和一个firstTaskfirstTask可能为空表示这个线程启动之后直接从队列里取任务。Worker的run方法会循环调用runWorker(this)核心流程简化如下try { while (task ! null || (task getTask()) ! null) { // 加锁防止shutdownNow之类的中断影响 // 执行任务前会执行beforeExecute等钩子 task.run(); // 执行完清理 } } finally { processWorkerExit(w, completedAbruptly); }一个Worker执行完firstTask后不会退出而是通过getTask()再去阻塞队列里拿下一个任务。如果队列里暂时没有任务它会被workQueue.take()或者workQueue.poll(keepAliveTime, unit)阻塞住。take是无限期阻塞poll带超时时间——核心线程用take非核心线程用poll这就是核心线程常驻、非核心线程空闲超时销毁的根本区别。这个循环解释了一个常见疑惑为什么线程池里的线程数量不多却可以处理成千上万的任务。因为线程是常驻的工人任务是流水线上的货物工人干完一件会接着拿下一件而不是干完一个就报废。getTask()返回null时Worker就会退出最典型的情况是当前线程数已经大于核心线程数且队列里没有任务了非核心线程阻塞超时poll返回null线程自然结束。整个退出逻辑最后还会统计“已完成任务数”这些指标可以通过ThreadPoolExecutor的getCompletedTaskCount()等接口拿到。3.3 从执行逻辑看“最大线程数形同虚设”的几个场景源码看明白了有些网上常见的问题就瞬间清晰了。场景一队列用的是无界队列比如new LinkedBlockingQueue()workQueue.offer(command)永远成功那么第三步addWorker(false)永远不会走到。即使maximumPoolSize设置成1000实际线程数最多也就是corePoolSize最大线程数永远用不上。之前很多老项目踩过这个坑线程池写死成20流量翻倍了也不扩容排查半天发现队列是无界LinkedBlockingQueue。场景二队列容量太大比如配了10000。极端情况下任务积压到月底都消费不完线程数也一直停留在corePoolSize不会扩。从监控面板看线程池的活跃线程永远是核心线程数queue size却在持续增长。这种情况要警惕“假健康”线程数正常、CPU不高但任务处理严重延迟。场景三核心线程数设置太小任务大部分时间都在排队新增的任务又持续不断导致队列永远满、线程数接近maximumPoolSize、拒绝策略频繁触发。这种情况就要优先考虑调大corePoolSize或优化单个任务的执行耗时。4. 阻塞队列怎么选别见到LinkedBlockingQueue就无脑用4.1 常见阻塞队列的特性对比队列在线程池里的角色是“积压任务的缓冲区”但不同队列的脾气完全不同。我整理了一个对比表队列是否有界特点适用场景LinkedBlockingQueue可指定容量默认无界基于链表吞吐较高默认选择最多必须显式设容量避免无界风险ArrayBlockingQueue有界基于数组容量固定FIFO适合对等待任务数有严格上限的场景SynchronousQueue无容量不存储任务每个插入必须等待一个删除操作适合“直接交付”场景不缓存任务PriorityBlockingQueue无界按优先级出队不是FIFO任务分优先级的特殊场景需要自定义ComparatorDelayQueue无界延迟到期才能取出延迟任务、定时任务场景很多人对SynchronousQueue的理解有误区觉得它是一个“大小为0的队列”是一个空的容器。其实它根本不是用来存储任务的而是一个“交接手递手”工具。提交任务给SynchronousQueue必须等一个空闲线程来取走否则提交操作就会阻塞。所以newCachedThreadPool配合SynchronousQueue配合Integer.MAX_VALUE的最大线程数会产生“来一个任务就建一个线程”的效果适合大量短时、高频的任务。但也很容易把线程数拉爆线上谨慎使用。PriorityBlockingQueue和DelayQueue都是无界队列搭配线程池使用时maximumPoolSize基本失效。因为队列永远不会满不会触发扩容。但这两个队列的特点是“任务按优先级或延迟出队”在任务本身有级别差异或需要延后处理的场景里很有价值比如延迟重试任务。4.2 拒绝策略四种内置策略与两种实战思路任务量超过线程池处理上限最终会走到拒绝策略。ThreadPoolExecutor内置了四种RejectedExecutionHandler策略行为风险AbortPolicy默认策略直接抛出RejectedExecutionException可能中断业务请求需要调用方处理异常CallerRunsPolicy不抛异常谁提交谁自己执行这个任务调用线程被阻塞相当于把压力传回调用方形成天然回压DiscardPolicy默默地丢弃新任务任务丢失无感知危险DiscardOldestPolicy丢弃队列中最早的任务然后重新提交当前任务可能丢弃关键任务这四种策略里我建议绝大多数场景用AbortPolicy或CallerRunsPolicy。AbortPolicy最规范任务被拒绝就应该明确抛出来让上层感知到系统过载而不是悄无声息丢任务。CallerRunsPolicy则适合流量削峰的场景提交线程自己消化一部分任务避免任务直接暴毙但要注意调用线程会被占用可能降低接口响应速度。DiscardPolicy和DiscardOldestPolicy我个人几乎不用。丢任务这件事太容易埋雷了尤其业务方根本不知道自己的请求已经被丢弃排查起来极难定位。如果非得用也建议在自定义handler里记录一条WARN日志方便事后追踪。自定义拒绝策略也很简单实现RejectedExecutionHandler接口即可。我常用的做法是在rejectedExecution里把任务信息写入Redis或Kafka配合一个定时任务重新入队相当于给线程池加了一个“重试通道”。这样既不会硬抛异常打断业务也不会静默丢失任务。经验提醒线上线程池的拒绝日志一定要打出来并且带上队列长度、当前线程数、活跃线程数、核心线程数这些关键指标。否则出现“大量请求被AbortPolicy打压”时你连从哪个线程池拒绝的都定位不出来。5. 常见问题与排查技巧实录5.1 线程数一直在涨日志里却没几条执行记录有个朋友之前在压测环境遇到一个现象线程池的poolSize一路涨到maximumPoolSize但日志里实际执行的任务数量却少得可怜CPU也不高线程都在干嘛排查之后发现大部分线程卡在外部接口的等待上比如一个HTTP调用超时设置成60秒下游服务迟迟不返回线程就一直BLOCKED在SocketRead上。线程池的任务是“看起来在执行”实则是“执行一动不动”。这种场景下线程池扩容再多也没用瓶颈在下游接口或数据库连接。排查方法先jstack看一眼线程栈如果大量线程在java.net.SocketInputStream.socketRead0或者数据库socket读上基本可以断定IO等待占了绝大部分时间。此时要解决的是下游超时时间、连接池大小、缓存策略而不是继续调大maximumPoolSize。5.2 队列容量显示为0但任务还是堆积有次排查一个消息消费线程池监控面板显示queue.size一直为0activeCount也上不去但消息积压却在不断增加。看线程池配置核心线程数明明设了10个。当时很多同事一脸懵。后来dump线程栈发现10个线程里有大半处于LockSupport.park状态等待一个公用的资源锁——那个锁是一个非线程安全的第三方SDK开发同学用synchronized给方法加了锁。结果就是线程池里的线程“全都活着”但只有1个能进临界区干活其他9个全部排队等锁。队列里没有额外任务是因为消息在内存里排队等着拿锁。这种情况下线程池参数再合理也没有问题的根子在锁竞争。这种问题不罕见。以前我也写过“线程池里的活线程看着多但实际上都在Blocked队列里排队等锁”这种代码。排查一定要先看线程栈别只盯线程池本身的指标。5.3 execute还是submit异常为什么会“消失”使用submit()提交任务时任务执行过程中抛出的异常不会直接打印到日志而是封装在返回的Future对象里。如果你没有调用future.get()异常就被静默吞掉了日志里看不到任何报错任务却悄悄挂掉。这点非常坑。生产环境出现过“任务好像没执行”但日志一片空白就是因为调用了submit然后没有get异常被吞得一干二净。解决方案如果你不需要返回值更推荐用execute()提交任务异常会直接抛给线程池的UncaughtExceptionHandler。必须用submit时一定要future.get()获取结果并catch住ExecutionException。线程池创建时设置ThreadFactory时给线程统一设置一个setUncaughtExceptionHandler至少保证异常有记录。我在项目里一般这么处理自定义一个线程工厂给所有池内线程设置UncaughtExceptionHandler统一记录异常日志提交任务时尽量用execute如果涉及需要返回值的业务使用submit并严格处理Future的异常分支。6. 参数配置把线程池配到“不翻车”的通用思路6.1 核心线程数和最大线程数的估算方法线上配置线程池参数没有绝对公式但我比较常用的起步思路是这样的CPU密集型任务核心线程数 ≈ CPU核数 1。原因是CPU密集任务几乎不等待线程数超过CPU核数之后多出来的线程主要是在抢CPU时间片反而增加上下文切换开销。IO密集型任务核心线程数 ≈ CPU核数 * 2或者更高。因为IO等待期间CPU是空闲的可以多放一些线程去处理其他任务。混合型任务把任务拆成CPU密集和IO密集两块分别交给不同线程池各配各的参数。关键还要看下游的承受能力。如果任务会调用外部接口、数据库、MQ线程池配得再大也没用下游撑不住照样超时。这时候不是无脑加大线程数而是先摸清下游最大支持多少QPS再反推线程数。不要完全照搬公式。线程数只是个起点最好是上线后进行压测根据队列积压、线程活跃度、RT数据动态调整。6.2 动态调整线程池与优雅关闭ThreadPoolExecutor在运行期间是支持动态调整参数的。通过setCorePoolSize(int)和setMaximumPoolSize(int)可以在不重启应用的情况下调整线程数。这个能力很实用比如线上压测发现核心线程数不够可以直接通过运维接口下调大不用发版。还有一点容易被忽略如果我们把corePoolSize调小到比当前线程数还小那些多出来的线程不会立刻被回收而是要等它们空闲下来超过keepAliveTime之后才会逐渐退出。所以线上动态缩容通常不是即时生效的要看线程是否繁忙。线程池关闭也有讲究。shutdown()是平滑关闭线程池不再接收新任务但队列中已提交的任务会继续处理完毕shutdownNow()则会尝试中断所有正在执行的任务并清空队列返回尚未执行的任务列表。业务系统推荐优先用shutdown()给正在跑的任务一个收尾时间。我也习惯在JVM关闭钩子ShutdownHook里统一调用线程池的shutdown()避免服务下线时任务被中断。细节虽小线上没少踩这种坑。6.3 监控先行线程池也需要“体检”配置线程池只是第一步上线后的监控才是长期稳定运行的保障。我一般会为每个线程池起一个独立且有业务含义的线程名前缀比如order-async-pool然后通过Spring的ThreadPoolTaskExecutor或ThreadPoolExecutor的自定义Metrics采集把以下指标暴露给监控系统当前线程数poolSize活跃线程数activeCount队列积压数量queue.size已完成任务数量completedTaskCount被拒绝任务数量Rejected Execution Count这五个指标基本够用。其中queue.size增长率和completedTaskCount的增速能非常直观地判断线程池是否在“干活”拒绝计数一旦出现非零就要立刻告警。我们当时在线上就是因为监控Alarm及时发现了某个业务线程池拒绝异常才避免了业务大规模受损。配置参数这件事本质上是一个动态调节的过程。项目初期可以先用经验值兜底但最终判断一定来自数据。多观察监控、多分析线程状态、多记录每次调参前后的效果时间长了你就能慢慢找到自己业务场景下的“最优参数区间”。我个人对线程池的体会是它不是一个配置完就一劳永逸的组件更像一个持续调节的“流量阀门”。你在面试时能把七大参数和拒绝策略背得滚瓜烂熟远不如在线上的监控面板里多盯几周这些指标的变化来得实在。动手调一次踩一次坑比你背十篇八股文都有用。
线程池这东西Java面试十次有八次会问工作里十个线程池有七个参数是从网上抄的。我刚开始写Java那会儿也是这样corePoolSize、maximumPoolSize、workQueue、handler背得滚瓜烂熟interview的时候能把“线程池的七大参数”倒着背出来可真到线上排查问题的时候照样满头问号——为什么任务积压了就是不发散为什么核心线程设置成10个跑起来一直是1个后来把ThreadPoolExecutor源码从头到尾翻了几遍又在生产环境观察了各类业务线程池的指标波动才算真正把这套机制串起来。这篇不是想复制一遍官方注释而是从“线程池到底在解决什么问题”讲起再把参数、队列、拒绝策略、常见坑逐个拆开揉碎最后聊点参数配置的经验。无论你是准备面试还是被线上线程池坑过应该都能在里面找到一点能直接拿去用的东西。1. 先搞明白线程池到底在解决什么问题1.1 从手动创建线程的痛说起先想一个最原始的场景请求来了就new Thread(...).start()任务跑了就完事。这种写法在并发量小的时候没毛病但并发一上来问题立刻暴露。第一线程创建和销毁是有开销的。JVM创建一个线程涉及到操作系统分配内核线程、分配栈内存默认1MB、注册到线程调度器频繁创建销毁对GC和CPU都是不小的负担。打个比方你不可能每一次面试都临时租个办公室大概率是长期租一间会议室随用随进。第二并发数不可控。没有上限地new Thread一旦请求洪峰来了几百个几千个线程同时跑CPU疯狂上下文切换内存也扛不住直接OutOfMemoryError: unable to create new native thread服务当场躺平。第三缺乏统一的任务管理与调度。你想优雅停掉一批任务想限制同时执行的任务数想做个任务队列让高峰期排队手写new Thread全都要自己实现而且极容易出bug。线程池把这三件事一次解决了复用线程、控制并发规模、通过队列缓冲任务。这就是它存在的意义。1.2 ThreadPoolExecutor的七大参数别只背定义Java标准的线程池实现是ThreadPoolExecutor它的构造参数有七个网上八股文都快背烂了。但很多人背完定义依然不知道怎么配问题出在只记了名词没理解参数之间的协作关系。表格先给出来后面我挨个讲参数作用corePoolSize核心线程数默认常驻存活即使空闲也不回收除非设置allowCoreThreadTimeOutmaximumPoolSize最大线程数线程池允许创建的最大线程数量keepAliveTime非核心线程空闲存活时间如果allowCoreThreadTimeOuttrue也作用于核心线程unitkeepAliveTime的时间单位workQueue任务队列核心线程忙不过来时任务先塞到这里threadFactory线程工厂决定线程名前缀、是否daemon强烈建议自定义handler拒绝策略任务太多队列也满线程也满时的处理方式参数之间不是孤立的。核心线程数决定“常备兵力”最大线程数是“战时可扩编的上限”任务队列是“缓冲区”拒绝策略是“缓冲区也满了的兜底方案”。1.3 别直接抄Executors的快捷方法Executors类提供了一堆现成方法比如newFixedThreadPool、newCachedThreadPool、newSingleThreadExecutor很多人图省事直接用它。但这里面坑很大。newFixedThreadPool用的队列是LinkedBlockingQueue默认容量是Integer.MAX_VALUE也就是说队列几乎无界。任务疯狂往里塞核心线程Reject了也不会创建更多线程因为队列永远没满最大线程数形同虚设。newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUESynchronousQueue又不会积压任务请求一多线程数直接奔着几千上万去了。真实项目中我个人的习惯是直接用new ThreadPoolExecutor(...)手动配置把ThreadFactory也一起实现了。这样参数是显式的每个线程池承担什么业务、允许什么行为一眼就能看清。2. 核心机制原理参数之间如何配合2.1 一个任务从提交到执行的完整闭环理清线程池执行逻辑最简单的方式就是跟随一个任务的“视角”走一遍完整闭环。假设我们配置了corePoolSize2、maximumPoolSize4、队列容量3线程池刚启动任务A到E先后提交。任务A进来发现当前工作线程数0小于corePoolSize直接创建一个核心线程去执行。任务B同理。此时两个核心线程都在忙任务C进来了。线程数已经等于核心线程数任务不会立刻再创建线程而是放进队列。任务D、E也是进队列排队。任务F进来时队列已经满了容量3。此时线程数2小于max4触发扩容创建一个非核心线程线程3去执行任务F。任务G进来队列满再扩容创建线程4。任务H进来队列满、线程数4已经到顶所有线程都在忙走拒绝策略。这个流程就是ThreadPoolExecutor最核心的判断逻辑先看核心线程满了再看队列队列满了再看能不能扩到最大线程数扩不了就拒绝。记住这个顺序绝大多数的参数配置问题都能理清。注意任务进队列而不是立刻创建新线程是刻意的设计选择。队列的本质是“缓冲”它让线程池在突发流量下不会瞬间把线程数拉到峰值而是给线程利用率和响应速度之间留了一个动态调节区间。先用缓冲把任务接住能消化的消化消化不了再扩兵这种“先排队再扩编”的思路远比无脑拉满线程数要稳。2.2 为什么“先放队列再扩线程”而不是直接扩线程很多人第一次看到这个执行逻辑时会疑惑既然队列满了才扩容为什么不在核心线程满了之后立刻创建新线程线程数上去了处理速度不是更快吗这个问题要分场景看。假如你不设队列、或者队列特别小线程池会非常敏感任何短时流量波动都会触发线程扩容。比如核心线程2个突然来了几十个请求线程数立刻拉到最大但很快流量降下来这些线程又在keepAliveTime内空闲销毁。线程的创建和销毁本身就是成本高频扩缩容会让系统的线程抖动非常剧烈整体性能反而下降。加入队列后线程池面对突发流量有了“缓冲带”。任务先排队用户请求不会直接被打回去而是等待核心线程逐步消化。只有持续的高流量让队列真正“溢出”线程池才会逐步扩容到最大值。这是对任务调度的一种平滑处理。另外队列的容量大小直接决定了“缓冲区”的深度。队列配得越大任务等待时间越长线程扩容越“迟钝”队列配得太小甚至为0线程池又几乎没有缓冲能力。配置的时候这两者必须联动考虑。2.3 线程池状态与线程数为什么藏在一个int里ThreadPoolExecutor里有个非常巧妙的设计用一个AtomicInteger ctl同时保存线程池的运行状态runState和工作线程数workerCount。其中高3位用来存runState低29位存workerCount。之所以这么干是为了让这两个状态可以原子地一起更新。比如一次CAS就能把“线程池变成STOP状态”和“线程数重置为0”的操作合在一起避免分布式锁或者多步同步带来的状态不一致。线程池的状态包括RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED。SHUTDOWN后不再接收新任务但会继续处理队列里的已提交任务STOP会直接中断任务并清空队列TIDYING时任务清零正在执行terminated()钩子方法TERMINATED是最终结束状态。日常使用中我们最常看到的是RUNNING状态。当调用shutdown()方法线程池进入SHUTDOWN处理完队列里已有的任务后才会真正结束。这也是为什么“优雅停机”需要时间不可能调一个方法线程池立刻消失。3. 从源码看工作流程execute()那几步到底干了什么3.1 execute()的四个分支前面讲的执行闭环对应到源码里就是execute()方法。把核心逻辑简化一下大概是这个样子public void execute(Runnable command) { if (command null) throw new NullPointerException(); int c ctl.get(); // 1. 工作线程数小于核心线程数直接新增核心线程 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 2. 线程池还在RUNNING尝试入队 if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); // double-check入队后线程池被SHUTDOWN了要回滚并拒绝 if (!isRunning(recheck) remove(command)) reject(command); // 线程没崩但没有工作线程就补一个空任务的Worker else if (workerCountOf(recheck) 0) addWorker(null, false); } // 3. 入队失败比如队列已满尝试增加到非核心线程 else if (!addWorker(command, false)) { // 4. 扩容失败拒绝 reject(command); } }第一步看核心线程是否饱和饱和了才走队列入队成功之后还有个double-check避免入队后线程池刚好被关掉或者线程数异常为0出现“任务放进了队列但没人消费”的情况入队失败才尝试加非核心线程加不进去就拒绝。这里面最妙的是addWorker(command, true)和addWorker(command, false)的布尔参数它标记是否为核心线程。核心线程和非核心线程的差别主要体现在闲置回收策略上普通情况下非核心线程空闲超出keepAliveTime会被回收核心线程则不会。但这个差别不在addWorker里而在后面Worker从队列取任务的环节中。3.2 Worker干活与线程复用的真相线程池里的线程被封装成了Worker对象。每个Worker内部持有一个Thread和一个firstTaskfirstTask可能为空表示这个线程启动之后直接从队列里取任务。Worker的run方法会循环调用runWorker(this)核心流程简化如下try { while (task ! null || (task getTask()) ! null) { // 加锁防止shutdownNow之类的中断影响 // 执行任务前会执行beforeExecute等钩子 task.run(); // 执行完清理 } } finally { processWorkerExit(w, completedAbruptly); }一个Worker执行完firstTask后不会退出而是通过getTask()再去阻塞队列里拿下一个任务。如果队列里暂时没有任务它会被workQueue.take()或者workQueue.poll(keepAliveTime, unit)阻塞住。take是无限期阻塞poll带超时时间——核心线程用take非核心线程用poll这就是核心线程常驻、非核心线程空闲超时销毁的根本区别。这个循环解释了一个常见疑惑为什么线程池里的线程数量不多却可以处理成千上万的任务。因为线程是常驻的工人任务是流水线上的货物工人干完一件会接着拿下一件而不是干完一个就报废。getTask()返回null时Worker就会退出最典型的情况是当前线程数已经大于核心线程数且队列里没有任务了非核心线程阻塞超时poll返回null线程自然结束。整个退出逻辑最后还会统计“已完成任务数”这些指标可以通过ThreadPoolExecutor的getCompletedTaskCount()等接口拿到。3.3 从执行逻辑看“最大线程数形同虚设”的几个场景源码看明白了有些网上常见的问题就瞬间清晰了。场景一队列用的是无界队列比如new LinkedBlockingQueue()workQueue.offer(command)永远成功那么第三步addWorker(false)永远不会走到。即使maximumPoolSize设置成1000实际线程数最多也就是corePoolSize最大线程数永远用不上。之前很多老项目踩过这个坑线程池写死成20流量翻倍了也不扩容排查半天发现队列是无界LinkedBlockingQueue。场景二队列容量太大比如配了10000。极端情况下任务积压到月底都消费不完线程数也一直停留在corePoolSize不会扩。从监控面板看线程池的活跃线程永远是核心线程数queue size却在持续增长。这种情况要警惕“假健康”线程数正常、CPU不高但任务处理严重延迟。场景三核心线程数设置太小任务大部分时间都在排队新增的任务又持续不断导致队列永远满、线程数接近maximumPoolSize、拒绝策略频繁触发。这种情况就要优先考虑调大corePoolSize或优化单个任务的执行耗时。4. 阻塞队列怎么选别见到LinkedBlockingQueue就无脑用4.1 常见阻塞队列的特性对比队列在线程池里的角色是“积压任务的缓冲区”但不同队列的脾气完全不同。我整理了一个对比表队列是否有界特点适用场景LinkedBlockingQueue可指定容量默认无界基于链表吞吐较高默认选择最多必须显式设容量避免无界风险ArrayBlockingQueue有界基于数组容量固定FIFO适合对等待任务数有严格上限的场景SynchronousQueue无容量不存储任务每个插入必须等待一个删除操作适合“直接交付”场景不缓存任务PriorityBlockingQueue无界按优先级出队不是FIFO任务分优先级的特殊场景需要自定义ComparatorDelayQueue无界延迟到期才能取出延迟任务、定时任务场景很多人对SynchronousQueue的理解有误区觉得它是一个“大小为0的队列”是一个空的容器。其实它根本不是用来存储任务的而是一个“交接手递手”工具。提交任务给SynchronousQueue必须等一个空闲线程来取走否则提交操作就会阻塞。所以newCachedThreadPool配合SynchronousQueue配合Integer.MAX_VALUE的最大线程数会产生“来一个任务就建一个线程”的效果适合大量短时、高频的任务。但也很容易把线程数拉爆线上谨慎使用。PriorityBlockingQueue和DelayQueue都是无界队列搭配线程池使用时maximumPoolSize基本失效。因为队列永远不会满不会触发扩容。但这两个队列的特点是“任务按优先级或延迟出队”在任务本身有级别差异或需要延后处理的场景里很有价值比如延迟重试任务。4.2 拒绝策略四种内置策略与两种实战思路任务量超过线程池处理上限最终会走到拒绝策略。ThreadPoolExecutor内置了四种RejectedExecutionHandler策略行为风险AbortPolicy默认策略直接抛出RejectedExecutionException可能中断业务请求需要调用方处理异常CallerRunsPolicy不抛异常谁提交谁自己执行这个任务调用线程被阻塞相当于把压力传回调用方形成天然回压DiscardPolicy默默地丢弃新任务任务丢失无感知危险DiscardOldestPolicy丢弃队列中最早的任务然后重新提交当前任务可能丢弃关键任务这四种策略里我建议绝大多数场景用AbortPolicy或CallerRunsPolicy。AbortPolicy最规范任务被拒绝就应该明确抛出来让上层感知到系统过载而不是悄无声息丢任务。CallerRunsPolicy则适合流量削峰的场景提交线程自己消化一部分任务避免任务直接暴毙但要注意调用线程会被占用可能降低接口响应速度。DiscardPolicy和DiscardOldestPolicy我个人几乎不用。丢任务这件事太容易埋雷了尤其业务方根本不知道自己的请求已经被丢弃排查起来极难定位。如果非得用也建议在自定义handler里记录一条WARN日志方便事后追踪。自定义拒绝策略也很简单实现RejectedExecutionHandler接口即可。我常用的做法是在rejectedExecution里把任务信息写入Redis或Kafka配合一个定时任务重新入队相当于给线程池加了一个“重试通道”。这样既不会硬抛异常打断业务也不会静默丢失任务。经验提醒线上线程池的拒绝日志一定要打出来并且带上队列长度、当前线程数、活跃线程数、核心线程数这些关键指标。否则出现“大量请求被AbortPolicy打压”时你连从哪个线程池拒绝的都定位不出来。5. 常见问题与排查技巧实录5.1 线程数一直在涨日志里却没几条执行记录有个朋友之前在压测环境遇到一个现象线程池的poolSize一路涨到maximumPoolSize但日志里实际执行的任务数量却少得可怜CPU也不高线程都在干嘛排查之后发现大部分线程卡在外部接口的等待上比如一个HTTP调用超时设置成60秒下游服务迟迟不返回线程就一直BLOCKED在SocketRead上。线程池的任务是“看起来在执行”实则是“执行一动不动”。这种场景下线程池扩容再多也没用瓶颈在下游接口或数据库连接。排查方法先jstack看一眼线程栈如果大量线程在java.net.SocketInputStream.socketRead0或者数据库socket读上基本可以断定IO等待占了绝大部分时间。此时要解决的是下游超时时间、连接池大小、缓存策略而不是继续调大maximumPoolSize。5.2 队列容量显示为0但任务还是堆积有次排查一个消息消费线程池监控面板显示queue.size一直为0activeCount也上不去但消息积压却在不断增加。看线程池配置核心线程数明明设了10个。当时很多同事一脸懵。后来dump线程栈发现10个线程里有大半处于LockSupport.park状态等待一个公用的资源锁——那个锁是一个非线程安全的第三方SDK开发同学用synchronized给方法加了锁。结果就是线程池里的线程“全都活着”但只有1个能进临界区干活其他9个全部排队等锁。队列里没有额外任务是因为消息在内存里排队等着拿锁。这种情况下线程池参数再合理也没有问题的根子在锁竞争。这种问题不罕见。以前我也写过“线程池里的活线程看着多但实际上都在Blocked队列里排队等锁”这种代码。排查一定要先看线程栈别只盯线程池本身的指标。5.3 execute还是submit异常为什么会“消失”使用submit()提交任务时任务执行过程中抛出的异常不会直接打印到日志而是封装在返回的Future对象里。如果你没有调用future.get()异常就被静默吞掉了日志里看不到任何报错任务却悄悄挂掉。这点非常坑。生产环境出现过“任务好像没执行”但日志一片空白就是因为调用了submit然后没有get异常被吞得一干二净。解决方案如果你不需要返回值更推荐用execute()提交任务异常会直接抛给线程池的UncaughtExceptionHandler。必须用submit时一定要future.get()获取结果并catch住ExecutionException。线程池创建时设置ThreadFactory时给线程统一设置一个setUncaughtExceptionHandler至少保证异常有记录。我在项目里一般这么处理自定义一个线程工厂给所有池内线程设置UncaughtExceptionHandler统一记录异常日志提交任务时尽量用execute如果涉及需要返回值的业务使用submit并严格处理Future的异常分支。6. 参数配置把线程池配到“不翻车”的通用思路6.1 核心线程数和最大线程数的估算方法线上配置线程池参数没有绝对公式但我比较常用的起步思路是这样的CPU密集型任务核心线程数 ≈ CPU核数 1。原因是CPU密集任务几乎不等待线程数超过CPU核数之后多出来的线程主要是在抢CPU时间片反而增加上下文切换开销。IO密集型任务核心线程数 ≈ CPU核数 * 2或者更高。因为IO等待期间CPU是空闲的可以多放一些线程去处理其他任务。混合型任务把任务拆成CPU密集和IO密集两块分别交给不同线程池各配各的参数。关键还要看下游的承受能力。如果任务会调用外部接口、数据库、MQ线程池配得再大也没用下游撑不住照样超时。这时候不是无脑加大线程数而是先摸清下游最大支持多少QPS再反推线程数。不要完全照搬公式。线程数只是个起点最好是上线后进行压测根据队列积压、线程活跃度、RT数据动态调整。6.2 动态调整线程池与优雅关闭ThreadPoolExecutor在运行期间是支持动态调整参数的。通过setCorePoolSize(int)和setMaximumPoolSize(int)可以在不重启应用的情况下调整线程数。这个能力很实用比如线上压测发现核心线程数不够可以直接通过运维接口下调大不用发版。还有一点容易被忽略如果我们把corePoolSize调小到比当前线程数还小那些多出来的线程不会立刻被回收而是要等它们空闲下来超过keepAliveTime之后才会逐渐退出。所以线上动态缩容通常不是即时生效的要看线程是否繁忙。线程池关闭也有讲究。shutdown()是平滑关闭线程池不再接收新任务但队列中已提交的任务会继续处理完毕shutdownNow()则会尝试中断所有正在执行的任务并清空队列返回尚未执行的任务列表。业务系统推荐优先用shutdown()给正在跑的任务一个收尾时间。我也习惯在JVM关闭钩子ShutdownHook里统一调用线程池的shutdown()避免服务下线时任务被中断。细节虽小线上没少踩这种坑。6.3 监控先行线程池也需要“体检”配置线程池只是第一步上线后的监控才是长期稳定运行的保障。我一般会为每个线程池起一个独立且有业务含义的线程名前缀比如order-async-pool然后通过Spring的ThreadPoolTaskExecutor或ThreadPoolExecutor的自定义Metrics采集把以下指标暴露给监控系统当前线程数poolSize活跃线程数activeCount队列积压数量queue.size已完成任务数量completedTaskCount被拒绝任务数量Rejected Execution Count这五个指标基本够用。其中queue.size增长率和completedTaskCount的增速能非常直观地判断线程池是否在“干活”拒绝计数一旦出现非零就要立刻告警。我们当时在线上就是因为监控Alarm及时发现了某个业务线程池拒绝异常才避免了业务大规模受损。配置参数这件事本质上是一个动态调节的过程。项目初期可以先用经验值兜底但最终判断一定来自数据。多观察监控、多分析线程状态、多记录每次调参前后的效果时间长了你就能慢慢找到自己业务场景下的“最优参数区间”。我个人对线程池的体会是它不是一个配置完就一劳永逸的组件更像一个持续调节的“流量阀门”。你在面试时能把七大参数和拒绝策略背得滚瓜烂熟远不如在线上的监控面板里多盯几周这些指标的变化来得实在。动手调一次踩一次坑比你背十篇八股文都有用。
