要精准定位触发线程池拒绝的业务，需在提交任务时主动携带业务标识，如封装带businesscode等字段的taskwrapper，在自定义rejectedexecutionhandler中解析并记录结构化日志，配合micrometer按biz标签聚合监控与告警。
给任务打上业务标识
线程池本身不区分任务来源，要精准定位哪个业务触发了拒绝，关键是在提交任务时主动携带可识别的上下文。最直接的方式是封装 Runnable 或 Callable，把业务名、接口名、traceId 甚至用户ID等信息作为字段注入。
例如：不直接 submit(() -> doWork())，而是构造一个带标签的任务对象：
- 自定义 TaskWrapper 类，含 businessCode、method、timestamp 字段
- 在 rejectedExecution 方法中，从 Runnable 参数里取出该 wrapper，提取 businessCode 记录日志或上报监控
- 避免用 ThreadLocal 传递业务信息——拒绝发生在 executor 内部，调用线程可能已退出，ThreadLocal 值不可靠
在自定义拒绝策略里做解析和归因
内置策略（如 AbortPolicy、DiscardPolicy）只处理动作，不记录来源。必须实现自己的 RejectedExecutionHandler，在 rejectedExecution(Runnable r, ThreadPoolExecutor e) 方法中做两件事：
- 判断 r 是否为已知的可识别类型（比如实现了 NamedTask 接口，或继承自 BaseTask）
- 若不是，则尝试 toString() 或反射获取类名，结合包路径粗略归类（如 com.xxx.order.service → “订单服务”）
- 将 businessCode + 队列 size + 当前 activeCount 一并写入结构化日志，方便 ELK 或 Prometheus 标签检索
配合统一任务注册与埋点机制
单靠拒绝时刻抓取信息容易遗漏，建议前置增强任务提交链路：
- 所有业务线通过统一的 TaskSubmitter 提交任务，强制传入 @NotBlank String bizTag
- submitter 内部包装任务，并在 MDC 中写入 bizTag，确保即使后续异步执行也能在日志中体现
- 在拒绝策略中读取 MDC 是无效的（MDC 绑定在线程上），但可以在包装时把 bizTag 存入 Runnable 字段，实现跨线程携带
- 对高频业务（如支付回调、消息消费）单独配置独立线程池，从物理层面隔离，拒绝即意味着该业务过载，无需再解析
拒绝指标按业务维度聚合
监控不能只看“总拒绝数”，要拆到业务粒度：
- 用 Micrometer 注册 Counter，name 为 threadpool.rejected.tasks，tags 包含 biz:order、env:prod
- 在自定义拒绝策略中，根据任务携带的 bizTag 执行 counter.tag("biz", tag).increment()
- Prometheus 查询时可用 sum by (biz)(rate(threadpool_rejected_tasks_total[1h])) 快速发现异常突增的业务线
- 告警规则按 biz 标签设置不同阈值，核心业务拒绝率 > 0.1% 就触发 P0，非核心可设为 5%
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
