任务队列积压是线程池资源与任务节奏失衡的实时信号，需通过活跃线程数、队列size、未完成任务数三指标交叉验证根因，并区分阻塞型、下游瓶颈型、突发流量型场景精准施策。
任务队列积压不是“队列满了才处理”的事后问题，而是线程池资源与任务节奏失衡的实时信号。关键要快速判断：是真没能力消费，还是假性卡住；是该扩容线程，还是该压降流量或优化下游。
看三个指标是否同步异常
单看队列 size 容易误判，必须交叉验证：
- 活跃线程数（getActiveCount）长期 ≈ corePoolSize，但队列 size 持续上涨 → 核心线程被阻塞（如等 DB 响应、HTTP 超时未设、锁竞争），根本没空取新任务
- 队列 size 接近 capacity（如 ArrayBlockingQueue(200) 中 size=195），且 getActiveCount 稳定在 maxPoolSize → 线程全在跑，但处理太慢，瓶颈在业务逻辑或下游依赖
- getTaskCount() − getCompletedTaskCount()持续扩大，而 getActiveCount 不升反降 → 任务卡在队列里不动，可能线程池已 shutdown，或 Worker 异常退出未被感知
确认队列是否真“有界”且能触发扩容
很多积压问题根源在于扩容机制压根没启动：
- 检查代码中 workQueue 实例化方式：是否用了 new LinkedBlockingQueue()（默认 Integer.MAX_VALUE）？必须显式写成 new LinkedBlockingQueue(200) 或 new ArrayBlockingQueue(200)
- 用 Arthas 执行 ognl '@YourExecutor@getQueue().remainingCapacity()'，确认运行时剩余容量确实在减少
- SynchronousQueue 是“逻辑有界”（capacity=0），每次 offer 都需立即匹配空闲线程，它不积压任务，但会更快触发扩容或拒绝
区分场景做响应处理
不能一概“调大队列或加线程”，要按根因分类施策：
立即学习“Java免费学习笔记（深入）”；
- 核心线程阻塞型：jstack 抓堆栈，重点查 RUNNABLE 状态线程是否卡在 JDBC、RestTemplate、synchronized 块内；加超时、拆分长事务、改异步调用
- 下游瓶颈型：活跃线程打满 + 队列缓慢增长 → 查数据库连接池使用率、第三方 API RT 和错误率；引入熔断（Sentinel/Hystrix）或降级返回
- 突发流量型：队列 size 短时飙升 + getActiveCount 快速逼近 maxPoolSize → 临时上调 maximumPoolSize（需确保机器 CPU/内存余量），并启用 CallerRunsPolicy 缓冲峰值
扩容不是调参，而是闭环动作
扩容线程只是手段，目标是恢复任务吞吐平衡：
- 若决定扩容，maximumPoolSize 建议设为 corePoolSize 的 2～3 倍（IO 密集型可到 5 倍），避免设 Integer.MAX_VALUE
- 扩容后必须监控 getLargestPoolSize()：如果它远高于当前 getPoolSize，说明线程频繁创建又回收，keepAliveTime 可能过短，应适当延长
- 上线后盯住两个水位线：活跃线程数 ≥ 90% maxPoolSize 或 队列剩余容量 ≤ 10%，任一触发即告警
