ASM不能直接监控拒绝策略触发频次，需通过字节码注入在rejectedExecution方法入口调用ConcurrentHashMap+LongAdder计数器，并经HTTP或JMX暴露数据。
不能用 ASM 直接“监控拒绝策略触发频次”——ASM 是字节码操作工具，它能修改、插入或拦截方法调用，但本身不提供计数、时间窗口、聚合统计等运行时监控能力。真正可行的是：用 ASM 在目标拒绝策略执行入口（如 RejectedExecutionHandler.rejectedExecution()）注入字节码，埋点调用一个轻量级计数器（如 ConcurrentHashMap + 原子计数），再通过 HTTP 端点或 JMX 暴露频次数据。
定位拒绝策略的关键字节码位置
Java 线程池的拒绝逻辑集中在 ThreadPoolExecutor 的 reject() 方法，该方法最终调用 handler.rejectedExecution(task, executor)。你需要在所有实现了 RejectedExecutionHandler 接口的类中，对 rejectedExecution 方法进行增强：
- 优先匹配 JDK 自带实现：
AbortPolicy、DiscardPolicy、DiscardOldestPolicy、CallerRunsPolicy - 也需覆盖自定义实现类（可通过 ASM 的
ClassReader扫描所有已加载类，或配合 Java Agent 的transform钩子） - 注意：JDK 9+ 模块系统下，部分类默认不可反射/重定义，需添加
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
用 ASM 插入计数逻辑（非侵入式）
在 rejectedExecution 方法的入口插入一段字节码，调用你预置的静态计数器。例如：
- 新增静态字段：
private static final ConcurrentHashMap<String, LongAdder> COUNTERS = new ConcurrentHashMap<>(); - 在方法开头插入：
COUNTERS.computeIfAbsent("AbortPolicy", k -> new LongAdder()).increment(); - 使用 ASM 的
MethodVisitor在visitCode()后插入INVOKESTATIC调用你的计数器方法，避免修改原逻辑分支 - 不建议在方法末尾或异常路径重复计数——拒绝策略本就是“已决定拒绝”，只应在进入时记录一次
暴露和读取频次数据
计数只是第一步，还需让外部可观测：
- 提供一个简单的 HTTP handler（如嵌入 Undertow 或暴露为 Spring Boot Actuator endpoint），返回 JSON 格式：
{"AbortPolicy":127,"CallerRunsPolicy":3} - 或注册为 JMX MBean，支持通过 jconsole、Prometheus JMX Exporter 采集
- 可选加时间维度：用
LongAdder记录总量，另起一个定时任务每分钟快照并清零，生成滑动窗口频次（如“过去 60 秒内 Abort 触发 42 次”） - 避免锁竞争：每个策略类型用独立
LongAdder实例，不共享计数器
注意事项与常见陷阱
这种方案看似透明，但有几处关键约束必须处理：
- 不要在计数逻辑里做 I/O、日志打印或远程调用——会拖慢拒绝路径，反而加剧线程池压力
- 若应用使用了多个线程池（如 IO 池、计算池、定时池），需确保计数器 key 区分来源，例如拼接
executor.toString()或传入自定义名称 - Java Agent 方式比编译期 ASM 更实用：无需重新打包，支持热加载，且能捕获动态生成的策略类（如 Spring AOP 代理类）
- ASM 修改后务必验证字节码校验（
CheckClassAdapter），否则可能触发VerifyError导致类加载失败
