线程池饱和度监控需基于相对使用率与变化速率预警，而非等待队列填满；有界队列看百分比（70%～80%阈值），无界队列用绝对水位（如size>1000），synchronousqueue则盯活跃线程数与submit延迟；需结合动态水位比、拒绝计数及线程工厂唯一性验证，报警须含实时指标与可操作建议。
线程池饱和度监控的核心是提前识别任务积压趋势，而不是等队列真正“满”了才响应。关键变量不是绝对数量，而是相对使用率和变化速率——比如队列使用率连续3次超过85%，且每秒入队任务数比出队数多20%以上，就已构成实质性溢出风险。
队列使用率：必须结合容量类型看
不同队列实现对“饱和”的定义完全不同：
-
有界队列（如 ArrayBlockingQueue）：直接用
queue.size() / queue.capacity()计算百分比，阈值建议设为 70%～80%。超过即说明缓冲余量不足，后续稍有流量波动就可能触发拒绝策略。 -
无界队列（如 LinkedBlockingQueue，默认 Integer.MAX_VALUE）：不能依赖 size/capacity（结果恒为 0），应改用
queue.size() > 1000或更合理的业务水位线（例如日均峰值的 1.5 倍）作为硬性阈值。 - 同步移交队列（SynchronousQueue）：容量恒为 0，此时“饱和”表现为活跃线程数持续等于最大线程数，且 submit 调用开始出现明显延迟或被拒绝。
动态水位比：比静态阈值更准
单纯看当前使用率容易误报。推荐引入时间维度，计算短周期内的趋势指标：
- 过去 30 秒内，队列长度的标准差 > 平均值的 40%，说明任务提交极不均衡，系统已进入不稳定态；
- 当前队列长度 ÷ 过去 1 分钟平均完成任务数 > 5，意味着即使所有线程全速消费，也要 5 秒以上才能清空积压，响应延迟必然超标；
- 连续 5 次检测中，队列 size 增量 ≥ 0，且活跃线程数 ≥ 最大线程数 × 90%，基本可判定消费能力已达瓶颈。
报警触发前必须验证的两个前提
避免误报的关键，在于排除临时抖动和配置误配：
-
确认拒绝策略未静默吞没任务：若使用 DiscardPolicy 或 DiscardOldestPolicy，队列未满但任务已丢失，此时队列使用率低却存在真实风险。需同步监控
getRejectedExecutionCount()（需自定义 ThreadPoolExecutor 或通过 DynamicTp 等框架暴露）； - 核对线程工厂是否生效：如果线程命名混乱、无法区分归属线程池，多个池子的监控数据就会混在一起。务必确保每个线程池都使用带唯一前缀的 ThreadFactory，否则“某个队列告警”根本无法定位到具体业务模块。
报警内容要带可行动线索
一条有效报警不应只说“队列过载”，而应包含即时可查的上下文：
- 当前队列 size / capacity = X / Y，使用率 Z%；
- 最近 60 秒平均入队速率 A task/s，平均出队速率 B task/s，净积压 C task/s；
- 关联线程池：活跃线程数 M / 最大线程数 N，核心线程数 P；
- 最近一次拒绝发生在 T 秒前，类型为 [AbortPolicy / CallerRunsPolicy …]；
- 建议动作：检查下游服务响应时间、查看对应业务日志关键词（如 “timeout”、“fallback”）、临时扩容 maximumPoolSize（如支持动态调整）。
