聊到Java并发编程线程池是绕不开的话题。无论是面试里被反复追问的“七大参数”还是生产环境里动不动就出现的任务堆积、线程数飙升、服务超时我估计每个Java开发者都跟它打过不少照面。我自己这几年调过不少线上问题最后发现大部分线程池“疑难杂症”并不是什么高深原理导致的而是对线程池的工作机制理解不够透彻或者配置的时候压根没想过业务场景。这篇内容我就从入门到生产把线程池的核心机制、队列选型、拒绝策略、常见配置以及那些真正会让服务出问题的坑一次性讲透。这篇内容适合谁刚接触Java并发的同学可以用来建立完整的认知框架已经写过几年代码、遇到过线上线程池问题但还没系统梳理过的朋友可以对照自查准备Java面试的人直接把这篇文章里的“为什么”吃透比背八股文有用得多。1. 线程池核心参数与底层工作机制1.1 七大参数逐字拆解ThreadPoolExecutor是Java线程池的核心实现类它也是唯一一个能让你完全掌控线程池行为的入口。前面那些Executors.newFixedThreadPool()、newCachedThreadPool()之类的工具方法本质都是对ThreadPoolExecutor的预配置封装但正因为是预配置很容易在不合适的场景下踩坑后面会专门说。先看完整的构造函数public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)七个参数一个一个说清楚corePoolSize核心线程数线程池长期维持的线程数量就算这些线程空闲也不会被回收除非设置了allowCoreThreadTimeOut(true)。核心线程数不是越多越好它是线程池稳定性的基石。maximumPoolSize最大线程数当任务队列满了之后线程池最多能扩展到多少个线程。扩展出来的这部分线程叫“非核心线程”它们有空闲回收机制。keepAliveTime空闲存活时间非核心线程空闲多久之后被回收。如果设置了allowCoreThreadTimeOut(true)核心线程也会受这个参数影响。unit时间单位keepAliveTime的时间单位常用TimeUnit.SECONDS、TimeUnit.MILLISECONDS。workQueue任务队列/阻塞队列当核心线程都在忙时新任务会进入这个队列排队等待。这是线程池性能的“调节器”后面的章节会重点展开。threadFactory线程工厂用来创建线程的工厂接口最重要的作用是给线程池里的线程命名、设置优先级、设置daemon属性。生产环境里线程名称乱七八糟排查问题的时候直接两眼一抹黑所以自定义ThreadFactory是生产标配。handler拒绝策略当任务队列满了、线程数也达到maximumPoolSize时再提交新任务会触发拒绝策略。JDK自带四种实现后面单独展开。这里有一个非常关键但很多人搞错的点线程池并不是“任务来了就先创建线程到corePoolSize同时把任务往队列里塞”这么简单。它的提交逻辑是这样的当提交一个任务时如果当前线程数小于corePoolSize则直接新建核心线程执行任务即使有空闲核心线程也会新建因为它优先保证核心线程数达到配置值如果当前线程数已经达到corePoolSize则任务会被放入队列等待如果队列已经满了才会创建非核心线程去执行如果线程数已经达到maximumPoolSize且队列也满了才会触发拒绝策略。这个顺序是理解线程池行为的关键。很多线上事故的根源其实就是对这个流程理解不到位。比如核心线程数配了10队列用了无界队列那么maximumPoolSize和拒绝策略就形同虚设因为任务永远在排队线程数永远保持在10。1.2 线程池状态机与任务提交全流程线程池内部有一个ctl变量用一个int的高3位保存线程池运行状态低29位保存线程数这是JDK为了做原子操作省掉锁的经典设计。线程池状态包括RUNNING接受新任务处理队列中的任务。SHUTDOWN调用shutdown()后进入不再接受新任务但会继续处理队列中已存在的任务。STOP调用shutdownNow()后进入不接新任务不处理队列任务还会中断正在执行的任务。TIDYING所有任务终止线程数为0进入该状态后执行terminated()钩子方法。TERMINATEDterminated()方法执行完成后的终态。这个状态流转实际上决定了你在调用shutdown()和shutdownNow()之后哪些任务会被执行、哪些会被丢弃。举个例子我见过有同学在服务优雅停机时调用shutdownNow()结果把正在跑的任务全打断了甚至导致数据写了一半就停了。正确的做法一般是shutdown()之后等待一段时间超时再shutdownNow()兜底。任务提交的完整流程可以这样理解先用execute()方法提交一个Runnable然后线程池内部走一遍上述的判断逻辑。注意submit()方法适合需要拿到返回结果的场景它内部最终还是调用execute()区别在于submit()会把任务包装成FutureTask同时异常会被吞进Future里获取结果时才抛出来。这个差异在异常排查时容易踩坑后面也会再提。2. 阻塞队列选择线程池性能的调节器2.1 四种常用队列的对比阻塞队列workQueue是线程池中最容易被忽略、却最能影响性能的参数。JDK里常用的队列有四种我直接做成表格对比队列类型是否有界特点典型场景ArrayBlockingQueue数组结构有界固定容量需要指定队列大小公平性可配置对队列长度有严格要求的场景LinkedBlockingQueue链表结构默认无界也可指定容量Executors.newFixedThreadPool默认使用无界的它吞吐量通常高于数组队列任务相对独立不追求极端容量控制SynchronousQueue无存储空间不存储任务每次提交任务必须有一个线程立刻接手没有等待队列Executors.newCachedThreadPool默认使用适合任务执行时间短、数量大且不希望排队等待的场景PriorityBlockingQueue二叉堆结构无界任务按优先级排序需要实现Comparable或传入Comparator需要任务分级处理的场景如VIP订单优先生效2.2 生产环境下队列选择的底层逻辑先泼一盆冷水无界队列配上maximumPoolSize和拒绝策略基本就是自欺欺人。因为任务永远进队列排队线程池永远不需要扩容到maximumPoolSize拒绝策略也永远不会触发。当任务产生速度长期大于消费速度时无界队列会无限增长内存被逐渐吃满GC压力陡增最后服务OOM。所以生产环境里队列必须有界而且要给出明确的兜底方案。SynchronousQueue比较特殊它不存储任务每个提交操作必须等待一个线程来接手。这个队列的核心价值是“高吞吐、低延迟”场景因为任务不会在内存里积累线程直接执行。但它要求线程池有非常灵活的扩缩容能力所以Executors.newCachedThreadPool才和它配合——核心线程数0最大线程数非常大空闲线程60秒回收。但如果突发流量过大SynchronousQueue会迫使线程数飙升到极大值可能导致线程创建频繁、上下文切换开销爆炸同样会拖垮服务。选队列的时候还要考虑一种情况队列长度、线程数、拒绝策略这三个要素是一个整体不能单独拍脑袋决定。比如你要设计一个处理速度峰值为1000 QPS、平均处理时长50ms的接口队列长度就要反推1000 * 0.05 50也就是每秒累积的任务大概50个队列至少要能缓冲几秒的任务量。但这里有个更优的思路与其依赖队列缓冲不如把队列设得小一点让线程池更早扩容、更早触发拒绝然后用拒绝策略做流量控制和降级这样系统的响应会更好而不是任务都在队列里堵着。经验之谈常规微服务场景队列容量建议在“每秒任务量 * 可接受排队秒数”附近。如果任务间有依赖关系比如一个任务要等另一个任务的结果那千万别用无界队列否则会死锁——消费者线程全被占满等着结果队列里的生产者任务永远得不到执行这就是经典的“线程池饥饿”。3. 拒绝策略系统最后的防洪堤3.1 JDK内置四种拒绝策略当线程池无法接收新任务时队列满、线程数达到最大值提交的任务会交给RejectedExecutionHandler处理。JDK提供四种AbortPolicy默认直接抛出RejectedExecutionException。这种方式最“硬”但它会把异常抛给提交任务的调用方如果调用方没做好捕获可能导致业务中断。适合允许接受失败、调用方有兜底的场景。CallerRunsPolicy不用线程池的线程而是由调用方线程自己执行这个任务。这个策略很有价值它不会丢任务同时能起到天然限流的效果——提交任务的线程被占用了自然没法继续狂提任务。但它的问题也很明显如果调用方是同步接口会在处理线程上累积阻塞增加接口延迟。DiscardPolicy静默丢弃任务不抛异常不处理。这个策略风险极大任务丢了业务方还完全不知道。我基本不推荐直接用。DiscardOldestPolicy丢弃队列里最老的未处理任务然后重新提交当前任务。适合“新任务比旧任务更有价值”的场景比如实时数据场景里过期的统计任务确实可以直接丢掉。3.2 自定义拒绝策略的工程实践生产环境里最常用的是自定义策略核心原则是失败信息必须可见失败动作必须可控。我一般这样写RejectedExecutionHandler handler (r, executor) - { // 1. 记录拒绝的任务和当前线程池状态 log.error(Task rejected, queueSize{}, activeCount{}, task{}, executor.getQueue().size(), executor.getActiveCount(), r.toString()); // 2. 告警上报如接入公司监控平台 monitor.report(threadpool.reject.count, 1); // 3. 降级兜底重试一次或写入本地文件/消息队列稍后处理 // 注意不要无限重试否则可能引发雪崩 if (retryCount.incrementAndGet() 3) { retryExecutor.schedule(r, 1, TimeUnit.SECONDS); } };拒绝策略的本质是流量控制的最后一道闸门。生产环境里触发拒绝不一定等于系统要挂了反而是线程池在“自救”。真正危险的是拒绝策略把任务静默丢弃业务侧完全感知不到最后对账才发现数据对不上。所以自定义拒绝策略里日志和监控必须到位。再补一句很多人问“触发拒绝后任务丢了怎么办”这里的关键是任务本身的可靠性要求。如果任务必须100%不丢那在线程池之前就要有可靠的持久化层比如消息队列、任务表线程池的拒绝策略只负责“尽量处理”底层可靠性得靠上层的持久化机制兜底。4. 线程池使用中的高频坑每个我都踩过4.1 坑一线程池没有给线程命名排查问题全靠猜不自定义ThreadFactory的后果是线程名长这样pool-1-thread-1、pool-2-thread-3。线上出了问题你打印线程栈jstack一看全是这种名字根本分不清是哪个业务线程池。尤其是服务里有几十个线程池的时候排查问题就是在泥坑里找针。解决方案很简单用自定义ThreadFactoryThreadFactory factory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r); t.setName(order-async-handler- counter.getAndIncrement()); t.setDaemon(false); // 可根据需要设置优先级默认即可 return t; } };有了明确前缀的线程名jstack一把下来哪个线程池堵了、哪些线程在空转一眼就能扫出来。这个习惯应该从第一天写线程池代码就养成别等项目出了问题再补。4.2 坑二线程池里的异常被“吞”了一切静悄悄这个坑有两种情况。第一种是用execute()提交任务任务内部抛了RuntimeException线程池会捕获异常并终结当前线程然后创建一个新线程异常堆栈可能只打到某个日志文件里甚至被丢掉取决于Thread.UncaughtExceptionHandler你压根不知道任务没执行成功。第二种是用submit()提交任务任务内部抛异常会被FutureTask吞掉调用Future.get()时才会抛出。如果你提交了任务但从来不调用get()那异常就永远沉默。我见过同学用submit()提交一批批量处理任务最后既不get()也不检查状态任务挂了几天没人发现。解决思路很明确任务内部必须自己捕获异常做好失败记录和告警不能指望线程池帮你处理。提交任务时如果用submit()务必通过Future拿到结果并检查或者干脆在任务代码里包一层try-catch兜底。可以使用Thread.setDefaultUncaughtExceptionHandler兜底异常但这是最后防线不能当主力。4.3 坑三ThreadLocal与线程池的“借尸还魂”普通线程和线程池最大的区别就是线程池里的线程是复用的大池子。直接用ThreadLocalA任务往ThreadLocal里存了数据线程处理完A之后回到线程池下一次被分配到B任务时B任务直接从ThreadLocal里取到了A留下的脏数据。这个坑在业务上非常危险。比如你用ThreadLocal做了用户身份传递、TraceId透传一旦线程池复用线程就会出现A用户登录态被B用户看到的严重事故。生产环境解决办法是在线程池执行每个任务前后显式清除和初始化ThreadLocal。推荐重写Runnable包一层“清理执行”逻辑或者使用阿里开源的TransmittableThreadLocal做上下文透传。无论用哪种核心原则是线程池任务的上下文必须由任务自己管理不能依赖“上一次任务残留的状态”。4.4 坑四线程数配置凭感觉CPU上下文切换爆炸线程数设得太小而队列太长任务积压延迟急剧上升线程数设得太大而任务又是CPU密集型线程频繁切换上下文整体吞吐反而下降。这两个极端我都见过。CPU密集型任务的线程数理论上接近CPU核数1即可IO密集型任务因为有大量等待时间线程数可以高一些。公式可以这样估算// CPU密集型 corePoolSize CPU核数 maximumPoolSize CPU核数 1 // 防止偶发的页缺失等原因导致CPU空闲 // IO密集型 // 理论值 CPU核数 * (1 平均等待时间 / 平均计算时间) // 一般可以用 CPU核数 * 2 作为起点再压测调整但说实话公式只是起点。真正的线程数需要结合压测结果、目标延迟和资源预算来调。我倾向于“宁可错杀不可放过”的反向思路先按公式给个保守值再在压测中逐步调大观察吞吐量和延迟的拐点。另外所有线程池参数应该做成可动态配置的配合监控平台运行时调整能省掉很多发版重启的麻烦。5. 生产环境的线程池配置方案与监控设计5.1 三大常见业务场景的参考配置下面直接给三组可抄作业的配置但请务必根据你的实际压测结果微调场景A高并发短任务如异步通知、消息推送ThreadPoolExecutor executor new ThreadPoolExecutor( 8, // 核心线程数按机器CPU核数的1~2倍 16, // 最大线程数留出一定的弹性 30L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), // 有界队列避免无限堆积 new NamedThreadFactory(notify-push), new CallerRunsPolicy() // 让调用方线程执行天然限流 );场景B耗时IO任务如文件处理、远程调用批量任务ThreadPoolExecutor executor new ThreadPoolExecutor( Runtime.getRuntime().availableProcessors() * 2, // IO密集型可以多配线程 Runtime.getRuntime().availableProcessors() * 4, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(500), // 容量比短任务场景稍大 new NamedThreadFactory(io-heavy-worker), new AbortPolicy() // 明确失败让上层感知 );场景C定时批量任务如每天跑报表、清算任务这类任务的特点是一次性提交大量数据且任务间相互独立。建议配置一个独立的线程池核心线程数不超过CPU核数队列使用有界队列拒绝策略直接使用DiscardOldestPolicy因为旧的未处理报表任务没有追赶价值及时丢弃更合理。5.2 线程池参数动态化生产环境调整配置的关键能力线程池的参数如果写死在代码里哪天线上出问题想调一下必须发版重启这个过程本身就有可能加重故障。我强烈建议把核心参数放到配置中心如Apollo、Nacos上通过配置动态修改corePoolSize、maximumPoolSize、queueCapacity等。ThreadPoolExecutor的setCorePoolSize、setMaximumPoolSize是线程安全的可以直接在运行期调用。但队列容量不能直接动态修改ArrayBlockingQueue的容量是final的。常见的做法有两种一种是用可变容量的队列包装类如DynamicResizeBlockingQueue另一种是干脆改用到支持setCapacity的定制队列。这块如果不方便改造退而求其次的方案是动态调整核心线程数和最大线程数就先能解决大半问题因为队列容量不变的话通过放大maximumPoolSize可以让非核心线程更早接走队列里的任务相当于变相减少了队列排队时间。5.3 监控指标与告警设计线程池的运行状态是黑盒如果不监控就是裸奔。我建议至少监控这四个核心指标活跃线程数activeCount持续接近maximumPoolSize说明线程吃紧。队列积压量queue.size持续增长说明消费速度跟不上生产速度。任务拒绝数rejectedCount只要不为0就必须立即告警。线程池任务执行耗时分布需要用AOP或任务包装器统计找出慢任务。用ScheduledExecutorService每10秒采样一次把指标推到监控平台配上告警阈值。我这里给一个简单例子ScheduledExecutorService monitor Executors.newSingleThreadScheduledExecutor(); monitor.scheduleAtFixedRate(() - { int active executor.getActiveCount(); int queueSize executor.getQueue().size(); long completed executor.getCompletedTaskCount(); if (queueSize 200) { monitor.report(order-threadpool.queue-depth, queueSize); } if (executor.getRejectedExecutionHandler() instanceof AbortPolicy) { // 记录拒绝次数通常需要自己在handler里做计数 monitor.report(order-threadpool.reject-count, rejectCounter.get()); } }, 0, 10, TimeUnit.SECONDS);监控的意义在于尽早发现趋势而不是等问题爆发后去救火。队列积压量从50涨到200可能只需要几秒但这几秒就是你能不能提前介入的关键窗口期。5.4 线程池关闭的正确姿势很多人只关心创建和执行忽略了关闭。如果线程池不关闭里面的线程会一直活着JVM无法正常退出如果过度关闭又会打断正在运行的任务。生产环境的标准做法是两步走// 第一步优雅关闭不再接受新任务等待已有任务完成 executor.shutdown(); // 第二步等待一定时间超时则强制关闭并记录未完成任务 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { ListRunnable unfinished executor.shutdownNow(); log.warn(ThreadPool forced shutdown, unfinished tasks: {}, unfinished.size()); }这个方法在微服务发布上下线时尤其重要。优雅停机要做到“让在途请求处理完不丢数据”强杀场景再配合重试机制补数据。6. 一个真实故障的完整排查实录6.1 故障现象与初步定位先说一个我印象很深的线上故障。当时有个订单处理服务平时表现很稳定某天突然接口P95延迟从200ms飙到5秒CPU也居高不下紧接着开始有消息积压告警。我第一反应就是查线程池因为这种“突然变慢CPU高”的组合通常跟线程池状态强相关。拿到jstack后果然发现问题大量线程处于WAITING状态阻塞在LinkedBlockingQueue.take()上而RUNNABLE状态的线程非常少。翻译过来就是所有工作线程都在空等队列里的任务队列里却没有任务可做与此同时整体链路却在超时。这是典型的“线程饥饿”伴生现象。6.2 根因分析继续深挖发现这个线程池被同一个业务拿来执行两类任务一类是CPU密集的订单解析一类是IO密集的远程调账。CPU密集任务占满了所有核心线程后IO密集任务排队等待而远程调账的响应时间又取决于订单解析是否完成形成了死锁式的相互等待。再加上这个线程池的队列用了无界队列maximumPoolSize设了跟没设一样队列里不断堆积内存也跟着涨。根本原因一句话一个线程池被塞进了多个互相不兼容的业务且队列配置错误放大了问题。线程池不是垃圾回收站什么任务都往里扔一定要按业务拆分。不同任务的生命周期、执行时长、对失败的态度完全不同混在一起必然互相拖累。6.3 修复方案先拆分线程池让CPU密集任务和IO密集任务各自独立。然后所有队列改为有界队列拒绝策略统一用“记录告警降级兜底”同时给所有线程加上业务前缀命名。最后在监控里补上了拒绝计数和队列积压量的告警。拆完之后接口P95恢复到了原来的200ms量级问题再没复现过。这次故障让我养成了两个习惯第一任何线程池配置都必须写明“适用业务、容量计算依据、拒绝后的兜底方案”没有文档的线程池代码不合法第二线上问题排查第一步永远是jstack线程池指标而不是去看业务日志先确认线程池状态再顺藤摸瓜找业务问题。6.4 常用排查工具速查表工具/命令用途核心看点jstack pid打印Java进程线程栈WAITING、BLOCKED状态线程占比线程名前缀jstat -gcutil pid查看GC情况FGC次数、GC耗时排除GC导致的卡顿top -H -p pid查看进程内线程CPU占用定位CPU飙升的线程ID再换算成16进制去jstack里找Arthasthread实时查看线程栈、CPU占用thread -n 3看最忙的3个线程thread -b找死锁监控平台线程池指标曲线队列积压量、活跃线程数、拒绝次数随时间的变化趋势现场排查的时候我通常会先看监控曲线确认故障发生的时间点和线程池指标的拐点是否吻合然后再去jstack抓现场。抓住“时间点吻合”这个关键线索定位效率会高很多。7. 最后的一些个人经验线程池这个东西原理并不复杂但真正用好它需要大量的实践和对业务的理解。我个人最大的体会是千万别把线程池当“万能加速器”它不是越大的线程数越好也不是越长的队列越安全。每一次配置都应该能回答出“为什么是这个值”和“如果流量翻三倍会发生什么”这两个问题。另一个很推荐的做法是花点时间把线程池的监控做扎实。线程池的状态曲线非常诚实它不会骗人——队列在涨就是消费跟不上活跃线程数抬高就是任务变重或变多拒绝次数出现就是容量到了极限。有了这些数据你才能在做容量规划、性能调优的时候心里有底。最后再分享一个小技巧写线程池代码的时候顺手把executor.toString()打一句日志。ThreadPoolExecutor重写了toString()里面包含了核心线程数、活跃线程数、队列大小、任务计数等关键信息。这会让你在问题复现时多一个非常便宜的观测手段少一次线上救火的损失。 
长河君 · 2026/10/6 13:49:02 · 阅读 1.2k Java线程池从入门到生产：核心机制、队列选型与避坑指南
聊到Java并发编程线程池是绕不开的话题。无论是面试里被反复追问的“七大参数”还是生产环境里动不动就出现的任务堆积、线程数飙升、服务超时我估计每个Java开发者都跟它打过不少照面。我自己这几年调过不少线上问题最后发现大部分线程池“疑难杂症”并不是什么高深原理导致的而是对线程池的工作机制理解不够透彻或者配置的时候压根没想过业务场景。这篇内容我就从入门到生产把线程池的核心机制、队列选型、拒绝策略、常见配置以及那些真正会让服务出问题的坑一次性讲透。这篇内容适合谁刚接触Java并发的同学可以用来建立完整的认知框架已经写过几年代码、遇到过线上线程池问题但还没系统梳理过的朋友可以对照自查准备Java面试的人直接把这篇文章里的“为什么”吃透比背八股文有用得多。1. 线程池核心参数与底层工作机制1.1 七大参数逐字拆解ThreadPoolExecutor是Java线程池的核心实现类它也是唯一一个能让你完全掌控线程池行为的入口。前面那些Executors.newFixedThreadPool()、newCachedThreadPool()之类的工具方法本质都是对ThreadPoolExecutor的预配置封装但正因为是预配置很容易在不合适的场景下踩坑后面会专门说。先看完整的构造函数public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)七个参数一个一个说清楚corePoolSize核心线程数线程池长期维持的线程数量就算这些线程空闲也不会被回收除非设置了allowCoreThreadTimeOut(true)。核心线程数不是越多越好它是线程池稳定性的基石。maximumPoolSize最大线程数当任务队列满了之后线程池最多能扩展到多少个线程。扩展出来的这部分线程叫“非核心线程”它们有空闲回收机制。keepAliveTime空闲存活时间非核心线程空闲多久之后被回收。如果设置了allowCoreThreadTimeOut(true)核心线程也会受这个参数影响。unit时间单位keepAliveTime的时间单位常用TimeUnit.SECONDS、TimeUnit.MILLISECONDS。workQueue任务队列/阻塞队列当核心线程都在忙时新任务会进入这个队列排队等待。这是线程池性能的“调节器”后面的章节会重点展开。threadFactory线程工厂用来创建线程的工厂接口最重要的作用是给线程池里的线程命名、设置优先级、设置daemon属性。生产环境里线程名称乱七八糟排查问题的时候直接两眼一抹黑所以自定义ThreadFactory是生产标配。handler拒绝策略当任务队列满了、线程数也达到maximumPoolSize时再提交新任务会触发拒绝策略。JDK自带四种实现后面单独展开。这里有一个非常关键但很多人搞错的点线程池并不是“任务来了就先创建线程到corePoolSize同时把任务往队列里塞”这么简单。它的提交逻辑是这样的当提交一个任务时如果当前线程数小于corePoolSize则直接新建核心线程执行任务即使有空闲核心线程也会新建因为它优先保证核心线程数达到配置值如果当前线程数已经达到corePoolSize则任务会被放入队列等待如果队列已经满了才会创建非核心线程去执行如果线程数已经达到maximumPoolSize且队列也满了才会触发拒绝策略。这个顺序是理解线程池行为的关键。很多线上事故的根源其实就是对这个流程理解不到位。比如核心线程数配了10队列用了无界队列那么maximumPoolSize和拒绝策略就形同虚设因为任务永远在排队线程数永远保持在10。1.2 线程池状态机与任务提交全流程线程池内部有一个ctl变量用一个int的高3位保存线程池运行状态低29位保存线程数这是JDK为了做原子操作省掉锁的经典设计。线程池状态包括RUNNING接受新任务处理队列中的任务。SHUTDOWN调用shutdown()后进入不再接受新任务但会继续处理队列中已存在的任务。STOP调用shutdownNow()后进入不接新任务不处理队列任务还会中断正在执行的任务。TIDYING所有任务终止线程数为0进入该状态后执行terminated()钩子方法。TERMINATEDterminated()方法执行完成后的终态。这个状态流转实际上决定了你在调用shutdown()和shutdownNow()之后哪些任务会被执行、哪些会被丢弃。举个例子我见过有同学在服务优雅停机时调用shutdownNow()结果把正在跑的任务全打断了甚至导致数据写了一半就停了。正确的做法一般是shutdown()之后等待一段时间超时再shutdownNow()兜底。任务提交的完整流程可以这样理解先用execute()方法提交一个Runnable然后线程池内部走一遍上述的判断逻辑。注意submit()方法适合需要拿到返回结果的场景它内部最终还是调用execute()区别在于submit()会把任务包装成FutureTask同时异常会被吞进Future里获取结果时才抛出来。这个差异在异常排查时容易踩坑后面也会再提。2. 阻塞队列选择线程池性能的调节器2.1 四种常用队列的对比阻塞队列workQueue是线程池中最容易被忽略、却最能影响性能的参数。JDK里常用的队列有四种我直接做成表格对比队列类型是否有界特点典型场景ArrayBlockingQueue数组结构有界固定容量需要指定队列大小公平性可配置对队列长度有严格要求的场景LinkedBlockingQueue链表结构默认无界也可指定容量Executors.newFixedThreadPool默认使用无界的它吞吐量通常高于数组队列任务相对独立不追求极端容量控制SynchronousQueue无存储空间不存储任务每次提交任务必须有一个线程立刻接手没有等待队列Executors.newCachedThreadPool默认使用适合任务执行时间短、数量大且不希望排队等待的场景PriorityBlockingQueue二叉堆结构无界任务按优先级排序需要实现Comparable或传入Comparator需要任务分级处理的场景如VIP订单优先生效2.2 生产环境下队列选择的底层逻辑先泼一盆冷水无界队列配上maximumPoolSize和拒绝策略基本就是自欺欺人。因为任务永远进队列排队线程池永远不需要扩容到maximumPoolSize拒绝策略也永远不会触发。当任务产生速度长期大于消费速度时无界队列会无限增长内存被逐渐吃满GC压力陡增最后服务OOM。所以生产环境里队列必须有界而且要给出明确的兜底方案。SynchronousQueue比较特殊它不存储任务每个提交操作必须等待一个线程来接手。这个队列的核心价值是“高吞吐、低延迟”场景因为任务不会在内存里积累线程直接执行。但它要求线程池有非常灵活的扩缩容能力所以Executors.newCachedThreadPool才和它配合——核心线程数0最大线程数非常大空闲线程60秒回收。但如果突发流量过大SynchronousQueue会迫使线程数飙升到极大值可能导致线程创建频繁、上下文切换开销爆炸同样会拖垮服务。选队列的时候还要考虑一种情况队列长度、线程数、拒绝策略这三个要素是一个整体不能单独拍脑袋决定。比如你要设计一个处理速度峰值为1000 QPS、平均处理时长50ms的接口队列长度就要反推1000 * 0.05 50也就是每秒累积的任务大概50个队列至少要能缓冲几秒的任务量。但这里有个更优的思路与其依赖队列缓冲不如把队列设得小一点让线程池更早扩容、更早触发拒绝然后用拒绝策略做流量控制和降级这样系统的响应会更好而不是任务都在队列里堵着。经验之谈常规微服务场景队列容量建议在“每秒任务量 * 可接受排队秒数”附近。如果任务间有依赖关系比如一个任务要等另一个任务的结果那千万别用无界队列否则会死锁——消费者线程全被占满等着结果队列里的生产者任务永远得不到执行这就是经典的“线程池饥饿”。3. 拒绝策略系统最后的防洪堤3.1 JDK内置四种拒绝策略当线程池无法接收新任务时队列满、线程数达到最大值提交的任务会交给RejectedExecutionHandler处理。JDK提供四种AbortPolicy默认直接抛出RejectedExecutionException。这种方式最“硬”但它会把异常抛给提交任务的调用方如果调用方没做好捕获可能导致业务中断。适合允许接受失败、调用方有兜底的场景。CallerRunsPolicy不用线程池的线程而是由调用方线程自己执行这个任务。这个策略很有价值它不会丢任务同时能起到天然限流的效果——提交任务的线程被占用了自然没法继续狂提任务。但它的问题也很明显如果调用方是同步接口会在处理线程上累积阻塞增加接口延迟。DiscardPolicy静默丢弃任务不抛异常不处理。这个策略风险极大任务丢了业务方还完全不知道。我基本不推荐直接用。DiscardOldestPolicy丢弃队列里最老的未处理任务然后重新提交当前任务。适合“新任务比旧任务更有价值”的场景比如实时数据场景里过期的统计任务确实可以直接丢掉。3.2 自定义拒绝策略的工程实践生产环境里最常用的是自定义策略核心原则是失败信息必须可见失败动作必须可控。我一般这样写RejectedExecutionHandler handler (r, executor) - { // 1. 记录拒绝的任务和当前线程池状态 log.error(Task rejected, queueSize{}, activeCount{}, task{}, executor.getQueue().size(), executor.getActiveCount(), r.toString()); // 2. 告警上报如接入公司监控平台 monitor.report(threadpool.reject.count, 1); // 3. 降级兜底重试一次或写入本地文件/消息队列稍后处理 // 注意不要无限重试否则可能引发雪崩 if (retryCount.incrementAndGet() 3) { retryExecutor.schedule(r, 1, TimeUnit.SECONDS); } };拒绝策略的本质是流量控制的最后一道闸门。生产环境里触发拒绝不一定等于系统要挂了反而是线程池在“自救”。真正危险的是拒绝策略把任务静默丢弃业务侧完全感知不到最后对账才发现数据对不上。所以自定义拒绝策略里日志和监控必须到位。再补一句很多人问“触发拒绝后任务丢了怎么办”这里的关键是任务本身的可靠性要求。如果任务必须100%不丢那在线程池之前就要有可靠的持久化层比如消息队列、任务表线程池的拒绝策略只负责“尽量处理”底层可靠性得靠上层的持久化机制兜底。4. 线程池使用中的高频坑每个我都踩过4.1 坑一线程池没有给线程命名排查问题全靠猜不自定义ThreadFactory的后果是线程名长这样pool-1-thread-1、pool-2-thread-3。线上出了问题你打印线程栈jstack一看全是这种名字根本分不清是哪个业务线程池。尤其是服务里有几十个线程池的时候排查问题就是在泥坑里找针。解决方案很简单用自定义ThreadFactoryThreadFactory factory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r); t.setName(order-async-handler- counter.getAndIncrement()); t.setDaemon(false); // 可根据需要设置优先级默认即可 return t; } };有了明确前缀的线程名jstack一把下来哪个线程池堵了、哪些线程在空转一眼就能扫出来。这个习惯应该从第一天写线程池代码就养成别等项目出了问题再补。4.2 坑二线程池里的异常被“吞”了一切静悄悄这个坑有两种情况。第一种是用execute()提交任务任务内部抛了RuntimeException线程池会捕获异常并终结当前线程然后创建一个新线程异常堆栈可能只打到某个日志文件里甚至被丢掉取决于Thread.UncaughtExceptionHandler你压根不知道任务没执行成功。第二种是用submit()提交任务任务内部抛异常会被FutureTask吞掉调用Future.get()时才会抛出。如果你提交了任务但从来不调用get()那异常就永远沉默。我见过同学用submit()提交一批批量处理任务最后既不get()也不检查状态任务挂了几天没人发现。解决思路很明确任务内部必须自己捕获异常做好失败记录和告警不能指望线程池帮你处理。提交任务时如果用submit()务必通过Future拿到结果并检查或者干脆在任务代码里包一层try-catch兜底。可以使用Thread.setDefaultUncaughtExceptionHandler兜底异常但这是最后防线不能当主力。4.3 坑三ThreadLocal与线程池的“借尸还魂”普通线程和线程池最大的区别就是线程池里的线程是复用的大池子。直接用ThreadLocalA任务往ThreadLocal里存了数据线程处理完A之后回到线程池下一次被分配到B任务时B任务直接从ThreadLocal里取到了A留下的脏数据。这个坑在业务上非常危险。比如你用ThreadLocal做了用户身份传递、TraceId透传一旦线程池复用线程就会出现A用户登录态被B用户看到的严重事故。生产环境解决办法是在线程池执行每个任务前后显式清除和初始化ThreadLocal。推荐重写Runnable包一层“清理执行”逻辑或者使用阿里开源的TransmittableThreadLocal做上下文透传。无论用哪种核心原则是线程池任务的上下文必须由任务自己管理不能依赖“上一次任务残留的状态”。4.4 坑四线程数配置凭感觉CPU上下文切换爆炸线程数设得太小而队列太长任务积压延迟急剧上升线程数设得太大而任务又是CPU密集型线程频繁切换上下文整体吞吐反而下降。这两个极端我都见过。CPU密集型任务的线程数理论上接近CPU核数1即可IO密集型任务因为有大量等待时间线程数可以高一些。公式可以这样估算// CPU密集型 corePoolSize CPU核数 maximumPoolSize CPU核数 1 // 防止偶发的页缺失等原因导致CPU空闲 // IO密集型 // 理论值 CPU核数 * (1 平均等待时间 / 平均计算时间) // 一般可以用 CPU核数 * 2 作为起点再压测调整但说实话公式只是起点。真正的线程数需要结合压测结果、目标延迟和资源预算来调。我倾向于“宁可错杀不可放过”的反向思路先按公式给个保守值再在压测中逐步调大观察吞吐量和延迟的拐点。另外所有线程池参数应该做成可动态配置的配合监控平台运行时调整能省掉很多发版重启的麻烦。5. 生产环境的线程池配置方案与监控设计5.1 三大常见业务场景的参考配置下面直接给三组可抄作业的配置但请务必根据你的实际压测结果微调场景A高并发短任务如异步通知、消息推送ThreadPoolExecutor executor new ThreadPoolExecutor( 8, // 核心线程数按机器CPU核数的1~2倍 16, // 最大线程数留出一定的弹性 30L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), // 有界队列避免无限堆积 new NamedThreadFactory(notify-push), new CallerRunsPolicy() // 让调用方线程执行天然限流 );场景B耗时IO任务如文件处理、远程调用批量任务ThreadPoolExecutor executor new ThreadPoolExecutor( Runtime.getRuntime().availableProcessors() * 2, // IO密集型可以多配线程 Runtime.getRuntime().availableProcessors() * 4, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(500), // 容量比短任务场景稍大 new NamedThreadFactory(io-heavy-worker), new AbortPolicy() // 明确失败让上层感知 );场景C定时批量任务如每天跑报表、清算任务这类任务的特点是一次性提交大量数据且任务间相互独立。建议配置一个独立的线程池核心线程数不超过CPU核数队列使用有界队列拒绝策略直接使用DiscardOldestPolicy因为旧的未处理报表任务没有追赶价值及时丢弃更合理。5.2 线程池参数动态化生产环境调整配置的关键能力线程池的参数如果写死在代码里哪天线上出问题想调一下必须发版重启这个过程本身就有可能加重故障。我强烈建议把核心参数放到配置中心如Apollo、Nacos上通过配置动态修改corePoolSize、maximumPoolSize、queueCapacity等。ThreadPoolExecutor的setCorePoolSize、setMaximumPoolSize是线程安全的可以直接在运行期调用。但队列容量不能直接动态修改ArrayBlockingQueue的容量是final的。常见的做法有两种一种是用可变容量的队列包装类如DynamicResizeBlockingQueue另一种是干脆改用到支持setCapacity的定制队列。这块如果不方便改造退而求其次的方案是动态调整核心线程数和最大线程数就先能解决大半问题因为队列容量不变的话通过放大maximumPoolSize可以让非核心线程更早接走队列里的任务相当于变相减少了队列排队时间。5.3 监控指标与告警设计线程池的运行状态是黑盒如果不监控就是裸奔。我建议至少监控这四个核心指标活跃线程数activeCount持续接近maximumPoolSize说明线程吃紧。队列积压量queue.size持续增长说明消费速度跟不上生产速度。任务拒绝数rejectedCount只要不为0就必须立即告警。线程池任务执行耗时分布需要用AOP或任务包装器统计找出慢任务。用ScheduledExecutorService每10秒采样一次把指标推到监控平台配上告警阈值。我这里给一个简单例子ScheduledExecutorService monitor Executors.newSingleThreadScheduledExecutor(); monitor.scheduleAtFixedRate(() - { int active executor.getActiveCount(); int queueSize executor.getQueue().size(); long completed executor.getCompletedTaskCount(); if (queueSize 200) { monitor.report(order-threadpool.queue-depth, queueSize); } if (executor.getRejectedExecutionHandler() instanceof AbortPolicy) { // 记录拒绝次数通常需要自己在handler里做计数 monitor.report(order-threadpool.reject-count, rejectCounter.get()); } }, 0, 10, TimeUnit.SECONDS);监控的意义在于尽早发现趋势而不是等问题爆发后去救火。队列积压量从50涨到200可能只需要几秒但这几秒就是你能不能提前介入的关键窗口期。5.4 线程池关闭的正确姿势很多人只关心创建和执行忽略了关闭。如果线程池不关闭里面的线程会一直活着JVM无法正常退出如果过度关闭又会打断正在运行的任务。生产环境的标准做法是两步走// 第一步优雅关闭不再接受新任务等待已有任务完成 executor.shutdown(); // 第二步等待一定时间超时则强制关闭并记录未完成任务 if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { ListRunnable unfinished executor.shutdownNow(); log.warn(ThreadPool forced shutdown, unfinished tasks: {}, unfinished.size()); }这个方法在微服务发布上下线时尤其重要。优雅停机要做到“让在途请求处理完不丢数据”强杀场景再配合重试机制补数据。6. 一个真实故障的完整排查实录6.1 故障现象与初步定位先说一个我印象很深的线上故障。当时有个订单处理服务平时表现很稳定某天突然接口P95延迟从200ms飙到5秒CPU也居高不下紧接着开始有消息积压告警。我第一反应就是查线程池因为这种“突然变慢CPU高”的组合通常跟线程池状态强相关。拿到jstack后果然发现问题大量线程处于WAITING状态阻塞在LinkedBlockingQueue.take()上而RUNNABLE状态的线程非常少。翻译过来就是所有工作线程都在空等队列里的任务队列里却没有任务可做与此同时整体链路却在超时。这是典型的“线程饥饿”伴生现象。6.2 根因分析继续深挖发现这个线程池被同一个业务拿来执行两类任务一类是CPU密集的订单解析一类是IO密集的远程调账。CPU密集任务占满了所有核心线程后IO密集任务排队等待而远程调账的响应时间又取决于订单解析是否完成形成了死锁式的相互等待。再加上这个线程池的队列用了无界队列maximumPoolSize设了跟没设一样队列里不断堆积内存也跟着涨。根本原因一句话一个线程池被塞进了多个互相不兼容的业务且队列配置错误放大了问题。线程池不是垃圾回收站什么任务都往里扔一定要按业务拆分。不同任务的生命周期、执行时长、对失败的态度完全不同混在一起必然互相拖累。6.3 修复方案先拆分线程池让CPU密集任务和IO密集任务各自独立。然后所有队列改为有界队列拒绝策略统一用“记录告警降级兜底”同时给所有线程加上业务前缀命名。最后在监控里补上了拒绝计数和队列积压量的告警。拆完之后接口P95恢复到了原来的200ms量级问题再没复现过。这次故障让我养成了两个习惯第一任何线程池配置都必须写明“适用业务、容量计算依据、拒绝后的兜底方案”没有文档的线程池代码不合法第二线上问题排查第一步永远是jstack线程池指标而不是去看业务日志先确认线程池状态再顺藤摸瓜找业务问题。6.4 常用排查工具速查表工具/命令用途核心看点jstack pid打印Java进程线程栈WAITING、BLOCKED状态线程占比线程名前缀jstat -gcutil pid查看GC情况FGC次数、GC耗时排除GC导致的卡顿top -H -p pid查看进程内线程CPU占用定位CPU飙升的线程ID再换算成16进制去jstack里找Arthasthread实时查看线程栈、CPU占用thread -n 3看最忙的3个线程thread -b找死锁监控平台线程池指标曲线队列积压量、活跃线程数、拒绝次数随时间的变化趋势现场排查的时候我通常会先看监控曲线确认故障发生的时间点和线程池指标的拐点是否吻合然后再去jstack抓现场。抓住“时间点吻合”这个关键线索定位效率会高很多。7. 最后的一些个人经验线程池这个东西原理并不复杂但真正用好它需要大量的实践和对业务的理解。我个人最大的体会是千万别把线程池当“万能加速器”它不是越大的线程数越好也不是越长的队列越安全。每一次配置都应该能回答出“为什么是这个值”和“如果流量翻三倍会发生什么”这两个问题。另一个很推荐的做法是花点时间把线程池的监控做扎实。线程池的状态曲线非常诚实它不会骗人——队列在涨就是消费跟不上活跃线程数抬高就是任务变重或变多拒绝次数出现就是容量到了极限。有了这些数据你才能在做容量规划、性能调优的时候心里有底。最后再分享一个小技巧写线程池代码的时候顺手把executor.toString()打一句日志。ThreadPoolExecutor重写了toString()里面包含了核心线程数、活跃线程数、队列大小、任务计数等关键信息。这会让你在问题复现时多一个非常便宜的观测手段少一次线上救火的损失。