abortpolicy是线程池默认拒绝策略，在线程池未关闭且工作队列已满时触发，抛出rejectedexecutionexception；需在提交点捕获异常、记录上下文日志、同步上报监控，并配套熔断降级与预检shutdown状态。
AbortPolicy 是线程池默认的拒绝策略，它不隐藏问题，而是用 RejectedExecutionException 明确告诉你：“系统已满，任务无法接纳”。但抛异常本身不是目的——关键在于如何把这次“拒绝”变成可定位、可监控、可响应的动作。
AbortPolicy 的触发时机要清楚
它只在两个条件**同时成立**时才生效：
- 线程池未关闭（
!isShutdown()），但当前线程数已达maximumPoolSize - 工作队列已满（且为有界队列，如
ArrayBlockingQueue(2)）
此时再调用 execute()，就会直接抛出异常。注意：submit() 同样会触发，因为底层仍走 execute 路径。
异常不能裸抛，必须做三件事
只写 executor.execute(runnable) 而不做任何捕获，等于把压力甩给上层容器（比如 Tomcat），结果往往是 HTTP 500、无日志、难复现。
- 必须 try-catch RejectedExecutionException：不能依赖全局异常处理器，要在提交点附近捕获
- 记录带上下文的日志：至少包含任务 ID、业务类型（如 “payment-callback-task”）、提交时间、线程名；避免只打 “任务被拒” 这种无效信息
-
同步打点到监控系统：例如调用
metrics.counter("threadpool.rejected", "type=pay").increment()，并关联 traceId，方便链路下钻
配套熔断与降级不可少
抛异常只是信号，业务不能停摆。常见应对方式：
- 对非核心任务（如日志上报、埋点聚合），自动降级为异步本地写文件，后续补偿上传
- 对关键路径（如支付回调确认），触发 Hystrix 或 Sentinel 熔断，短时拒绝同类请求，避免雪崩
- 配合告警规则：比如“1 分钟内 rejected ≥ 5 次”立即企微/钉钉通知负责人，附上最近 3 条拒绝日志片段
别忽略 shutdown 后的二次提交
线程池调用 shutdown() 后，若仍有线程在提交任务，也会触发 AbortPolicy。建议在提交前加轻量预检：
if (executor.isTerminated() || executor.isShutdown()) {
log.warn("线程池已关闭，跳过任务提交：{}", taskId);
return;
}
executor.execute(task);
这能避免日志被大量重复的“rejected from terminated pool”刷屏，干扰真实问题排查。
