1. 从一次差点翻车的事故说起线程池到底管什么两年前我接手过一个内部运营系统的维护任务某天晚上十点多监控突然报警接口平均响应时间从 80ms 涨到了 8 秒紧接着一堆超时异常轰炸日志。查了半天才发现罪魁祸首是前人留的一段代码每次请求进来都new Thread(() - { ... }).start()高峰期线程数瞬间冲到上千个CPU 被打满上下文切换把系统彻底拖垮。那次事故之后我把这个模块的所有异步逻辑全部改造成线程池才算消停。这就是我写这篇 ThreadPoolExecutor 详解的出发点。很多同学对线程池的理解停留在背八个参数或者能用 Executors 静态方法就行但真正上了生产环境参数怎么配、队列怎么选、拒绝策略怎么定、线程如何回收、监控怎么埋点每一环都藏着坑。这篇文章不打算讲太多教科书式的定义我想把 ThreadPoolExecutor 从构造参数到任务流转、再到调参和排查用一线的视角完整捋一遍。适合已经被corePoolSize、maximumPoolSize搞糊涂的入门读者也适合那些想把自己的线程池从能跑优化到稳跑的进阶开发者。看完你至少能回答三个问题线程池是怎么工作的、为什么不建议随手用Executors的便捷方法、以及线上线程池出了问题该往哪儿查。2. 构造函数里的七个参数每一个都有存在理由2.1 核心线程数与最大线程数先搞清楚谁是正式工谁是临时工ThreadPoolExecutor最常用的构造函数有七个参数大部分人的记忆难点不在于参数含义而在于它们之间的联动关系。我习惯用开公司的逻辑来类比这样好记也好讲。corePoolSize正式员工数量。不管活多活少这部分线程常驻除非设置了allowCoreThreadTimeOut(true)否则即使空闲也不会被回收。maximumPoolSize公司最多能容纳的总员工数。等于正式工加上临时外援的上限。keepAliveTime和unit临时工的试用期。非核心线程空闲超过这个时间就会被裁掉。workQueue待办事项的队列。正式工忙不过来的时候新任务先排队而不是立刻招临时工。threadFactory招聘渠道。用来给每个线程命名、设置守护状态。handler公司实在塞不下人时的应对策略也就是拒绝策略。很多人在初学时会背一句话当提交的任务数大于corePoolSize且队列已满时线程池会创建新线程直到达到maximumPoolSize。这句话本身没毛病但容易让人误以为队列一满就立刻扩张线程实际上线程池的扩张顺序是先让核心线程干活核心线程忙不过来了就丢进队列队列满了才开始加非核心线程加到maximumPoolSize还是不够才触发拒绝策略。这个顺序特别关键。我见过有人把corePoolSize设成 200maximumPoolSize设成 400队列用无界队列结果上来就被流量打爆因为队列根本不会满线程数永远停在 200临时工一个都没被雇用。后面讲任务流转的时候我还会再展开。2.2 工作队列与拒绝策略决定了线程池的性格workQueue是线程池里最容易出问题的地方因为它直接决定了任务的排队方式。常见的选项有三个SynchronousQueue不存储任务每个插入操作必须等待另一个线程的移除操作。用它意味着只要核心线程忙就立即创建新线程适合对响应时间敏感、不希望任务积压的场景。LinkedBlockingQueue基于链表的无界队列也可以指定容量任务可以无限排队。日常用Executors.newFixedThreadPool得到的线程池就是它 无界队列。ArrayBlockingQueue有界队列必须指定容量适合需要限制排队量的场景。这里有一个非常隐蔽的坑如果你用了无界队列那么maximumPoolSize和拒绝策略基本就废了。因为任务永远不会填满队列线程池永远不会创建超过corePoolSize的线程也不会触发拒绝策略。换句话说你的线程池实际上被固定成了corePoolSize个线程剩下的参数形同虚设。拒绝策略RejectedExecutionHandler有四种内置实现AbortPolicy直接抛RejectedExecutionException默认策略。CallerRunsPolicy不抛异常会让提交任务的那个线程自己去执行这个任务。DiscardPolicy静默丢弃任务啥也不干。DiscardOldestPolicy丢弃队列中最老的任务然后把新任务塞进去。我个人的建议是大多数业务场景用CallerRunsPolicy会比AbortPolicy更稳妥因为当线程池满了说明系统已经到了瓶颈这时候让调用线程亲自执行相当于一种隐式的背压能拖慢提交方的速度给系统喘息的机会。当然如果任务是纯异步的、可以接受丢弃也可以自定义策略做告警和降级。2.3 其他参数里藏着的细节线程工厂与拒绝策略缺一不可threadFactory这个参数经常被忽略但它是线上排查的一把钥匙。如果你不自定义JDK 默认生成的线程名字是pool-1-thread-1这种格式一旦系统里线程池多了你根本分不清某个线程是哪个业务模块创建的。我每次在项目里都会用一个自定义工厂把业务名写进线程名比如order-async-pool-thread-1这样出问题的时候jstack一看就知道是谁家的线程在搞事情。顺带还会把线程设为非守护线程避免因为主线程结束导致任务丢失。还有一点容易被误解的是allowCoreThreadTimeOut参数。它默认是false如果你把它设为true核心线程也会在空闲超过keepAliveTime后退出可以配合SynchronousQueue实现线程数随负载伸缩的效果。不过要注意这个设置通常需要配合setKeepAliveTime使用而且在低峰期反复创建和销毁线程的开销也不小适合对资源占用敏感但任务量波动大的场景。3. 任务在池里的完整流转从execute到runWorker3.1execute方法的决策树每次提交都是一次条件判断很多人用线程池只是把任务往execute或者submit里一扔但没想过这背后发生了什么。其实execute的源码逻辑并不复杂可以用三步来概括。第一步如果当前线程数小于corePoolSize那就直接创建一个 Worker 线程来执行这个任务。这一步的判断即使在核心线程已经空闲的情况下也会成立所以线程池倾向于通过新建线程来响应新任务而不是复用空闲线程这是它先开人、后排队的性格。第二步如果当前线程数已经大于等于corePoolSize就把任务放进workQueue。注意这里并不在乎核心线程有没有空闲只看线程总数是否达到核心数。进了队列之后线程池会再次检查线程池状态如果发现池子已经关闭就会拒绝这个任务如果发现没有线程存活会补建一个线程。第三步如果队列也放不进去就尝试调用addWorker创建非核心线程。如果线程数已经达到maximumPoolSize或者线程池状态不合法就会走向拒绝策略。这个决策树理解透了你就能解释很多奇怪的现象。比如为什么corePoolSize10、maximumPoolSize20、有界队列容量为 100 的情况下前 10 个任务会立刻执行第 11 到第 110 个任务会排队而第 111 个任务才开始创建新线程。很多面试题里喜欢问先扩线程还是先排队答案就是先排队。3.2 Worker 线程生命周期AQS 与任务循环线程池里的每个线程其实被包装成了一个Worker对象这个对象继承自AbstractQueuedSynchronizerAQS。为什么要用 AQS因为Worker需要支持两种状态一种是正在干活时不能被中断另一种是空闲时可以被中断以便关闭线程池。AQS 正好提供了一种简单的互斥机制lock()表示开始干活时上锁此时外部调shutdownNow不会中断它干完活后unlock()解锁如果线程池正在关闭空闲的 Worker 就会被中断掉。每个 Worker 启动之后会进入一个while循环不断从任务队列里取任务执行完之后再取下一个。取任务有两个方法poll和take区别在于前者会等待keepAliveTime时间然后返回 null后者会一直阻塞直到有任务。线程池内部正是通过控制getTask()使用哪种方式来管理线程的回收核心线程用take除非设置了allowCoreThreadTimeOut非核心线程用poll超时返回 null 之后 Worker 就会退出线程数随之减少。这里有一个值得注意的性能细节当一个任务执行完毕Worker 并不会立刻销毁而是会再次尝试取任务这就避免了频繁创建线程的开销。也正是因为这个循环机制线程池里的核心线程才能真正实现常驻。3.3 从execute到submit的分岔Future 是怎么来的大多数业务代码用的不是execute而是submit因为后者能拿到返回值或者异常。submit内部把Runnable或者Callable包装成一个FutureTask最后调用的还是execute。这意味着线程池对任务本身的类型并不敏感它只负责执行任务的返回值、异常传播都由FutureTask来处理。但这里有一个坑如果你在任务里抛了异常execute提交的任务会直接让 Worker 线程挂掉异常会打印在日志里但线程池会默默补一个新的 Worker而submit提交的任务会把异常封装在返回的Future里如果你不调用future.get()异常会被吞掉日志里什么都不会有。我在排查线上问题时至少碰到过三次任务神秘消失最后都发现是submit之后没调get异常被吞了。所以用submit的代码要么记得接结果要么在任务内部自己 catch 住异常打日志。4. 参数估算与动态线程池改造调参不能拍脑袋4.1 两种常见的参数估算思路面试的时候最常被问到线程池大小怎么设置标准的回答是分 CPU 密集型和 IO 密集型CPU 密集型任务公式大致是CPU 核数 1。因为这类任务几乎不阻塞多出来的线程只会增加上下文切换开销。IO 密集型任务公式可以粗算为CPU 核数 * 2更精确一点是CPU 核数 / (1 - 阻塞系数)阻塞系数通常在 0.8 到 0.9 之间。也就是说如果任务有 80% 的时间在等待 IO那么理论上线程数可以是 CPU 核数的 5 倍。但说实话这些公式只能给出一个起点真实线上环境受内存、GC、下游服务吞吐量的影响很大。我更推荐的做法是先跑一轮压测在压测环境下用不同的线程数跑同样的任务观测吞吐量和响应时间随线程数的变化曲线找到拐点。我曾经调过一个日志清洗任务核心线程从 4 加到 8吞吐量直接翻倍再加到 16反而因为争抢数据库连接导致性能下滑。这正好说明线程数不是越大越好最终瓶颈往往不在 CPU而在下游资源。4.2 队列容量怎么定别让请求变成闲置库存队列容量的选择是调参里最容易失衡的地方。队列太小稍有流量波动就会触发拒绝策略队列太大任务积压后一旦系统恢复又会瞬间处理大量过期任务反而拖垮下游。我习惯用一个经验值让队列容量等于corePoolSize的 2 到 3 倍同时配合一个队列积压数的监控指标。当积压数持续增长时说明消费速度跟不上生产速度这时候需要思考是扩线程还是降流量而不是傻等队列自动消化。对于实时性要求高的系统甚至可以放弃队列直接使用SynchronousQueue让线程池的弹性完全交给非核心线程。这种做法的代价是线程创建销毁会更频繁需要合理配置keepAliveTime不能太短否则高峰期的抖动会非常剧烈。说到这必须再强调一次不要用Executors.newFixedThreadPool来创建线程池。它的默认队列是无界LinkedBlockingQueue一旦任务提交速度长期大于消费速度队列会无限增长最终导致内存溢出。这几乎是每个团队都会踩的坑我在代码评审里看到类似写法都会直接打回改造成显式构造ThreadPoolExecutor。4.3 动态线程池让参数可以随时调整生产环境有个很现实的问题参数配得再合理也架不住业务流量突变。比如大促前你预测峰值手动调高了核心线程数但活动结束后忘记调回来系统就会长期低负载运行。所以现在很多团队会做动态线程池。JDK 的ThreadPoolExecutor其实已经提供了调整参数的接口setCorePoolSize、setMaximumPoolSize、setKeepAliveTime。调用setCorePoolSize时线程池会动态调整正在运行的线程数如果新设置的值比当前核心线程数小空闲线程会被逐步回收。setMaximumPoolSize同理只是它不影响已运行的线程只限制后续扩张。我的做法是把线程池的配置放到配置中心里然后用一个后台线程定期同步参数。同步之前先通过getPoolSize、getActiveCount、getQueue().size()这几个方法拿到当前状态再决定要不要调整避免在高峰期贸然缩容。另外prestartAllCoreThreads()这个方法也值得提一下它可以在系统启动时就预先创建所有核心线程避免第一个任务到达时因为创建线程而延迟。对延迟敏感的初始化阶段这个方法很实用。5. 故障场景实录线程池出问题时怎么查5.1 案例一无界队列导致的内存与线程堆积有个某电商促销项目用户下单后会异步发送一堆消息。开发图省事用了Executors.newFixedThreadPool(20)顺便把线程池对象定义成了静态变量。结果某次下游消息服务响应极度变慢消息积压越来越多队列长度涨到了几百万条最终老年代内存持续增长触发了 Full GC整个应用几乎卡死。排查思路其实很直接先看jstat -gcutil确认内存状况再用jstack抓线程栈发现大量线程阻塞在LinkedBlockingQueue.put上再看业务日志里的消息发送耗时就基本能定位。修复方案是弃用无界队列改成有界队列 自定义拒绝策略比如丢弃并记录告警同时在下游服务恢复后通过重试机制补发。从那次之后我们团队定了一个规矩凡是线程池必须用显式构造队列必须有界。如果你现在也在用Executors的便捷方法建议尽早自查一下特别是newFixedThreadPool和newSingleThreadExecutor这两兄弟它们的无界队列在流量突刺时真的很危险。5.2 案例二核心线程数配置过大导致的线程饥饿另一个有意思的故障不是线程不够而是线程太多。某批处理系统给线程池配置了corePoolSize100、无界队列看起来性能很充足。但任务大部分是调用第三方 API耗时 1 到 3 秒不等。问题在于这个线程池的任务里还嵌套了另一个同样大线程数的线程池形成了 A 池任务等待 B 池任务完成的依赖关系。当 A 池 100 个线程全部占满B 池又没有线程可用时就出现了线程饥饿表现为 A 池的任务队列不停堆积但每个任务都卡在等待 Future 上。这种问题的排查难点在于线程栈看起来都正常阻塞没有死锁。我当时的排查步骤是先看jstack里大量park状态的线程再检查代码里的线程池调用链发现嵌套关系后将依赖子任务的部分改造成单独的线程池并给小池子设置更小的corePoolSize和更短的超时同时给 A 池的keepAliveTime设置了合理值以便非高峰时回收。线程饥饿的本质是资源都被无效占用了而不是资源不够所以在设计时就要尽量避免一个线程池任务再去依赖另一个线程池。5.3 监控与告警线程池里的四大核心指标平时不监控出了问题只能靠日志猜这是线程池运维最大的痛点。我建议至少给每个线程池埋上四个指标。getPoolSize()当前线程数结合getActiveCount()看实际干活的有多少。getQueue().size()队列积压数这是最敏感的指标。getTaskCount()和getCompletedTaskCount()累计完成任务数可用差值评估处理速率。拒绝次数这个需要自定义RejectedExecutionHandler在拒绝逻辑里埋点累加。在 Java 层面可以用 Micrometer 或者简单的ThreadPoolExecutor包装类暴露指标如果不想引入额外依赖也可以写一个定时任务每隔 10 秒采集一次并记录到日志。有了数据就能做告警规则队列积压数连续 3 次超过阈值或者拒绝次数大于 0就触发告警。坦率地讲大部分线程池问题在发生之前都是有可观测信号的关键是你有没有把它接进监控体系。6. 最后再分享几个我自己的使用习惯线程池这个东西用好了是性能利器用不好是隐性地雷。最后分享几个我这些年沉淀下来的小习惯谈不上标准答案但每一招都来自实战教训。线程池对象尽量用静态内部类持有不要散落在方法里到处创建。每次new ThreadPoolExecutor都是在浪费资源而且会导致线程无法复用。给每个池子取业务相关的前缀名字这是成本最低的排查手段。显式设置拒绝策略并且一定在拒绝策略里打日志宁愿多打一条日志也不要静默丢弃。用完的线程池要想到关闭。如果一个线程池是某个模块独有的在应用关闭时应该调用shutdown()或shutdownNow()别让它把 JVM 退出拖慢几秒钟。我个人在实际操作中还有一个体会调线程池参数的时候永远只调一个变量观察一段时间再做下一次调整。很多人喜欢一次性把核心线程、队列容量、拒绝策略全改了出了问题根本不知道是哪个变量引起的。线程池是并发系统的核心组件谨慎一点系统就会稳一点。