可通过自定义RejectedExecutionHandler结合Micrometer埋点统计拒绝次数，并用Prometheus+Grafana大盘监控，按pool标签下钻分析，辅以日志和排队时长诊断根因。
Java线程池的拒绝策略本身不直接暴露调用频次，但可以通过自定义拒绝策略 + Metrics（如Micrometer或Dropwizard Metrics）实现触发次数的采集与大盘展示。
自定义拒绝策略并埋点计数
标准的 RejectedExecutionHandler（如 AbortPolicy、CallerRunsPolicy）不会记录被拒任务。你需要包装或重写它，在拒绝逻辑中主动上报指标：
- 继承
ThreadPoolExecutor.AbortPolicy或直接实现RejectedExecutionHandler - 在
rejectedExecution(Runnable r, ThreadPoolExecutor executor)方法内，调用 Metrics 的计数器（Counter）+1 - 推荐使用 Micrometer 的
Counter，例如：Counter.builder("threadpool.rejection.count")<br> .tag("pool", "biz-task-pool")<br> .register(meterRegistry)
绑定到具体线程池实例（避免指标混淆）
一个应用常有多个线程池（如 IO 密集型、CPU 密集型、定时任务等），需确保每个池的拒绝事件打上唯一标识：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 在创建线程池时，将池名作为 tag 传入 Counter（如
.tag("pool", "order-processor")） - 若使用 Spring，可通过
@Bean方法注入MeterRegistry，并在构造拒绝策略时传入池名和 registry - 避免所有线程池共用同一个 Counter，否则无法下钻分析哪个池压力大
接入 Prometheus + Grafana 做大盘
Micrometer 默认支持 Prometheus 格式暴露指标。配置好后，Grafana 中可构建如下看板：
立即学习“Java免费学习笔记（深入）”；
- 图表类型：Time series 或 Stat
- 查询示例（PromQL）：
rate(threadpool_rejection_count_total{application="myapp"}[5m])
表示过去 5 分钟每秒平均拒绝次数 - 叠加维度：按
pool标签拆分，支持点击下钻查看单个线程池的突增趋势 - 建议加告警：当
rate(...[1m]) > 0.5持续 2 分钟，说明线程池持续过载，需排查队列积压或处理变慢
补充建议：拒绝原因辅助诊断
仅统计次数不够，还可扩展记录上下文辅助定位问题：
- 在拒绝时打印简要日志（非全量，避免刷屏）：
log.warn("Task rejected by [{}], queueSize={}, activeCount={}", poolName, executor.getQueue().size(), executor.getActiveCount()) - 用 Timer 记录拒绝前的排队等待时间（从提交到被拒绝的时间），判断是否因队列过长导致
- 结合 JVM 线程数、GC 时间、CPU 使用率等指标交叉分析，确认是线程池配置不合理，还是下游依赖响应拖慢
