拒绝频率是线程池最真实的过载信号，它在线程数达maximumpoolsize且队列满时发生，精准反映资源耗尽；需通过自定义拒绝策略埋点采集，并结合拒绝率、密度与任务耗时反推并发缺口，再依趋势动态扩容。
拒绝频率是线程池在生产环境中最直接、最真实的“过载信号”。它不像CPU或内存使用率那样存在滞后或干扰，而是明确告诉你：当前配置已无法承载实际流量。用好这个指标，就能从被动救火转向主动扩容预测。
为什么拒绝频率比队列长度更可靠
队列积压可能因单个慢任务长期占位而虚高，但拒绝只发生在线程数已达 maximumPoolSize 且队列也满的瞬间——这是资源真正耗尽的铁证。尤其在使用有界队列（如 ArrayBlockingQueue）时，拒绝发生即代表系统已触达当前并发容量上限。
常见误区是依赖平均响应时间或线程活跃数做判断，这些指标受I/O等待、GC停顿等干扰大；而拒绝次数是原子性事件，可精确采集、不可伪造、天然带业务上下文（比如哪个接口、哪类请求被拒）。
如何准确采集与归因拒绝频率
关键不是“有没有拒绝”，而是“谁在什么条件下拒绝”。需在自定义拒绝策略中埋点：
- 继承 RejectedExecutionHandler，在 reject() 方法里记录：时间戳、任务类型（如 HTTP / DB / MQ）、提交线程名、当前队列 size、活跃线程数、系统 load 均值
- 避免仅打印日志——日志易丢失、难聚合。应同步上报到监控系统（如 Prometheus + Grafana），打上 service、endpoint、env 标签
- 区分拒绝来源：是突发流量导致？还是某个下游超时拉长了任务执行时间，间接压垮队列？需结合链路追踪（如 SkyWalking）反查被拒任务的上游调用链
从拒绝频率反推并发容量缺口
假设某接口在 1 分钟内发生 12 次拒绝，平均每 5 秒 1 次。这不是孤立事件，而是容量瓶颈的持续暴露。可用以下方式量化缺口：
- 拒绝率 = 拒绝数 / 总提交数。若该值稳定 ≥ 0.5%，说明当前配置已逼近极限；≥ 2% 通常意味着必须扩容
- 拒绝密度 = 拒绝数 / 时间窗口（秒）。例如 60 秒内拒 30 次 → 密度为 0.5 次/秒。这相当于每 2 秒就有 1 个任务“无处安放”，可近似换算为缺失的并发处理能力
- 结合任务平均执行时间（P95）反推：若平均耗时 200ms，拒绝密度 0.5 次/秒，则理论缺失吞吐 ≈ 0.5 × (1000 / 200) = 2.5 QPS —— 这就是当前配置下“永远追不上的”那部分流量
基于拒绝趋势做变量扩容预测
拒绝不是静态阈值，而是动态曲线。真正的预测能力来自观察其随时间的变化规律：
- 看斜率：过去 1 小时拒绝数从 0 → 180 → 720，呈指数上升，说明负载增长远快于线程池弹性，此时不应只加固定线程数，而要启动最大线程数（maximumPoolSize）的阶梯式上调（如每次 +2，间隔 5 分钟）
- 看周期性：每日 10:00 和 15:00 出现拒绝高峰，与业务活动强相关。可提前 10 分钟按历史峰值的 1.3 倍预热 maximumPoolSize，并在峰后 15 分钟自动回落
- 看关联指标：当拒绝频率上升同时，keepAliveTime 内回收的非核心线程数骤降 → 说明新线程创建后立即投入高负荷，未进入空闲期，此时单纯调大 keepAliveTime 无效，必须提升 corePoolSize 或 workQueue 容量
不复杂但容易忽略
