前言线程池队列从几十涨到几千通常不是“队列参数太小”而是任务进入速度已经超过完成速度。队列只是把差额暂时存了下来。很多处理方式会让问题变得更隐蔽把队列从1000改成10000告警暂时消失但排在后面的任务要等得更久把线程数从20加到200如果瓶颈在数据库结果往往是200个线程一起等连接。堆积没有消失只是换成了接口超时、连接池等待或堆内存上涨。排查线程池堆积时先回答三个问题任务为什么变慢提交量为什么变多当前处理能力能否让队列降下来。本文以Java的ThreadPoolExecutor为主说明如何定位原因、建立监控以及在生产环境中止损和治理。一、什么叫线程池队列堆积ThreadPoolExecutor接收任务时大致按下面的顺序处理提交任务│├─ 当前线程数 corePoolSize│ └─ 创建工作线程执行│├─ 否则尝试放入工作队列│ └─ 入队成功等待执行│├─ 队列已满并且当前线程数 maximumPoolSize│ └─ 创建非核心线程执行│└─ 线程数和队列都达到上限└─ 执行拒绝策略线程数达到核心线程数后新任务会优先入队。只有队列无法继续接收时线程数才会继续增长到maximumPoolSize。所以大队列配小核心线程数时最大线程数可能长期不生效。例如线程池每秒收到50个任务只能完成30个净增长是每秒20个。容量为1000的空队列大约50秒就会装满1000 ÷ (50 - 30) 50秒。也就是说到达速率 完成速率时就会产生堆积的情况换个生动的说法就是比如有一个池子池子有一个入水口一个出水口可以维持水流稳定。但是当入水口增加多个而出水口不变的时候就会使池子中的水不断增加甚至溢出。二、队列为什么会堆积1、短时流量突增定时任务集中触发、消息批量到达、上游补数据都会在短时间内让提交速率超过处理速率。突增结束后如果队列能在业务允许的时间内回落这属于队列原本要吸收的波动。2. 流入量长期超过设计容量业务增长后常态QPS已经超过线程池稳定吞吐量。此时每天都可能出现相同的曲线高峰期持续上涨低峰期缓慢回落最终连低峰期也清不完。3、数据库或远程接口变慢线程池任务常常把大部分时间花在等待获取数据库连接执行慢SQL或等待锁调用HTTP、RPC接口读取对象存储、文件或消息系统假设有20个工作线程单任务耗时原来是100ms理论完成速率约为每秒200个。下游变慢后单任务耗时升到1秒完成速率会降到每秒约20个。提交速率没有任何变化队列也会快速上涨。4、任务内部阻塞或死锁任务可能卡在没有超时的网络调用、锁竞争或无限等待上。5. 参数和队列类型不合适常见配置问题包括Executors.newFixedThreadPool()使用无界LinkedBlockingQueue过载时任务持续累积核心线程数很小、队列很大maximumPoolSize迟迟不能生效线程数超过数据库连接池或HTTP连接池容量大量线程只是换了一个位置等待队列容量只凭经验填写没有对应允许的排队时间6. 重试和任务放大一次请求可能拆成多个异步任务任务失败后又在当前线程池中立即重试。下游故障时原始流量、超时重试和补偿任务叠加提交速率反而比正常时期更高。三、队列堆积会造成什么后果1、排队时间过久导致流程超时有界队列只有装满后才触发拒绝但业务可能早已超时。假设20个线程处理单个耗时200ms的任务队列中已有1000个任务。忽略耗时波动排在尾部的任务大约要等待1000 ÷ 20 × 200ms 10秒2、堆内存和GC压力上升同样是10000个任务只保存订单ID与持有完整订单对象的内存占用可能相差几个数量级。积压严重时老年代占用和Full GC会增加最坏情况是OutOfMemoryError。3. 超时和重试形成反馈循环排队变长会让上游超时。上游如果立即重试新增请求又进入同一个线程池队列增长更快。原本只是某个下游变慢最后可能扩散为Web请求线程、连接池和JVM一起过载。四、监控不能只看queueSize指标作用观察重点queueSize当前排队任务数是否持续增长峰值后能否回落queueRemainingCapacity队列剩余容量只对有界队列有明确意义队列使用率已使用容量占比适合不同容量线程池统一展示activeCount正在执行任务的线程数是否长期接近当前或最大线程数poolSize、maximumPoolSize当前与最大线程数最大线程数是否真正生效提交速率单位时间收到多少任务是否突增是否出现重试放大完成速率单位时间完成多少任务是否低于提交速率任务排队时间从提交到开始执行的时间p95、p99是否超过业务预算任务执行时间从开始到结束的时间长尾是否突然上升最老任务等待时间当前积压里最老任务等了多久比单纯队列长度更接近用户感受拒绝次数线程和队列都饱和后的结果出现一次也应能追踪原因取消、失败和超时数任务最终结果防止“完成了但没成功”1、用Micrometer采集基础指标需要引入Micrometer Jar包import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Tags; import io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ExecutorService; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicInteger; public final class ExecutorConfig { public static ExecutorService orderExecutor(MeterRegistry registry) { AtomicInteger sequence new AtomicInteger(); ThreadPoolExecutor rawExecutor new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), task - new Thread( task, order-query- sequence.incrementAndGet() ), new ThreadPoolExecutor.AbortPolicy() ); return ExecutorServiceMetrics.monitor( registry, rawExecutor, order-query, Tags.empty() ); } }Micrometer可以包装ExecutorService记录线程池状态、任务执行时间和队列等待时间。对于ThreadPoolExecutorMicrometer提供的指标包括executor 任务执行时间executor.idle 任务开始前的等待时间executor.completed 已完成任务数executor.active 活动线程数executor.queued 排队任务数executor.queue.remaining 队列剩余容量executor.pool.size 当前线程数executor.pool.core 核心线程数executor.pool.max 最大线程数2. 指标标签要控制基数线程池名称适合作为标签任务ID、用户ID、订单号不适合。高基数标签会让监控系统自身承受很大压力。如果同一线程池混合多种任务可以按少量、固定的任务类型记录提交量和耗时更细的定位交给日志而不是把每个业务标识都塞进指标标签。五、生产环境如何定位根因第一步确认是哪个线程池应用可能同时存在Web容器线程池、业务线程池、数据库连接池和CompletableFuture公共池。先确认指标对应的Bean、线程名前缀和创建代码避免调错参数。线程名不要使用默认的pool-1-thread-1。像order-query-12、notification-send-4这样的名字在APM和线程转储中更容易定位。第二步看趋势不看单个截图截取故障前后至少10到30分钟的这些曲线提交速率、完成速率队列长度、队列使用率活动线程数、当前线程数、最大线程数排队时间执行时间拒绝数、失败数、超时数CPU、堆内存、GC数据库与HTTP连接池等待、下游接口延迟和错误率如果提交速率上升而执行时间稳定先查流量来源如果提交速率没变但执行时间上涨先查任务内部和下游。第三步连续获取线程转储单份线程转储只能看到一个瞬间。间隔几秒获取三份更容易判断线程是否一直卡在同一位置jcmd pid Thread.print -l重点查找线程名前缀并统计它们的状态大量线程停在数据库驱动、HTTP客户端检查下游延迟和超时停在连接池获取连接线程数已经超过可用连接或连接泄漏停在同一把锁检查锁竞争和临界区第四步从慢任务回到业务输入同一段代码可能只对大文件、特定租户或异常数据变慢。通过日志记录任务类型、输入规模、下游耗时和排队时间找出长尾来自哪里。不要把完整请求对象或敏感字段直接写进日志。通常只需要任务类型、数据量级、脱敏标识和Trace ID。第五步验证故障恢复速度根据净消化速率估算恢复时间预计清空时间 当前队列长度 ÷ (完成速率 - 提交速率)如果预计要几个小时业务需要决定是否扩容、暂停非核心流量或者丢弃已经过期的任务。六、结论线程池队列堆积的直接条件只有一个一段时间内任务进入得比完成得快。背后的原因可能是流量增长也可能是数据库变慢、任务长尾、锁等待、重试放大或线程池配置不合适。真正有用的监控要把队列长度、提交与完成速率、排队时间、执行时间和拒绝数放在一起看。处理时先控制新流量和重试再定位任务为什么变慢确认CPU和下游都有余量后才考虑增加线程或实例。关于ThreadPoolExecutor参数的配置也可以参阅Java线程池参数应该如何设置ThreadPoolExecutor-CSDN博客 线程池队列堆积：原因、监控与解决方案
前言线程池队列从几十涨到几千通常不是“队列参数太小”而是任务进入速度已经超过完成速度。队列只是把差额暂时存了下来。很多处理方式会让问题变得更隐蔽把队列从1000改成10000告警暂时消失但排在后面的任务要等得更久把线程数从20加到200如果瓶颈在数据库结果往往是200个线程一起等连接。堆积没有消失只是换成了接口超时、连接池等待或堆内存上涨。排查线程池堆积时先回答三个问题任务为什么变慢提交量为什么变多当前处理能力能否让队列降下来。本文以Java的ThreadPoolExecutor为主说明如何定位原因、建立监控以及在生产环境中止损和治理。一、什么叫线程池队列堆积ThreadPoolExecutor接收任务时大致按下面的顺序处理提交任务│├─ 当前线程数 corePoolSize│ └─ 创建工作线程执行│├─ 否则尝试放入工作队列│ └─ 入队成功等待执行│├─ 队列已满并且当前线程数 maximumPoolSize│ └─ 创建非核心线程执行│└─ 线程数和队列都达到上限└─ 执行拒绝策略线程数达到核心线程数后新任务会优先入队。只有队列无法继续接收时线程数才会继续增长到maximumPoolSize。所以大队列配小核心线程数时最大线程数可能长期不生效。例如线程池每秒收到50个任务只能完成30个净增长是每秒20个。容量为1000的空队列大约50秒就会装满1000 ÷ (50 - 30) 50秒。也就是说到达速率 完成速率时就会产生堆积的情况换个生动的说法就是比如有一个池子池子有一个入水口一个出水口可以维持水流稳定。但是当入水口增加多个而出水口不变的时候就会使池子中的水不断增加甚至溢出。二、队列为什么会堆积1、短时流量突增定时任务集中触发、消息批量到达、上游补数据都会在短时间内让提交速率超过处理速率。突增结束后如果队列能在业务允许的时间内回落这属于队列原本要吸收的波动。2. 流入量长期超过设计容量业务增长后常态QPS已经超过线程池稳定吞吐量。此时每天都可能出现相同的曲线高峰期持续上涨低峰期缓慢回落最终连低峰期也清不完。3、数据库或远程接口变慢线程池任务常常把大部分时间花在等待获取数据库连接执行慢SQL或等待锁调用HTTP、RPC接口读取对象存储、文件或消息系统假设有20个工作线程单任务耗时原来是100ms理论完成速率约为每秒200个。下游变慢后单任务耗时升到1秒完成速率会降到每秒约20个。提交速率没有任何变化队列也会快速上涨。4、任务内部阻塞或死锁任务可能卡在没有超时的网络调用、锁竞争或无限等待上。5. 参数和队列类型不合适常见配置问题包括Executors.newFixedThreadPool()使用无界LinkedBlockingQueue过载时任务持续累积核心线程数很小、队列很大maximumPoolSize迟迟不能生效线程数超过数据库连接池或HTTP连接池容量大量线程只是换了一个位置等待队列容量只凭经验填写没有对应允许的排队时间6. 重试和任务放大一次请求可能拆成多个异步任务任务失败后又在当前线程池中立即重试。下游故障时原始流量、超时重试和补偿任务叠加提交速率反而比正常时期更高。三、队列堆积会造成什么后果1、排队时间过久导致流程超时有界队列只有装满后才触发拒绝但业务可能早已超时。假设20个线程处理单个耗时200ms的任务队列中已有1000个任务。忽略耗时波动排在尾部的任务大约要等待1000 ÷ 20 × 200ms 10秒2、堆内存和GC压力上升同样是10000个任务只保存订单ID与持有完整订单对象的内存占用可能相差几个数量级。积压严重时老年代占用和Full GC会增加最坏情况是OutOfMemoryError。3. 超时和重试形成反馈循环排队变长会让上游超时。上游如果立即重试新增请求又进入同一个线程池队列增长更快。原本只是某个下游变慢最后可能扩散为Web请求线程、连接池和JVM一起过载。四、监控不能只看queueSize指标作用观察重点queueSize当前排队任务数是否持续增长峰值后能否回落queueRemainingCapacity队列剩余容量只对有界队列有明确意义队列使用率已使用容量占比适合不同容量线程池统一展示activeCount正在执行任务的线程数是否长期接近当前或最大线程数poolSize、maximumPoolSize当前与最大线程数最大线程数是否真正生效提交速率单位时间收到多少任务是否突增是否出现重试放大完成速率单位时间完成多少任务是否低于提交速率任务排队时间从提交到开始执行的时间p95、p99是否超过业务预算任务执行时间从开始到结束的时间长尾是否突然上升最老任务等待时间当前积压里最老任务等了多久比单纯队列长度更接近用户感受拒绝次数线程和队列都饱和后的结果出现一次也应能追踪原因取消、失败和超时数任务最终结果防止“完成了但没成功”1、用Micrometer采集基础指标需要引入Micrometer Jar包import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Tags; import io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ExecutorService; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicInteger; public final class ExecutorConfig { public static ExecutorService orderExecutor(MeterRegistry registry) { AtomicInteger sequence new AtomicInteger(); ThreadPoolExecutor rawExecutor new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), task - new Thread( task, order-query- sequence.incrementAndGet() ), new ThreadPoolExecutor.AbortPolicy() ); return ExecutorServiceMetrics.monitor( registry, rawExecutor, order-query, Tags.empty() ); } }Micrometer可以包装ExecutorService记录线程池状态、任务执行时间和队列等待时间。对于ThreadPoolExecutorMicrometer提供的指标包括executor 任务执行时间executor.idle 任务开始前的等待时间executor.completed 已完成任务数executor.active 活动线程数executor.queued 排队任务数executor.queue.remaining 队列剩余容量executor.pool.size 当前线程数executor.pool.core 核心线程数executor.pool.max 最大线程数2. 指标标签要控制基数线程池名称适合作为标签任务ID、用户ID、订单号不适合。高基数标签会让监控系统自身承受很大压力。如果同一线程池混合多种任务可以按少量、固定的任务类型记录提交量和耗时更细的定位交给日志而不是把每个业务标识都塞进指标标签。五、生产环境如何定位根因第一步确认是哪个线程池应用可能同时存在Web容器线程池、业务线程池、数据库连接池和CompletableFuture公共池。先确认指标对应的Bean、线程名前缀和创建代码避免调错参数。线程名不要使用默认的pool-1-thread-1。像order-query-12、notification-send-4这样的名字在APM和线程转储中更容易定位。第二步看趋势不看单个截图截取故障前后至少10到30分钟的这些曲线提交速率、完成速率队列长度、队列使用率活动线程数、当前线程数、最大线程数排队时间执行时间拒绝数、失败数、超时数CPU、堆内存、GC数据库与HTTP连接池等待、下游接口延迟和错误率如果提交速率上升而执行时间稳定先查流量来源如果提交速率没变但执行时间上涨先查任务内部和下游。第三步连续获取线程转储单份线程转储只能看到一个瞬间。间隔几秒获取三份更容易判断线程是否一直卡在同一位置jcmd pid Thread.print -l重点查找线程名前缀并统计它们的状态大量线程停在数据库驱动、HTTP客户端检查下游延迟和超时停在连接池获取连接线程数已经超过可用连接或连接泄漏停在同一把锁检查锁竞争和临界区第四步从慢任务回到业务输入同一段代码可能只对大文件、特定租户或异常数据变慢。通过日志记录任务类型、输入规模、下游耗时和排队时间找出长尾来自哪里。不要把完整请求对象或敏感字段直接写进日志。通常只需要任务类型、数据量级、脱敏标识和Trace ID。第五步验证故障恢复速度根据净消化速率估算恢复时间预计清空时间 当前队列长度 ÷ (完成速率 - 提交速率)如果预计要几个小时业务需要决定是否扩容、暂停非核心流量或者丢弃已经过期的任务。六、结论线程池队列堆积的直接条件只有一个一段时间内任务进入得比完成得快。背后的原因可能是流量增长也可能是数据库变慢、任务长尾、锁等待、重试放大或线程池配置不合适。真正有用的监控要把队列长度、提交与完成速率、排队时间、执行时间和拒绝数放在一起看。处理时先控制新流量和重试再定位任务为什么变慢确认CPU和下游都有余量后才考虑增加线程或实例。关于ThreadPoolExecutor参数的配置也可以参阅Java线程池参数应该如何设置ThreadPoolExecutor-CSDN博客