最近一个线上事故让我印象很深某服务在晚高峰突然响应变慢CPU 冲到 90% 以上线程 dump 里能看到大量RUNNABLE线程在疯狂抢占锁而队列里还积压着几十万条任务。最后定位下来根因就是 Java 线程池参数配置不合理——核心线程数设太小、队列用了无界队列、拒绝策略又是默认的抛异常等于把线程池当成了无限缓冲区在使。事后复盘时团队里几个同事对 ThreadPoolExecutor 的参数和执行顺序都只是一知半解于是就有了写这篇内容的想法。这篇文章会围绕 Java 线程池从底层原理到生产实战完整梳理一遍先讲清楚线程池到底在解决什么问题再逐签剖析 ThreadPoolExecutor 的七个核心参数和执行流程然后拆解 Worker 线程的完整生命周期接着给出生产环境参数计算、监控告警和动态调整的实操方案最后复盘几类常见线上故障的排查路径。适合刚接触并发编程的同学建立正确心智模型也适合已经在用线程池但没系统理清源码逻辑、想减少线上事故的资深开发者参考。1. 线程池到底解决了什么问题先搞清楚使用场景再谈配置很多人学线程池喜欢直接背参数这是本末倒置。参数只是手段我们先说线程池存在的根本原因。1.1 线程创建的代价被严重低估了写并发程序时创建一个线程看起来很简单new Thread(() - {}).start()一行代码但 JVM 底层为这行代码要做的事远超大多数人的想象向操作系统发起系统调用创建原生线程、为线程栈分配内存默认 1MB虽然实际使用多少取决于栈深度、注册 JMX 线程对象、触发 ThreadLocal 相关的初始化等等。创建动作本身只是开始线程启动后一旦出现频繁切换CPU 还要保存和恢复线程上下文状态这些开销在高频任务场景下会被无限放大。我见过一个极端案例某接口内部对每个请求都直接new Thread去执行一段第三方调用压测时每秒 500 个请求系统就要创建 500 个线程瞬时线程数到了 1000 多CPU 一半时间都在做线程切换接口 RT 从 20ms 涨到 400ms。这还不是最惨的最惨的是在高并发下线程数失控直接把 CPU 打满整个进程假死。线程池的核心价值就是把创建线程这个昂贵操作变成一次性投入提前创建好一批线程循环复用把任务的提交和任务的执行彻底分离。提交方只管把任务丢给线程池不需要关心哪个线程执行的、什么时候执行的执行方则是固定的几个线程从队列里取任务干完一个接着干下一个。省掉了反复创建销毁的开销也通过池子限制了并发线程数的上限从根上避免了无脑创建线程导致资源耗尽。1.2 任务提交与任务执行解耦带来的三个收益从设计模式角度看线程池本质上是生产者-消费者模型的经典实现。生产者线程调用execute()提交任务消费者线程从工作队列取任务执行中间通过一个阻塞队列解耦。这带来三个非常实际的好处第一是削峰填谷。瞬时涌入的大量请求不会直接冲击到执行线程而是先进入队列排队执行线程按照自己的处理能力匀速消费。就像水库的泄洪闸洪峰来了先蓄水再慢慢放水。第二是资源可控。通过限制 corePoolSize 和 maximumPoolSize线程池把线程数量钉死在上下限之间无论提交方有多疯狂底层的线程数不会超过配置值这等于给系统上了一道保险丝。第三是提升响应速度。任务的提交和执行异步化调用方不需要等任务真正跑完才返回适用于大量扔进去就不管的后台任务场景。1.3 什么样的场景不适合用线程池上面说了线程池这么多好处但它不是万能的。如果你的任务是 CPU 密集型且任务间有严格的先后依赖比如一个复杂计算需要分阶段递进每个阶段依赖上个阶段的结果用线程池反而要额外引入 CountDownLatch、Future、CompletableFuture 这些协调机制代码复杂度上升收益却不大。另外如果你需要任务有非常严格的优先级调度比如实时交易系统的撮合队列线程池的 FIFO 队列不能满足需求需要自己实现优先级队列的延迟任务调度器。还有个常见误区有人以为线程池能解决所有并发问题把线程安全的责任也丢给线程池。实际上线程池只解决了谁来执行、并发上限是多少的问题任务内部如果存在共享资源的竞争该加锁还是得加锁该用原子类还得用原子类线程池不会帮你做任何数据同步。简单说线程管理归线程池数据安全归你自己。2. ThreadPoolExecutor 七参数逐一说清每个参数都是取舍决策ThreadPoolExecutor 的构造函数有五个参数和七个参数两个版本七个参数版本多了 ThreadFactory 和 RejectedExecutionHandler。这张图里每一个参数都不是平白无故存在的背后都对应着一类生产需求。2.1 参数对照表与第一性理解先把七个参数用一张表立起来参数作用默认值关键决策点corePoolSize核心线程数常驻线程数无决定常态并发能力过小会频繁排队过大会浪费资源maximumPoolSize最大线程数无决定峰值并发能力是系统资源的最后一道保险keepAliveTime非核心线程空闲存活时间无决定线程回收节奏配合 queue 大小一起看unit存活时间单位无用对的单位别全用秒workQueue任务等待队列无决定任务的排队策略有界还是无界是最关键的选择threadFactory线程工厂默认工厂自定义线程名、是否为守护线程的关键handler拒绝策略AbortPolicy系统过载时的应对策略直接影响业务可用性但参数本身好背参数之间的联动关系才是真正的难点。很多人只知道core 不够就加到 max再不够就拒绝这太粗糙了。真正完整的工作节奏是提交任务时若当前线程数小于核心线程数直接创建新线程执行若线程数已经达到核心线程数任务先进入队列排队只有当队列也满了才会继续创建新线程直到最大线程数连最大线程都满了才触发拒绝策略。这里最反直觉的点是队列满了才创建非核心线程。这个设计就是为了让线程池在低负载时保持核心线程数尽量复用线程而不是动不动把线程拉到最大值。代价就是如果核心线程处理不过来任务会在队列里排队等待延迟变大但系统不至于被冲垮。2.2 每个参数在真实业务里该怎么定corePoolSize不是越大越好。某支付系统把核心线程数设成 200但业务高峰期并发也只有 80 左右结果 200 个线程大部分时间在 park 等待白白占内存和 OS 线程资源。corePoolSize 应该约等于常态并发量也就是系统平稳运行时并行任务数的平均值。maximumPoolSize要参考系统资源上限不是拍脑袋。一次接口调用的任务要访问数据库、调用外部服务系统能扛住的并发线程数受限于连接池大小、数据库连接数上限超过这些线程数再大也只能排队等连接反而拉高 CPU。maximumPoolSize 一般建议设为 corePoolSize 的 1.5~2 倍或者按系统可承受的极限线程数来定。keepAliveTime unit决定非核心线程的回收节奏。如果峰值时间很短比如秒杀场景只有几分钟keepAliveTime 设 30~60 秒就够了峰值过去后多开的线程很快被回收。如果业务有明显的周期性潮汐比如每天早上 10 点和下午 3 点的抢券高峰keepAliveTime 可以拉长到 5~10 分钟避免高峰频繁创建销毁线程的额外开销。workQueue是最容易踩坑的参数。无界队列LinkedBlockingQueue看起来很方便任务不会丢实际是隐性炸弹消费者处理能力跟不上时任务无限积压内存持续上涨直到 OOM。生产环境我强烈建议使用有界队列配合任务丢弃策略或拒绝策略让系统在过载时有感知地降级而不是无感知地死亡。threadFactory是成本最低但回报最高的参数。默认工厂创建的线程名是pool-1-thread-1线上排查问题时看到这种名字完全不知道是哪个业务在跑。自定义 ThreadFactory 给线程命名为order-async-pool-thread-1一个线程 dump 下去立刻能定位。生产上我基本都自定义。handler有四种内置策略AbortPolicy直接抛异常、CallerRunsPolicy让提交任务的线程自己跑这个任务、DiscardPolicy默默丢弃、DiscardOldestPolicy丢弃队列最老的任务。选哪种没有标准答案取决于业务对丢失任务的容忍度允许当前请求失败并返回错误提示可以用 AbortPolicy需要保证任务一定被执行可以用 CallerRunsPolicy日志场景允许丢可以用 DiscardPolicy。需要明确默认的 AbortPolicy 直接抛RejectedExecutionException如果外层没捕获可能导致任务在用户已经看到响应之后又异步失败需要格外注意调用链上的异常处理。3. 一次任务提交的完整旅行从 execute 入口到 runWorker 的源码拆解参数理解到位了接下来要看代码是怎么执行的。ThreadPoolExecutor 的源码并不难读核心链路就三个方法execute()、addWorker()、runWorker()。我按执行顺序拆开讲每个环节配合源码片段。3.1 execute 方法三段式判断逻辑public void execute(Runnable command) { if (command null) throw new NullPointerException(); int c ctl.get(); // 第一段线程数小于核心线程数尝试创建核心线程 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 第二段线程数已到核心线程数尝试入队 if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); if (!isRunning(recheck) remove(command)) reject(command); else if (workerCountOf(recheck) 0) addWorker(null, false); } // 第三段入队失败队列满了尝试创建非核心线程 else if (!addWorker(command, false)) reject(command); }这段代码的执行顺序决定了前面说的core - queue - max - reject节奏。注意一个细节第二段里任务成功入队后还会重新检查线程池状态和线程数。如果线程池已经被 shutdown刚入队的任务要被移除并拒绝如果线程数是 0比如核心线程数配了 0 但任务又入队了则需要兜底创建一个非核心线程否则队列里的任务永远没人执行。这个三重检查不是多此一举因为workerCountOf(c) corePoolSize之后到addWorker之前是存在时间窗口的期间可能有线程被回收或线程池被关闭所以每次 addWorker 失败都要重新获取状态再走下一步逻辑。理解了这一点回头看那些线程池状态怎么这么复杂的疑问就会清晰很多。3.2 addWorker 方法线程池加锁保护下的线程创建private boolean addWorker(Runnable firstTask, boolean core) { retry: for (;;) { int c ctl.get(); ... for (;;) { int wc workerCountOf(c); if (wc CAPACITY || wc (core ? corePoolSize : maximumPoolSize)) return false; if (compareAndIncrementWorkerCount(c)) break retry; c ctl.get(); ... } } ... Worker w new Worker(firstTask); Thread t w.thread; ... workers.add(w); // 双重检查锁保证 ... t.start(); // 启动线程 ... }这里最值得说的是ctl这个字段。它是一个AtomicInteger高 3 位存线程池运行状态RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED低 29 位存工作线程数。用一个原子变量同时保存两个字段是为了在检查状态和线程数时不需要加锁避免竞态条件。每次都通过compareAndIncrementWorkerCount原子地增加线程数保证同一时刻不会有两批线程同时创建。我在自己读源码时有一个非常深刻的体会addWorker里创建线程和添加 Worker 到workers集合被分成了两步中间采用了双重检查锁的结合方式先用ReentrantLock锁住再检查线程池状态如果状态已经不对了就回滚刚才的workerCount计数。这个细节如果漏看容易误解成线程池不加锁就创建线程。3.3 runWorker 方法线程核心循环与任务执行线程启动后进入 Worker 的run()方法实际干活的是runWorker()public void run() { runWorker(this); } final void runWorker(Worker w) { Thread wt Thread.currentThread(); Runnable task w.firstTask; w.firstTask null; w.unlock(); boolean completedAbruptly true; try { while (task ! null || (task getTask()) ! null) { w.lock(); ... try { task.run(); // 真正执行任务 ... } finally { ... w.unlock(); } } completedAbruptly false; } finally { processWorkerExit(w, completedAbruptly); } }几个关键点w.firstTask是创建 Worker 时携带的第一个任务如果创建 Worker 时没带任务比如addWorker(null, false)就靠getTask()从队列里拿。循环退出的条件只有一个getTask()返回 null这意味着任务队列空了且线程处于空闲状态该被回收。task.run()这条是最容易被误解的地方——ThreadPoolExecutor 在线程里执行任务用的是 Runnable 的run()方法不是start()。因为线程本身已经在运行了直接调用run()才是在当前线程里执行如果调用start()反而会新开线程完全走偏。3.4 任务提交完整链路示意图文字版为了加深理解把整个过程串一遍调用方execute(task)检查当前线程数是否小于核心线程数。小于则新建线程执行否则尝试把任务放入 workQueue。入队成功后重新检查线程池状态若已关闭则移除并拒绝任务若线程数为 0则补建一个工作线程。入队失败队列满继续尝试新建非核心线程若线程数已达 maximumPoolSize则触发拒绝策略。每个工作线程进入 runWorker 循环先从 firstTask 执行再通过 getTask 从队列取任务循环执行。队列为空且线程数超过核心线程数或允许超时回收线程在等待超时后退出。第 4 章会详细展开线程退出这一步因为这是很多人对核心/非核心线程生命周期理解最模糊的地方。4. 核心线程与非核心线程的生死边界Worker 生命周期和两个容易踩的误区4.1 Worker 继承 AQS 的秘密为什么线程池需要可重入锁Worker 类本身继承了AbstractQueuedSynchronizerAQS这在源码里很容易被忽略但它是理解线程池的一个重要符号。每个 Worker 都带一个 state 字段0 表示空闲状态1 表示被占用状态。runWorker中每次执行任务前调用w.lock()执行完调用w.unlock()就是利用这个锁来标记当前线程是否在执行任务。这个锁不是为了保护 workerCount 或队列数据的而是为了配合线程池的关闭机制当线程池执行shutdown()时它需要中断空闲的工作线程但不能中断正在执行任务的线程。如何判断一个线程是空闲还是繁忙就是通过尝试获取 Worker 的锁如果tryLock()成功说明当前 Worker 没在执行任务空闲状态可以安全中断如果失败说明正在执行任务只能等任务执行完再处理。Worker 的锁就是任务执行状态的标记而不是传统的互斥锁。这个设计精妙之处在于它让中断控制变得精细到单个任务粒度。看线程 dump 的时候我也会用它来辅助判断如果一个线程名带pool-order-thread-1并且 state 是WAITING对应getTask()里queue.take()阻塞说明它是空闲工人如果是RUNNABLE且栈帧显示在业务代码里说明它在忙。4.2 getTask 的超时机制核心线程为什么不退出Worker 线程退出全部由getTask()返回值决定它有两种取值方式Runnable r timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take();timed false核心线程调用workQueue.take()当队列为空时线程会无限期阻塞等待新任务这就是核心线程常驻的原理。timed true非核心线程或allowCoreThreadTimeOuttrue的核心线程调用workQueue.poll(keepAliveTime, NANOSECONDS)等待一段时间没有新任务就返回 null线程退出。关键在timed标志的计算当线程数大于核心线程数时所有线程都会被标记为 timed当线程数小于等于核心线程数时只有allowCoreThreadTimeOut为 true 时 timed 才为 true。这也说明核心线程超时退出的前提是你主动调用了allowCoreThreadTimeOut(true)并设置了 keepAliveTime。在很多生产监控中你会发现高峰期开了 30 个线程低谷期只剩核心线程 10 个那些多的线程都是通过poll(keepAliveTime)返回 null 后自然退出的这个过程中 Worker 对象从workers集合里移除JVM 里对应线程也会随之结束。线程池不会调用Thread.interrupt()强制退出空闲线程而是靠队列取任务超时来自然死亡这比强制中断安全得多。4.3 误区一调整 corePoolSize 不会立刻杀死线程setCorePoolSize(int)这个方法在很多运维脚本里被用来动态调参但它并不会立刻把当前线程数砍到新值。它的行为是如果新值小于当前线程数只会让多余的线程在空闲时更快地被回收通过setCorePoolSize内部唤醒空闲 worker触发interruptIdleWorkers但如果这些线程正在执行任务它们会继续执行完之后在 getTask 里因 timed 超时退出。如果你期待降配立即回收线程需要配合setKeepAliveTime和shutdown等机制光调用 setCorePoolSize 不够。同理setMaximumPoolSize调小时也不会杀掉线程它只是收紧未来创建新线程的天花板。4.4 误区二任务队列永远会被最先提交的任务先执行workQueue.offer(command)选择的队列不同任务执行的先后就不同。默认的LinkedBlockingQueue是 FIFO 先入先出但如果你用PriorityBlockingQueue优先级阻塞队列任务可以实现Comparable接口让更高优先级的任务先被取出执行。注意线程池的 execute 是按序提交的但实际被哪个线程执行是不固定的任务顺序只受队列输出顺序影响。这个知识点在生产里的应用是异步任务如果分关键任务和可延迟任务可以考虑自定义优先级队列而不是开两个线程池。当然优先级队列本身需要任务对象实现排序逻辑而且PriorityBlockingQueue不是严格 FIFO 的这块需要自己测试验证。5. 生产环境参数计算与监控告警落地别靠拍脑袋配置线程池前面原理讲透了这一章说最实际的如果公司让你负责一个核心服务的线程池配置你应该怎么定参数、怎么监控、怎么调优。5.1 先从业务指标倒推需要的线程数网上有各种经验公式CPU 密集型设CPU 核数 1IO 密集型设CPU 核数 * 2或CPU 核数 / (1 - 阻塞系数)。这些公式有参考意义但直接套用有风险因为阻塞系数很难精确测量而且一台机器上通常跑着多个服务不是只服务一个线程池。我推荐的思路是从吞吐量目标倒推。假设一个接口的 QPS 需要支持 1000单次任务内部平均耗时是 200ms注意是同步耗时包含 RPC、DB、计算那么同时处于执行状态的任务数大概是并发任务数 QPS * 单任务耗时 1000 * 0.2 200这 200 就是理论需要的并发能力。如果任务中大部分是 IO 等待200 个并发线程可以让 CPU 保持较充分的利用率如果任务是 CPU 密集那 200 个线程反而不合适因为超过 CPU 核数的线程调度开销会吃掉大量性能此时应该用CPU 核数 1作为基准再结合吞吐目标折算。进一步细化公式可以写为线程数 NCPU * Ucpu * (1 W/C)其中 NCPU 是可用 CPU 核数Ucpu 是目标 CPU 利用率比如 0.8预留系统余量W/C 是等待时间与计算时间的比值。IO 密集型的 W/C 很大所以乘出来的线程数可以远超核数CPU 密集型的 W/C 接近于 0线程数约等于核数。实际上大多数业务系统是混合型可以把这个公式作为初始基准再基于压测结果迭代。5.2 队列容量和拒绝策略的配套设计队列容量取决于对延迟的容忍度。如果单任务平均耗时 100ms队列容量设 1000意味着最坏情况下任务要等 100 秒才被处理这对绝大多数在线业务来说不可接受。更合理的做法是从超时时间反推假设业务方允许任务最长等待 5 秒单任务耗时 100ms那么队列深度可以控制在 50 左右。线程池的容量三角是corePoolSize 决定常驻处理能力queueSize 决定缓冲长度maximumPoolSize 决定峰值处理能力。三者需要联动加大 queueSize 和调小 maximumPoolSize 效果类似都增加了等待容忍度但一个消耗内存一个消耗线程资源。在实际生产里宁可让 maximumPoolSize 稍微大一点、队列尽量小一点也不要反过来。因为线程是可控的资源任务积压到内存里膨胀起来是更难排查的。拒绝策略的选择要跟调用方约定好。某电商场景中用CallerRunsPolicy作为降级策略当线程池饱和时由调用方线程自己执行任务虽然会增加调用方接口时延但至少任务不丢、系统不崩。如果你选择自定义 handler记得在 handler 里记录监控指标比如递增一个拒绝任务数计数器而不是只输出一行日志否则过载时日志刷屏会加剧系统压力。5.3 线程池监控指标采集与告警体系没有监控的线程池配置就是盲人摸象。JDK 自带ThreadPoolExecutor支持子类化我建议重写beforeExecute、afterExecute和terminated三个方法把关键指标暴露给监控系统。需要采集的指标至少包括指标获取方式告警阈值建议当前线程数getPoolSize()持续接近 maximumPoolSize活跃线程数getActiveCount()持续等于 poolSize 且队列有积压队列任务积压量getQueue().size()持续超过队列容量的 70%已提交任务总数getTaskCount()用于计算吞吐量已完成任务总数getCompletedTaskCount()结合 taskCount 算成功率历史最大线程数getLargestPoolSize()接近 max 值说明峰值得到了控制拒绝任务数自定义计数器 0 就要重点告警任务平均执行耗时beforeExecute/afterExecute统计超出基线需要关注代码示例简化版public class MonitorableThreadPoolExecutor extends ThreadPoolExecutor { private final AtomicLong rejectedCount new AtomicLong(); private final AtomicLong taskCostNanos new AtomicLong(); public MonitorableThreadPoolExecutor(...) { super(...); } Override protected void beforeExecute(Thread t, Runnable r) { super.beforeExecute(t, r); // 记录开始时间可以用 ThreadLocal 存储 ThreadLocalLong startTime ...; startTime.set(System.nanoTime()); } Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); // 累加任务耗时 } Override public void rejectedExecution(Runnable r, java.util.concurrent.RejectedExecutionHandler handler) { rejectedCount.incrementAndGet(); } }监控体系建立后告警不是只看指标绝对值要看趋势。比如队列积压量偶发飙升可以不用立即告警但持续 3 分钟以上且活跃线程数贴满就需要触发 P1 告警。很多团队只在系统出问题时才去看线程池这是被动的正确的姿势是让线程池指标常态化进入监控大盘容量水位要有预测性告警。5.4 线程池隔离别把所有任务挤在一个池子里一个 JVM 里通常会有多个业务模块如果共用一个线程池某个低优先级的批量任务会把线程池占满导致高优先级业务直接被拒绝。实践上建议按业务线拆分线程池比如异步下单用一个池日志落库用一个池消息推送用一个池。线程数分配各自独立拒绝策略和监控也各自独立。隔离的同时也要注意总量控制。假设三个线程池每个 max 配了 200总线程数 600底层机器却只有 4 核 8 线程那只是在制造更大的竞争。总量设计要从整机承载能力出发分配好配额再拆到各池而不是每个池都按满配设计。某团队曾经给三个业务池各配了 150 线程压测时三个池的任务同时爆发打到数据库连接池直接爆掉根因就是线程总量远超下游可承载的连接数线程都在等数据库连接CPU 却被打满。线程池配置从来不是只算线程池本身的账要看整个调用链路的资源容量。5.5 动态调参不用重启就能调整线程池高并发系统的参数最好做到可动态调整。JDK 提供了setCorePoolSize、setMaximumPoolSize、setKeepAliveTime等方法可以结合配置中心实现免重启调参。我在实践中的做法是把线程池参数放进配置中心变更时监听回调更新 core/max/queue 容量。注意LinkedBlockingQueue的容量大小在创建时固定不能直接修改需要换成自定义的ResizableCapacityLinkedBlockingQueue或者在配置变更时重建线程池。直接重建有风险在途任务会丢失稳妥做法是旧池调用shutdown()新池接手新任务两池并行一段时间直至旧任务执行完。6. 线上事故复盘三类典型线程池故障与完整排查链路原理和配置讲完了用真实事故收尾。这一类问题见得多我把高频的三类故障整理成场景描述 - 排查链路 - 根因 - 修复方案方便大家对照。6.1 事故一无界队列积压导致内存溢出某天某服务的 JVM 频繁 Full GC内存曲线飙升最终 OOM 崩溃。查看监控发现 workQueue 积压了几百万条任务每个任务对象携带一批数据堆直接被打爆。排查链路先看内存监控发现堆使用率曲线呈阶梯式上升没有回落迹象。dump 堆文件用 MAT 分析发现大量任务对象堆积在线程池的LinkedBlockingQueue里。回溯代码发现线程池使用的是无界队列生产环境的任务生产速度远高于消费速度。确认线程数配置core10、max10队列无界等于完全没有背压机制。修复方案将有界队列容量设为 1000并将 maximumPoolSize 提高到 20。拒绝策略改成自定义策略超过容量后记录日志、发送告警同时把任务降级写入本地文件后续异步补偿处理。监控队列长度超过 500 时就预警告警。这里的关键教训是无界队列表面上是不拒绝任务实际是把拒绝推迟到了内存耗尽那一刻而且是以最惨烈的方式。任何线程池都应该设置有界队列这是生产底线。6.2 事故二拒绝策略默认抛异常导致任务静默丢失某消息推送服务高峰期偶发大量推送失败调用方日志里能看到RejectedExecutionException但没有对应的业务日志。上游只知道任务提交失败具体哪个任务丢了完全不可追踪。排查链路从调用方日志找到异常堆栈确认是默认 AbortPolicy 抛出的。查线程池监控发现 activeCount 长期等于 max队列也满说明线程池确实过载了。让开发查代码发现创建线程池时没有显式设置 handler使用的默认策略。进一步发现调用方用execute()提交任务没有 try-catch 包住提交动作异常直接抛到业务外层导致任务丢失且没有补偿。修复方案handler 改成自定义策略记录任务内容到日志同时写入一个待重试表由定时任务补偿处理。调用方侧补一个兜底 try-catch提交失败时至少留痕。队列容量从无界改为有界从根上减少过载概率。这个事故的核心教训有两个第一是默认 AbortPolicy 本身没有错错的是没有显式选择策略、没有考虑过载时的降级方案第二是提交任务的代码没有异常兜底异步任务一旦被拒既不感知也不处理直接静默丢失。实际生产建议无论选哪种策略都要保证提交失败这件事一定被记录和补偿。6.3 事故三核心线程数虚高拖垮下游连接池某服务做了压测优化把 corePoolSize 从 20 调到 100 后数据库连接池突然大量打满SQL 超时率飙升。但这个服务的 CPU 其实没满很多人第一反应是数据库出问题了查了半天发现是线程池配置导致。排查链路查看数据库监控连接数长期占满等待获取连接的时间暴增。查看应用线程数发现线程池线程数 100全部在等待数据库连接返回。核对数据库连接池配置最大连接数是 50线程池并发能力远超连接池承载能力。大量线程在getConnection()上阻塞数据库端 SQL 并发也飙升整体吞吐反而下降。修复方案线程池 core/max 调回 30与数据库连接池 50 的额度匹配留出安全余量。调整时考虑下游一切资源的上限线程池 max 不能超过数据库连接池、外部服务线程池、消息队列消费者等下游瓶颈的最小值。增加动态配置能力压测时如果发现需要更高并发再按链路容量逐步上调。这个事故说明线程池参数不是独立的它是一个链路上的资源配额之一。计算 max 值时必须同步确认下游各资源的瓶颈否则更高的并发只会从上游转移到下游的排队等待整体 RT 变得更差。6.4 给排查线程池问题的一份检查清单如果线上线程池指标异常个人建议按以下顺序排查确认线程池名称线程 dump 里能看到业务命名吗看到 pool-xx-thread 就知道没自定义 ThreadFactory这是第一层损失。看线程池监控的五个数poolSize、activeCount、queueSize、taskCount、completedTaskCount。哪个异常先处理哪个。根据 queueSize 积压情况判断生产端和消费端的速度比是突发流量还是持续过载。看拒绝策略计数器是否大于 0有拒绝意味着线程池已经饱和需要快速扩容或限流。线程 dump 检查工作线程状态大量 WAITING 说明空闲大量 RUNNABLE 在业务代码里说明正在执行跑在锁竞争上说明任务内部有锁问题不是线程池问题。复盘任务本身耗时如果单任务从 100ms 涨到 1s那不是文件数配少了是下游变慢了调整文件数没用要找下游根因。这套清单在多个故障中帮我快速缩小了范围。线程池参数出问题往往不是线程池本身的问题而是业务方对任务耗时、下游容量、突刺峰值的认知出现了偏差线程池只是把这些问题具象化地暴露出来。7. 几个进阶实践从会用到用得优雅7.1 动态线程数配合压测回归如果有条件把线程池参数做成可配置的并建立一套压测回归基线。每次发布前用固定比例的压测流量跑一遍接口对比线程池指标的基线变化。如果一次普通的业务发布导致线程池 activeCount 翻倍、queueSize 开始堆积说明新版本里存在性能劣化要提前定位而不是等高峰期自然暴露。我之前所在的团队有一个固定的例行动作每周对核心服务做一次小流量压测覆盖线程池的队列积压、拒绝次数和 RT 三个核心指标。半年下来提前发现了十几个潜在的过载风险都是平时低峰期很难暴露、高峰期一旦爆发就是事故的问题。7.2 CompletableFuture 与线程池搭配的陷阱Java 8 之后异步编程最常用的就是CompletableFuture但它默认使用ForkJoinPool.commonPool()这个池的大小是CPU 核数 - 1非常容易被打满。生产环境强烈建议所有 CompletableFuture 都显式传入自定义线程池否则多个业务模块共用公共池会互相影响。这里有个隐蔽的坑CompletableFuture的thenApplyAsync()如果你传了自定义线程池它和supplyAsync()用的线程池可能不是同一个。如果你在thenApplyAsync里又调用了另一个thenApplyAsync且不传池它会回到默认的 commonPool两池并发时线程调度结果会很混乱。建议写一个统一封装所有异步编排都强制指定同一个业务线程池避免这种微妙的问题。7.3 线程池优雅停机shutdown 和 shutdownNow 怎么选shutdown()会让线程池不再接受新任务已入队的任务继续执行完再停止shutdownNow()会尝试中断所有运行中的线程并返回尚未执行的任务列表。选择哪一个是业务取舍问题如果任务是幂等的、短耗时的shutdown更安全如果任务是长耗时的、可以安全中断的、且不能阻塞停机流程shutdownNow更合适。但要注意shutdownNow()依赖于线程能够响应中断。如果任务代码里捕获了InterruptedException又没重新设置中断标志或者阻塞调用不响应中断线程可能无法及时退出JVM 进程也就无法优雅停机。所以配合线程池停机任务内部对中断标志要遵循一条准则捕获中断异常后随手Thread.currentThread().interrupt()重新置位让上层能看到中断请求。7.4 任务耗时异常时要先排查业务代码而不是调参数线程池调优有一个很容易犯的方向性错误任务变慢时就调大线程数。实际上任务变慢更大概率是下游服务变慢、数据库出现慢查询、锁竞争加剧等原因。调大线程数只是放大了对这些慢资源的压力让问题更严重。正确的做法是先用 profiling 定位慢的根因等任务耗时恢复正常后再回头看线程池水位。我见过一个最典型的反面案例某服务依赖的外部接口 RT 从 200ms 涨到 2s开发把线程池从 20 调到 100结果这 100 个线程全部卡在外部调用上外部系统被打得更慢最终两边一起雪崩。如果先把下游的慢调用找出来降级或熔断线程池根本不需要调整。8. 写在最后的几个小原则Java 线程池是个学习曲线比较陡峭的组件参数之间的联动性很强网上很多文章要么只讲参数、要么只讲源码缺少生产环境到底怎么用这条线。写这篇内容时我尽力把原理、源码、监控、故障串起来希望能减少一些大家实际踩坑的成本。个人体会最深的三件事第一线程池参数没有标准答案任何公式和配置都要基于你自己的业务场景、吞吐目标和下游容量去验证。网上抄一份配置到生产是不负责任的做法必须经过压测和监控数据验证。第二无界队列是生产红线默认拒绝策略是隐雷自定义线程名是成本最低的保命手段。这三条是硬性约束回看所有线程池事故几乎都跟这三条有关。第三监控和动态调参比精妙的参数计算更重要。你永远无法预测线上真实的流量形态能做的就是让线程池的行为可观测、可调整、可恢复。每次线上事故后我都会把线程池的指标翻出来复盘问自己三个问题为什么当时没有预警告警如果在过载前一步就通过动态调参扩容是不是可以完全规避这个经验能不能沉淀成自动化的容量评估规则线程池只是工具真正重要的是你对自己系统的理解深度。配置可以抄经验不能抄希望对看到这里的你有帮助。
最近一个线上事故让我印象很深某服务在晚高峰突然响应变慢CPU 冲到 90% 以上线程 dump 里能看到大量RUNNABLE线程在疯狂抢占锁而队列里还积压着几十万条任务。最后定位下来根因就是 Java 线程池参数配置不合理——核心线程数设太小、队列用了无界队列、拒绝策略又是默认的抛异常等于把线程池当成了无限缓冲区在使。事后复盘时团队里几个同事对 ThreadPoolExecutor 的参数和执行顺序都只是一知半解于是就有了写这篇内容的想法。这篇文章会围绕 Java 线程池从底层原理到生产实战完整梳理一遍先讲清楚线程池到底在解决什么问题再逐签剖析 ThreadPoolExecutor 的七个核心参数和执行流程然后拆解 Worker 线程的完整生命周期接着给出生产环境参数计算、监控告警和动态调整的实操方案最后复盘几类常见线上故障的排查路径。适合刚接触并发编程的同学建立正确心智模型也适合已经在用线程池但没系统理清源码逻辑、想减少线上事故的资深开发者参考。1. 线程池到底解决了什么问题先搞清楚使用场景再谈配置很多人学线程池喜欢直接背参数这是本末倒置。参数只是手段我们先说线程池存在的根本原因。1.1 线程创建的代价被严重低估了写并发程序时创建一个线程看起来很简单new Thread(() - {}).start()一行代码但 JVM 底层为这行代码要做的事远超大多数人的想象向操作系统发起系统调用创建原生线程、为线程栈分配内存默认 1MB虽然实际使用多少取决于栈深度、注册 JMX 线程对象、触发 ThreadLocal 相关的初始化等等。创建动作本身只是开始线程启动后一旦出现频繁切换CPU 还要保存和恢复线程上下文状态这些开销在高频任务场景下会被无限放大。我见过一个极端案例某接口内部对每个请求都直接new Thread去执行一段第三方调用压测时每秒 500 个请求系统就要创建 500 个线程瞬时线程数到了 1000 多CPU 一半时间都在做线程切换接口 RT 从 20ms 涨到 400ms。这还不是最惨的最惨的是在高并发下线程数失控直接把 CPU 打满整个进程假死。线程池的核心价值就是把创建线程这个昂贵操作变成一次性投入提前创建好一批线程循环复用把任务的提交和任务的执行彻底分离。提交方只管把任务丢给线程池不需要关心哪个线程执行的、什么时候执行的执行方则是固定的几个线程从队列里取任务干完一个接着干下一个。省掉了反复创建销毁的开销也通过池子限制了并发线程数的上限从根上避免了无脑创建线程导致资源耗尽。1.2 任务提交与任务执行解耦带来的三个收益从设计模式角度看线程池本质上是生产者-消费者模型的经典实现。生产者线程调用execute()提交任务消费者线程从工作队列取任务执行中间通过一个阻塞队列解耦。这带来三个非常实际的好处第一是削峰填谷。瞬时涌入的大量请求不会直接冲击到执行线程而是先进入队列排队执行线程按照自己的处理能力匀速消费。就像水库的泄洪闸洪峰来了先蓄水再慢慢放水。第二是资源可控。通过限制 corePoolSize 和 maximumPoolSize线程池把线程数量钉死在上下限之间无论提交方有多疯狂底层的线程数不会超过配置值这等于给系统上了一道保险丝。第三是提升响应速度。任务的提交和执行异步化调用方不需要等任务真正跑完才返回适用于大量扔进去就不管的后台任务场景。1.3 什么样的场景不适合用线程池上面说了线程池这么多好处但它不是万能的。如果你的任务是 CPU 密集型且任务间有严格的先后依赖比如一个复杂计算需要分阶段递进每个阶段依赖上个阶段的结果用线程池反而要额外引入 CountDownLatch、Future、CompletableFuture 这些协调机制代码复杂度上升收益却不大。另外如果你需要任务有非常严格的优先级调度比如实时交易系统的撮合队列线程池的 FIFO 队列不能满足需求需要自己实现优先级队列的延迟任务调度器。还有个常见误区有人以为线程池能解决所有并发问题把线程安全的责任也丢给线程池。实际上线程池只解决了谁来执行、并发上限是多少的问题任务内部如果存在共享资源的竞争该加锁还是得加锁该用原子类还得用原子类线程池不会帮你做任何数据同步。简单说线程管理归线程池数据安全归你自己。2. ThreadPoolExecutor 七参数逐一说清每个参数都是取舍决策ThreadPoolExecutor 的构造函数有五个参数和七个参数两个版本七个参数版本多了 ThreadFactory 和 RejectedExecutionHandler。这张图里每一个参数都不是平白无故存在的背后都对应着一类生产需求。2.1 参数对照表与第一性理解先把七个参数用一张表立起来参数作用默认值关键决策点corePoolSize核心线程数常驻线程数无决定常态并发能力过小会频繁排队过大会浪费资源maximumPoolSize最大线程数无决定峰值并发能力是系统资源的最后一道保险keepAliveTime非核心线程空闲存活时间无决定线程回收节奏配合 queue 大小一起看unit存活时间单位无用对的单位别全用秒workQueue任务等待队列无决定任务的排队策略有界还是无界是最关键的选择threadFactory线程工厂默认工厂自定义线程名、是否为守护线程的关键handler拒绝策略AbortPolicy系统过载时的应对策略直接影响业务可用性但参数本身好背参数之间的联动关系才是真正的难点。很多人只知道core 不够就加到 max再不够就拒绝这太粗糙了。真正完整的工作节奏是提交任务时若当前线程数小于核心线程数直接创建新线程执行若线程数已经达到核心线程数任务先进入队列排队只有当队列也满了才会继续创建新线程直到最大线程数连最大线程都满了才触发拒绝策略。这里最反直觉的点是队列满了才创建非核心线程。这个设计就是为了让线程池在低负载时保持核心线程数尽量复用线程而不是动不动把线程拉到最大值。代价就是如果核心线程处理不过来任务会在队列里排队等待延迟变大但系统不至于被冲垮。2.2 每个参数在真实业务里该怎么定corePoolSize不是越大越好。某支付系统把核心线程数设成 200但业务高峰期并发也只有 80 左右结果 200 个线程大部分时间在 park 等待白白占内存和 OS 线程资源。corePoolSize 应该约等于常态并发量也就是系统平稳运行时并行任务数的平均值。maximumPoolSize要参考系统资源上限不是拍脑袋。一次接口调用的任务要访问数据库、调用外部服务系统能扛住的并发线程数受限于连接池大小、数据库连接数上限超过这些线程数再大也只能排队等连接反而拉高 CPU。maximumPoolSize 一般建议设为 corePoolSize 的 1.5~2 倍或者按系统可承受的极限线程数来定。keepAliveTime unit决定非核心线程的回收节奏。如果峰值时间很短比如秒杀场景只有几分钟keepAliveTime 设 30~60 秒就够了峰值过去后多开的线程很快被回收。如果业务有明显的周期性潮汐比如每天早上 10 点和下午 3 点的抢券高峰keepAliveTime 可以拉长到 5~10 分钟避免高峰频繁创建销毁线程的额外开销。workQueue是最容易踩坑的参数。无界队列LinkedBlockingQueue看起来很方便任务不会丢实际是隐性炸弹消费者处理能力跟不上时任务无限积压内存持续上涨直到 OOM。生产环境我强烈建议使用有界队列配合任务丢弃策略或拒绝策略让系统在过载时有感知地降级而不是无感知地死亡。threadFactory是成本最低但回报最高的参数。默认工厂创建的线程名是pool-1-thread-1线上排查问题时看到这种名字完全不知道是哪个业务在跑。自定义 ThreadFactory 给线程命名为order-async-pool-thread-1一个线程 dump 下去立刻能定位。生产上我基本都自定义。handler有四种内置策略AbortPolicy直接抛异常、CallerRunsPolicy让提交任务的线程自己跑这个任务、DiscardPolicy默默丢弃、DiscardOldestPolicy丢弃队列最老的任务。选哪种没有标准答案取决于业务对丢失任务的容忍度允许当前请求失败并返回错误提示可以用 AbortPolicy需要保证任务一定被执行可以用 CallerRunsPolicy日志场景允许丢可以用 DiscardPolicy。需要明确默认的 AbortPolicy 直接抛RejectedExecutionException如果外层没捕获可能导致任务在用户已经看到响应之后又异步失败需要格外注意调用链上的异常处理。3. 一次任务提交的完整旅行从 execute 入口到 runWorker 的源码拆解参数理解到位了接下来要看代码是怎么执行的。ThreadPoolExecutor 的源码并不难读核心链路就三个方法execute()、addWorker()、runWorker()。我按执行顺序拆开讲每个环节配合源码片段。3.1 execute 方法三段式判断逻辑public void execute(Runnable command) { if (command null) throw new NullPointerException(); int c ctl.get(); // 第一段线程数小于核心线程数尝试创建核心线程 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 第二段线程数已到核心线程数尝试入队 if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); if (!isRunning(recheck) remove(command)) reject(command); else if (workerCountOf(recheck) 0) addWorker(null, false); } // 第三段入队失败队列满了尝试创建非核心线程 else if (!addWorker(command, false)) reject(command); }这段代码的执行顺序决定了前面说的core - queue - max - reject节奏。注意一个细节第二段里任务成功入队后还会重新检查线程池状态和线程数。如果线程池已经被 shutdown刚入队的任务要被移除并拒绝如果线程数是 0比如核心线程数配了 0 但任务又入队了则需要兜底创建一个非核心线程否则队列里的任务永远没人执行。这个三重检查不是多此一举因为workerCountOf(c) corePoolSize之后到addWorker之前是存在时间窗口的期间可能有线程被回收或线程池被关闭所以每次 addWorker 失败都要重新获取状态再走下一步逻辑。理解了这一点回头看那些线程池状态怎么这么复杂的疑问就会清晰很多。3.2 addWorker 方法线程池加锁保护下的线程创建private boolean addWorker(Runnable firstTask, boolean core) { retry: for (;;) { int c ctl.get(); ... for (;;) { int wc workerCountOf(c); if (wc CAPACITY || wc (core ? corePoolSize : maximumPoolSize)) return false; if (compareAndIncrementWorkerCount(c)) break retry; c ctl.get(); ... } } ... Worker w new Worker(firstTask); Thread t w.thread; ... workers.add(w); // 双重检查锁保证 ... t.start(); // 启动线程 ... }这里最值得说的是ctl这个字段。它是一个AtomicInteger高 3 位存线程池运行状态RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED低 29 位存工作线程数。用一个原子变量同时保存两个字段是为了在检查状态和线程数时不需要加锁避免竞态条件。每次都通过compareAndIncrementWorkerCount原子地增加线程数保证同一时刻不会有两批线程同时创建。我在自己读源码时有一个非常深刻的体会addWorker里创建线程和添加 Worker 到workers集合被分成了两步中间采用了双重检查锁的结合方式先用ReentrantLock锁住再检查线程池状态如果状态已经不对了就回滚刚才的workerCount计数。这个细节如果漏看容易误解成线程池不加锁就创建线程。3.3 runWorker 方法线程核心循环与任务执行线程启动后进入 Worker 的run()方法实际干活的是runWorker()public void run() { runWorker(this); } final void runWorker(Worker w) { Thread wt Thread.currentThread(); Runnable task w.firstTask; w.firstTask null; w.unlock(); boolean completedAbruptly true; try { while (task ! null || (task getTask()) ! null) { w.lock(); ... try { task.run(); // 真正执行任务 ... } finally { ... w.unlock(); } } completedAbruptly false; } finally { processWorkerExit(w, completedAbruptly); } }几个关键点w.firstTask是创建 Worker 时携带的第一个任务如果创建 Worker 时没带任务比如addWorker(null, false)就靠getTask()从队列里拿。循环退出的条件只有一个getTask()返回 null这意味着任务队列空了且线程处于空闲状态该被回收。task.run()这条是最容易被误解的地方——ThreadPoolExecutor 在线程里执行任务用的是 Runnable 的run()方法不是start()。因为线程本身已经在运行了直接调用run()才是在当前线程里执行如果调用start()反而会新开线程完全走偏。3.4 任务提交完整链路示意图文字版为了加深理解把整个过程串一遍调用方execute(task)检查当前线程数是否小于核心线程数。小于则新建线程执行否则尝试把任务放入 workQueue。入队成功后重新检查线程池状态若已关闭则移除并拒绝任务若线程数为 0则补建一个工作线程。入队失败队列满继续尝试新建非核心线程若线程数已达 maximumPoolSize则触发拒绝策略。每个工作线程进入 runWorker 循环先从 firstTask 执行再通过 getTask 从队列取任务循环执行。队列为空且线程数超过核心线程数或允许超时回收线程在等待超时后退出。第 4 章会详细展开线程退出这一步因为这是很多人对核心/非核心线程生命周期理解最模糊的地方。4. 核心线程与非核心线程的生死边界Worker 生命周期和两个容易踩的误区4.1 Worker 继承 AQS 的秘密为什么线程池需要可重入锁Worker 类本身继承了AbstractQueuedSynchronizerAQS这在源码里很容易被忽略但它是理解线程池的一个重要符号。每个 Worker 都带一个 state 字段0 表示空闲状态1 表示被占用状态。runWorker中每次执行任务前调用w.lock()执行完调用w.unlock()就是利用这个锁来标记当前线程是否在执行任务。这个锁不是为了保护 workerCount 或队列数据的而是为了配合线程池的关闭机制当线程池执行shutdown()时它需要中断空闲的工作线程但不能中断正在执行任务的线程。如何判断一个线程是空闲还是繁忙就是通过尝试获取 Worker 的锁如果tryLock()成功说明当前 Worker 没在执行任务空闲状态可以安全中断如果失败说明正在执行任务只能等任务执行完再处理。Worker 的锁就是任务执行状态的标记而不是传统的互斥锁。这个设计精妙之处在于它让中断控制变得精细到单个任务粒度。看线程 dump 的时候我也会用它来辅助判断如果一个线程名带pool-order-thread-1并且 state 是WAITING对应getTask()里queue.take()阻塞说明它是空闲工人如果是RUNNABLE且栈帧显示在业务代码里说明它在忙。4.2 getTask 的超时机制核心线程为什么不退出Worker 线程退出全部由getTask()返回值决定它有两种取值方式Runnable r timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take();timed false核心线程调用workQueue.take()当队列为空时线程会无限期阻塞等待新任务这就是核心线程常驻的原理。timed true非核心线程或allowCoreThreadTimeOuttrue的核心线程调用workQueue.poll(keepAliveTime, NANOSECONDS)等待一段时间没有新任务就返回 null线程退出。关键在timed标志的计算当线程数大于核心线程数时所有线程都会被标记为 timed当线程数小于等于核心线程数时只有allowCoreThreadTimeOut为 true 时 timed 才为 true。这也说明核心线程超时退出的前提是你主动调用了allowCoreThreadTimeOut(true)并设置了 keepAliveTime。在很多生产监控中你会发现高峰期开了 30 个线程低谷期只剩核心线程 10 个那些多的线程都是通过poll(keepAliveTime)返回 null 后自然退出的这个过程中 Worker 对象从workers集合里移除JVM 里对应线程也会随之结束。线程池不会调用Thread.interrupt()强制退出空闲线程而是靠队列取任务超时来自然死亡这比强制中断安全得多。4.3 误区一调整 corePoolSize 不会立刻杀死线程setCorePoolSize(int)这个方法在很多运维脚本里被用来动态调参但它并不会立刻把当前线程数砍到新值。它的行为是如果新值小于当前线程数只会让多余的线程在空闲时更快地被回收通过setCorePoolSize内部唤醒空闲 worker触发interruptIdleWorkers但如果这些线程正在执行任务它们会继续执行完之后在 getTask 里因 timed 超时退出。如果你期待降配立即回收线程需要配合setKeepAliveTime和shutdown等机制光调用 setCorePoolSize 不够。同理setMaximumPoolSize调小时也不会杀掉线程它只是收紧未来创建新线程的天花板。4.4 误区二任务队列永远会被最先提交的任务先执行workQueue.offer(command)选择的队列不同任务执行的先后就不同。默认的LinkedBlockingQueue是 FIFO 先入先出但如果你用PriorityBlockingQueue优先级阻塞队列任务可以实现Comparable接口让更高优先级的任务先被取出执行。注意线程池的 execute 是按序提交的但实际被哪个线程执行是不固定的任务顺序只受队列输出顺序影响。这个知识点在生产里的应用是异步任务如果分关键任务和可延迟任务可以考虑自定义优先级队列而不是开两个线程池。当然优先级队列本身需要任务对象实现排序逻辑而且PriorityBlockingQueue不是严格 FIFO 的这块需要自己测试验证。5. 生产环境参数计算与监控告警落地别靠拍脑袋配置线程池前面原理讲透了这一章说最实际的如果公司让你负责一个核心服务的线程池配置你应该怎么定参数、怎么监控、怎么调优。5.1 先从业务指标倒推需要的线程数网上有各种经验公式CPU 密集型设CPU 核数 1IO 密集型设CPU 核数 * 2或CPU 核数 / (1 - 阻塞系数)。这些公式有参考意义但直接套用有风险因为阻塞系数很难精确测量而且一台机器上通常跑着多个服务不是只服务一个线程池。我推荐的思路是从吞吐量目标倒推。假设一个接口的 QPS 需要支持 1000单次任务内部平均耗时是 200ms注意是同步耗时包含 RPC、DB、计算那么同时处于执行状态的任务数大概是并发任务数 QPS * 单任务耗时 1000 * 0.2 200这 200 就是理论需要的并发能力。如果任务中大部分是 IO 等待200 个并发线程可以让 CPU 保持较充分的利用率如果任务是 CPU 密集那 200 个线程反而不合适因为超过 CPU 核数的线程调度开销会吃掉大量性能此时应该用CPU 核数 1作为基准再结合吞吐目标折算。进一步细化公式可以写为线程数 NCPU * Ucpu * (1 W/C)其中 NCPU 是可用 CPU 核数Ucpu 是目标 CPU 利用率比如 0.8预留系统余量W/C 是等待时间与计算时间的比值。IO 密集型的 W/C 很大所以乘出来的线程数可以远超核数CPU 密集型的 W/C 接近于 0线程数约等于核数。实际上大多数业务系统是混合型可以把这个公式作为初始基准再基于压测结果迭代。5.2 队列容量和拒绝策略的配套设计队列容量取决于对延迟的容忍度。如果单任务平均耗时 100ms队列容量设 1000意味着最坏情况下任务要等 100 秒才被处理这对绝大多数在线业务来说不可接受。更合理的做法是从超时时间反推假设业务方允许任务最长等待 5 秒单任务耗时 100ms那么队列深度可以控制在 50 左右。线程池的容量三角是corePoolSize 决定常驻处理能力queueSize 决定缓冲长度maximumPoolSize 决定峰值处理能力。三者需要联动加大 queueSize 和调小 maximumPoolSize 效果类似都增加了等待容忍度但一个消耗内存一个消耗线程资源。在实际生产里宁可让 maximumPoolSize 稍微大一点、队列尽量小一点也不要反过来。因为线程是可控的资源任务积压到内存里膨胀起来是更难排查的。拒绝策略的选择要跟调用方约定好。某电商场景中用CallerRunsPolicy作为降级策略当线程池饱和时由调用方线程自己执行任务虽然会增加调用方接口时延但至少任务不丢、系统不崩。如果你选择自定义 handler记得在 handler 里记录监控指标比如递增一个拒绝任务数计数器而不是只输出一行日志否则过载时日志刷屏会加剧系统压力。5.3 线程池监控指标采集与告警体系没有监控的线程池配置就是盲人摸象。JDK 自带ThreadPoolExecutor支持子类化我建议重写beforeExecute、afterExecute和terminated三个方法把关键指标暴露给监控系统。需要采集的指标至少包括指标获取方式告警阈值建议当前线程数getPoolSize()持续接近 maximumPoolSize活跃线程数getActiveCount()持续等于 poolSize 且队列有积压队列任务积压量getQueue().size()持续超过队列容量的 70%已提交任务总数getTaskCount()用于计算吞吐量已完成任务总数getCompletedTaskCount()结合 taskCount 算成功率历史最大线程数getLargestPoolSize()接近 max 值说明峰值得到了控制拒绝任务数自定义计数器 0 就要重点告警任务平均执行耗时beforeExecute/afterExecute统计超出基线需要关注代码示例简化版public class MonitorableThreadPoolExecutor extends ThreadPoolExecutor { private final AtomicLong rejectedCount new AtomicLong(); private final AtomicLong taskCostNanos new AtomicLong(); public MonitorableThreadPoolExecutor(...) { super(...); } Override protected void beforeExecute(Thread t, Runnable r) { super.beforeExecute(t, r); // 记录开始时间可以用 ThreadLocal 存储 ThreadLocalLong startTime ...; startTime.set(System.nanoTime()); } Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); // 累加任务耗时 } Override public void rejectedExecution(Runnable r, java.util.concurrent.RejectedExecutionHandler handler) { rejectedCount.incrementAndGet(); } }监控体系建立后告警不是只看指标绝对值要看趋势。比如队列积压量偶发飙升可以不用立即告警但持续 3 分钟以上且活跃线程数贴满就需要触发 P1 告警。很多团队只在系统出问题时才去看线程池这是被动的正确的姿势是让线程池指标常态化进入监控大盘容量水位要有预测性告警。5.4 线程池隔离别把所有任务挤在一个池子里一个 JVM 里通常会有多个业务模块如果共用一个线程池某个低优先级的批量任务会把线程池占满导致高优先级业务直接被拒绝。实践上建议按业务线拆分线程池比如异步下单用一个池日志落库用一个池消息推送用一个池。线程数分配各自独立拒绝策略和监控也各自独立。隔离的同时也要注意总量控制。假设三个线程池每个 max 配了 200总线程数 600底层机器却只有 4 核 8 线程那只是在制造更大的竞争。总量设计要从整机承载能力出发分配好配额再拆到各池而不是每个池都按满配设计。某团队曾经给三个业务池各配了 150 线程压测时三个池的任务同时爆发打到数据库连接池直接爆掉根因就是线程总量远超下游可承载的连接数线程都在等数据库连接CPU 却被打满。线程池配置从来不是只算线程池本身的账要看整个调用链路的资源容量。5.5 动态调参不用重启就能调整线程池高并发系统的参数最好做到可动态调整。JDK 提供了setCorePoolSize、setMaximumPoolSize、setKeepAliveTime等方法可以结合配置中心实现免重启调参。我在实践中的做法是把线程池参数放进配置中心变更时监听回调更新 core/max/queue 容量。注意LinkedBlockingQueue的容量大小在创建时固定不能直接修改需要换成自定义的ResizableCapacityLinkedBlockingQueue或者在配置变更时重建线程池。直接重建有风险在途任务会丢失稳妥做法是旧池调用shutdown()新池接手新任务两池并行一段时间直至旧任务执行完。6. 线上事故复盘三类典型线程池故障与完整排查链路原理和配置讲完了用真实事故收尾。这一类问题见得多我把高频的三类故障整理成场景描述 - 排查链路 - 根因 - 修复方案方便大家对照。6.1 事故一无界队列积压导致内存溢出某天某服务的 JVM 频繁 Full GC内存曲线飙升最终 OOM 崩溃。查看监控发现 workQueue 积压了几百万条任务每个任务对象携带一批数据堆直接被打爆。排查链路先看内存监控发现堆使用率曲线呈阶梯式上升没有回落迹象。dump 堆文件用 MAT 分析发现大量任务对象堆积在线程池的LinkedBlockingQueue里。回溯代码发现线程池使用的是无界队列生产环境的任务生产速度远高于消费速度。确认线程数配置core10、max10队列无界等于完全没有背压机制。修复方案将有界队列容量设为 1000并将 maximumPoolSize 提高到 20。拒绝策略改成自定义策略超过容量后记录日志、发送告警同时把任务降级写入本地文件后续异步补偿处理。监控队列长度超过 500 时就预警告警。这里的关键教训是无界队列表面上是不拒绝任务实际是把拒绝推迟到了内存耗尽那一刻而且是以最惨烈的方式。任何线程池都应该设置有界队列这是生产底线。6.2 事故二拒绝策略默认抛异常导致任务静默丢失某消息推送服务高峰期偶发大量推送失败调用方日志里能看到RejectedExecutionException但没有对应的业务日志。上游只知道任务提交失败具体哪个任务丢了完全不可追踪。排查链路从调用方日志找到异常堆栈确认是默认 AbortPolicy 抛出的。查线程池监控发现 activeCount 长期等于 max队列也满说明线程池确实过载了。让开发查代码发现创建线程池时没有显式设置 handler使用的默认策略。进一步发现调用方用execute()提交任务没有 try-catch 包住提交动作异常直接抛到业务外层导致任务丢失且没有补偿。修复方案handler 改成自定义策略记录任务内容到日志同时写入一个待重试表由定时任务补偿处理。调用方侧补一个兜底 try-catch提交失败时至少留痕。队列容量从无界改为有界从根上减少过载概率。这个事故的核心教训有两个第一是默认 AbortPolicy 本身没有错错的是没有显式选择策略、没有考虑过载时的降级方案第二是提交任务的代码没有异常兜底异步任务一旦被拒既不感知也不处理直接静默丢失。实际生产建议无论选哪种策略都要保证提交失败这件事一定被记录和补偿。6.3 事故三核心线程数虚高拖垮下游连接池某服务做了压测优化把 corePoolSize 从 20 调到 100 后数据库连接池突然大量打满SQL 超时率飙升。但这个服务的 CPU 其实没满很多人第一反应是数据库出问题了查了半天发现是线程池配置导致。排查链路查看数据库监控连接数长期占满等待获取连接的时间暴增。查看应用线程数发现线程池线程数 100全部在等待数据库连接返回。核对数据库连接池配置最大连接数是 50线程池并发能力远超连接池承载能力。大量线程在getConnection()上阻塞数据库端 SQL 并发也飙升整体吞吐反而下降。修复方案线程池 core/max 调回 30与数据库连接池 50 的额度匹配留出安全余量。调整时考虑下游一切资源的上限线程池 max 不能超过数据库连接池、外部服务线程池、消息队列消费者等下游瓶颈的最小值。增加动态配置能力压测时如果发现需要更高并发再按链路容量逐步上调。这个事故说明线程池参数不是独立的它是一个链路上的资源配额之一。计算 max 值时必须同步确认下游各资源的瓶颈否则更高的并发只会从上游转移到下游的排队等待整体 RT 变得更差。6.4 给排查线程池问题的一份检查清单如果线上线程池指标异常个人建议按以下顺序排查确认线程池名称线程 dump 里能看到业务命名吗看到 pool-xx-thread 就知道没自定义 ThreadFactory这是第一层损失。看线程池监控的五个数poolSize、activeCount、queueSize、taskCount、completedTaskCount。哪个异常先处理哪个。根据 queueSize 积压情况判断生产端和消费端的速度比是突发流量还是持续过载。看拒绝策略计数器是否大于 0有拒绝意味着线程池已经饱和需要快速扩容或限流。线程 dump 检查工作线程状态大量 WAITING 说明空闲大量 RUNNABLE 在业务代码里说明正在执行跑在锁竞争上说明任务内部有锁问题不是线程池问题。复盘任务本身耗时如果单任务从 100ms 涨到 1s那不是文件数配少了是下游变慢了调整文件数没用要找下游根因。这套清单在多个故障中帮我快速缩小了范围。线程池参数出问题往往不是线程池本身的问题而是业务方对任务耗时、下游容量、突刺峰值的认知出现了偏差线程池只是把这些问题具象化地暴露出来。7. 几个进阶实践从会用到用得优雅7.1 动态线程数配合压测回归如果有条件把线程池参数做成可配置的并建立一套压测回归基线。每次发布前用固定比例的压测流量跑一遍接口对比线程池指标的基线变化。如果一次普通的业务发布导致线程池 activeCount 翻倍、queueSize 开始堆积说明新版本里存在性能劣化要提前定位而不是等高峰期自然暴露。我之前所在的团队有一个固定的例行动作每周对核心服务做一次小流量压测覆盖线程池的队列积压、拒绝次数和 RT 三个核心指标。半年下来提前发现了十几个潜在的过载风险都是平时低峰期很难暴露、高峰期一旦爆发就是事故的问题。7.2 CompletableFuture 与线程池搭配的陷阱Java 8 之后异步编程最常用的就是CompletableFuture但它默认使用ForkJoinPool.commonPool()这个池的大小是CPU 核数 - 1非常容易被打满。生产环境强烈建议所有 CompletableFuture 都显式传入自定义线程池否则多个业务模块共用公共池会互相影响。这里有个隐蔽的坑CompletableFuture的thenApplyAsync()如果你传了自定义线程池它和supplyAsync()用的线程池可能不是同一个。如果你在thenApplyAsync里又调用了另一个thenApplyAsync且不传池它会回到默认的 commonPool两池并发时线程调度结果会很混乱。建议写一个统一封装所有异步编排都强制指定同一个业务线程池避免这种微妙的问题。7.3 线程池优雅停机shutdown 和 shutdownNow 怎么选shutdown()会让线程池不再接受新任务已入队的任务继续执行完再停止shutdownNow()会尝试中断所有运行中的线程并返回尚未执行的任务列表。选择哪一个是业务取舍问题如果任务是幂等的、短耗时的shutdown更安全如果任务是长耗时的、可以安全中断的、且不能阻塞停机流程shutdownNow更合适。但要注意shutdownNow()依赖于线程能够响应中断。如果任务代码里捕获了InterruptedException又没重新设置中断标志或者阻塞调用不响应中断线程可能无法及时退出JVM 进程也就无法优雅停机。所以配合线程池停机任务内部对中断标志要遵循一条准则捕获中断异常后随手Thread.currentThread().interrupt()重新置位让上层能看到中断请求。7.4 任务耗时异常时要先排查业务代码而不是调参数线程池调优有一个很容易犯的方向性错误任务变慢时就调大线程数。实际上任务变慢更大概率是下游服务变慢、数据库出现慢查询、锁竞争加剧等原因。调大线程数只是放大了对这些慢资源的压力让问题更严重。正确的做法是先用 profiling 定位慢的根因等任务耗时恢复正常后再回头看线程池水位。我见过一个最典型的反面案例某服务依赖的外部接口 RT 从 200ms 涨到 2s开发把线程池从 20 调到 100结果这 100 个线程全部卡在外部调用上外部系统被打得更慢最终两边一起雪崩。如果先把下游的慢调用找出来降级或熔断线程池根本不需要调整。8. 写在最后的几个小原则Java 线程池是个学习曲线比较陡峭的组件参数之间的联动性很强网上很多文章要么只讲参数、要么只讲源码缺少生产环境到底怎么用这条线。写这篇内容时我尽力把原理、源码、监控、故障串起来希望能减少一些大家实际踩坑的成本。个人体会最深的三件事第一线程池参数没有标准答案任何公式和配置都要基于你自己的业务场景、吞吐目标和下游容量去验证。网上抄一份配置到生产是不负责任的做法必须经过压测和监控数据验证。第二无界队列是生产红线默认拒绝策略是隐雷自定义线程名是成本最低的保命手段。这三条是硬性约束回看所有线程池事故几乎都跟这三条有关。第三监控和动态调参比精妙的参数计算更重要。你永远无法预测线上真实的流量形态能做的就是让线程池的行为可观测、可调整、可恢复。每次线上事故后我都会把线程池的指标翻出来复盘问自己三个问题为什么当时没有预警告警如果在过载前一步就通过动态调参扩容是不是可以完全规避这个经验能不能沉淀成自动化的容量评估规则线程池只是工具真正重要的是你对自己系统的理解深度。配置可以抄经验不能抄希望对看到这里的你有帮助。
![Puppeteer 中 Realm 的资源释放机制：深入解析 [disposeSymbol]() 方法](http://pic.xiahunao.cn/yaotu/Puppeteer 中 Realm 的资源释放机制：深入解析 [disposeSymbol]() 方法)
