最准确安全的方式是 executor.getQueue().size()，但需结合队列类型（SynchronousQueue 恒为 0）、处理速率（TPS=完成数/时间）、三级水位阈值及活跃线程数、拒绝数交叉分析。
直接调用 getQueue().size() 是获取线程池队列积压任务数最常用、最轻量的方式，但光看这个数字容易误判，必须结合队列类型、采集频率、处理速率和水位阈值一起用。
怎么安全准确地获取队列积压数
对 ThreadPoolExecutor，使用以下方式获取当前待执行任务数量：
-
推荐写法：
executor.getQueue().size()—— 返回阻塞队列中尚未被线程取走的任务数 -
注意队列差异：
-
LinkedBlockingQueue/ArrayBlockingQueue：返回真实积压数，size()是 O(1) -
SynchronousQueue：始终返回0，它不存储任务，积压实际体现为生产者线程阻塞在put() -
PriorityBlockingQueue：size()正确，但无法反映高优先级任务是否被低优任务“挡在后面”
-
-
避免踩坑：
- 不要打印
executor.getQueue()对象本身（如LinkedBlockingQueue@xxx），看不出任何数值 - 不要在任务执行逻辑里同步调用
size()并据此决定是否提交新任务，易引发竞态或雪崩 - 高频轮询（如每毫秒）会带来无谓开销，建议采样间隔设为 1–5 秒
- 不要打印
只看 size=180 没意义？得算“清空要多久”
积压数本身是静态快照，真正关键的是它会不会越堆越多。需要搭配处理速率做动态预判：
- 每 10 秒采集一次
getCompletedTaskCount()差值 → 得到**实际每秒完成任务数（TPS）** - 同时记录当前
getQueue().size()→ 得到**积压存量** - 计算预估清空时间：存量 ÷ TPS；若结果 > 60 秒，即使未达阈值也应预警
- 举例：队列有 300 个任务，过去 10 秒完成 50 个 → TPS ≈ 5 → 预估清空需 60 秒 → 触发预警
设定三级水位，让监控能驱动动作
单一阈值容易误报，按积压程度分三级更实用（具体数值需结合压测确定）：
- 正常区（如 ≤ 50）：不做干预，维持默认配置
-
预警区（如 51–200）：
- 降低新任务准入率（如限流 30%）
- 缩短单任务超时时间（防长尾阻塞）
- 记录慢任务 trace ID，用于后续分析
-
过载区（如 > 200）：
- 拒绝非核心任务（返回 HTTP 429）
- 启用降级逻辑（如返回缓存旧数据）
- 触发自动扩容（需配合动态线程池实现）
别忘了关联拒绝数和活跃线程数看全貌
队列积压不是孤立现象，要交叉验证其他指标才能定位根因：
- 如果
getActiveCount()远低于getMaximumPoolSize()，但队列持续上涨 → 说明任务执行慢（IO 阻塞、DB 响应长、锁竞争） - 如果
getActiveCount()接近最大值 + 队列还在涨 → 线程已饱和，系统吞吐见顶 - 一旦
getRejectedExecutionCount() > 0→ 拒绝策略已被触发，不是“偶尔发生”，而是系统防线已破，必须立刻响应
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
