线程池任务积压的典型表现是threadpoolexecutor.getqueue().size()持续增长、getactivecount()长期等于corepoolsize或maximumpoolsize、rejectedexecutionexception频繁出现；这些指标连续3–5分钟超阈值即可判定积压。
线程池任务积压的典型表现是什么
任务积压不是“程序卡了”这么模糊，而是有明确可观测信号：ThreadPoolExecutor.getQueue().size() 持续增长、getActiveCount() 长期等于 getCorePoolSize() 或 getMaximumPoolSize()、拒绝异常 RejectedExecutionException 频繁出现。这些指标在监控系统里一旦连续 3–5 分钟超出阈值（比如队列长度 > 1000），基本可以判定积压已发生，不是瞬时抖动。
- 积压不等于慢：哪怕单个任务执行很快，只要提交速率 > 消费速率，队列就会涨
-
LinkedBlockingQueue默认无界，getQueue().size()可能悄悄涨到几万，OOM 前毫无预警 -
SynchronousQueue不存任务，积压会直接表现为拒绝，但掩盖了“为什么提交太快”的根因
怎么用 JMX 或 Micrometer 抓到关键指标
JMX 是 JVM 内置通道，不用加依赖就能拿到原始数据；Micrometer 更适合对接 Prometheus，但得确认 Spring Boot 版本是否自动暴露了 taskExecutor 相关 meter。
- 必须采集的三个指标：
pool.activeThreads、pool.queueSize、pool.completedTasks - Spring Boot 2.4+ 默认关闭 JMX 的
ThreadPoolTaskExecutorMBean，需显式配置：spring.task.execution.pool.jmx.enabled=true - Micrometer 下，若用
@Bean自定义ThreadPoolTaskExecutor，要手动调用new MeterRegistryCustomizer()注册，否则指标为空 - 注意：
queueSize对SynchronousQueue永远是 0，别拿它当积压判断依据
报警阈值怎么设才不会误报或漏报
阈值不是拍脑袋定的。先看历史水位：取过去 7 天每 5 分钟的 queueSize 95 分位数，再上浮 20%；再叠加业务节奏——大促期间允许短时冲高，但持续超过 2 分钟就该响。
- 队列长度报警不能只设一个绝对值：低峰期
queueSize > 50就该告警，高峰期可能要放宽到> 500 - 拒绝率比队列长度更敏感：
rejected.count / (completed.count + rejected.count)> 0.5% 持续 1 分钟，必须触发 - 别忽略线程活跃度：如果
activeThreads == corePoolSize且queueSize在涨，说明扩容没生效，可能是allowCoreThreadTimeOut=false锁死了
积压发生后，光加机器或调大线程数为什么常失效
调大 corePoolSize 或换更大队列，只是把问题往后推。根本矛盾是「下游处理能力」和「上游提交节奏」不匹配，而线程池本身不解决背压。
- 加线程数 → CPU 上下文切换开销上升 → 单任务延迟反而升高 → 队列积压更严重
- 换
ArrayBlockingQueue设固定容量 → 拒绝变多，但没告诉上游“别发了”，错误被吞掉 - 真正有效的动作：在入口层做限流（如
Resilience4j RateLimiter），或改用响应式背压（如Project Reactor的onBackpressureBuffer） - 临时止血可动态调小
keepAliveTime，让空闲线程更快回收，腾出资源给活跃任务，但治标不治本
线程池积压的本质是系统边界失守，监控和报警只是探针，真正难的是定位哪个环节吃不消、以及敢不敢让上游慢下来。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
