必须自定义线程池拒绝策略，因其能将被动失败转为可观测事件：通过实现rejectedexecutionhandler提取业务上下文、线程池状态、mdc信息，并支持同步落盘、异步转发、主动告警等多层响应，同时保障线程安全与性能。
Java 线程池拒绝策略不是“可选项”，而是系统稳定性的重要守门人。默认策略（如 AbortPolicy）只抛异常，DiscardPolicy 直接静默丢任务——它们不记录上下文、不区分业务、不联动监控，在生产环境极易导致问题难定位、故障难复现、资损难追溯。
为什么必须自定义拒绝策略？
线程池饱和不是偶发异常，而是资源瓶颈或流量突增的明确信号。但默认策略无法回答关键问题：
- 这个被拒任务来自哪个订单模块？携带了什么 orderNo？
- 拒绝发生时队列长度是多少？活跃线程数是否已达 maximumPoolSize？
- 调用链 traceId 是多少？能否关联到上游 HTTP 请求或 MQ 消息？
没有这些信息，运维只能看到一行“RejectedExecutionException”，排查周期从分钟级拉长到小时级。自定义策略的核心价值，就是把“被动失败”变成“可观测事件”。
自定义策略的关键实现逻辑
需实现 RejectedExecutionHandler 接口，重点在 rejectedExecution(Runnable r, ThreadPoolExecutor e) 方法中安全提取和结构化信息：
- 优先做类型判断：若任务是
OrderTask或PaymentRunnable，强转后调用getOrderId()、getTimestamp()等业务 getter，避免依赖不可靠的toString() - 逐层解包：Spring Security 的
DelegatingSecurityContextRunnable或 JDK 的FutureTask需 unwrap 获取原始任务 - 记录线程池状态：通过
e.getQueue().size()、e.getActiveCount()、e.getCompletedTaskCount()获取实时指标 - 注入 MDC：写入
traceId、businessCode等字段，确保日志可跨服务串联
生产级策略应支持多层响应
单一动作难以应对复杂场景，推荐组合使用：
- 同步落盘：将任务元数据序列化后写入本地文件或 Redis，供人工核查或补偿调度
- 异步转发：发送至 Kafka/RocketMQ，由下游消费者重试、降级或存档
- 主动告警：调用告警 SDK，携带线程池名、拒绝数量、队列水位百分比等维度，避免“静默丢任务”
- 日志异步化：使用 SLF4J + AsyncAppender，防止 I/O 阻塞拒绝处理流程
注意线程安全与性能边界
拒绝策略本身不能成为新瓶颈：
- 避免在拒绝逻辑中执行耗时操作（如同步 DB 写入、远程 HTTP 调用）
- 日志记录必须异步，MDC 上下文需在线程进入拒绝方法时立即快照
- 若任务对象含敏感字段（如用户手机号），需脱敏后再记录
- 策略类应无状态，避免实例变量引发并发问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
