AbortPolicy会直接抛出RejectedExecutionException，需显式捕获处理；触发条件为线程池关闭或核心线程满、队列满且无法创建新线程；应通过try-catch包裹execute()并记录上下文日志，是否替换取决于业务可靠性要求。
当线程池使用 AbortPolicy 作为拒绝策略时，一旦任务无法被接受（比如队列已满、线程数已达最大值），线程池会直接抛出 RejectedExecutionException 异常，而不是静默丢弃或重试。这个异常必须被显式捕获处理，否则会导致调用线程中断或程序异常终止。
AbortPolicy 的触发时机
它在 ThreadPoolExecutor.execute() 方法中被触发，前提是满足以下任一条件：
- 线程池已关闭（
isShutdown() == true） - 核心线程数已满、工作队列已满、且创建新线程失败（达到
maximumPoolSize）
如何正确捕获和处理该异常
不能依赖“不抛异常就没事”的侥幸心理。每次调用 execute() 都应考虑异常路径：
- 用
try-catch包裹execute()调用，捕获RejectedExecutionException - 避免在循环中无保护地批量提交——一次异常可能让后续任务全部跳过
- 日志记录要包含上下文，例如任务类型、当前线程池状态（
getActiveCount()、getQueue().size()）
示例：
立即学习“Java免费学习笔记（深入）”；
try {
executor.execute(() -> doSomething());
} catch (RejectedExecutionException e) {
log.warn("Task rejected by thread pool: {}", e.getMessage());
// 可选：降级处理，如写入本地队列、发告警、或同步执行
doSomething(); // 同步执行作为兜底
}
是否应该换掉 AbortPolicy？
不是“该不该换”，而是“是否符合你的可靠性要求”：
- 适合对任务丢失敏感、需要快速失败暴露问题的场景（如金融交易校验）
- 不适合高吞吐但允许少量丢失的后台任务（此时可选
DiscardPolicy或CallerRunsPolicy） - 若想保留 AbortPolicy 行为但增强可观测性，可自定义策略继承它，并在抛出前打点或上报指标
排查常见误用
很多问题其实不是策略本身的问题，而是配置或调用方式不当：
- 线程池初始化时未设置合理的核心/最大线程数和队列容量，导致轻易触发拒绝
- 用了
submit()却没处理Future.get()可能抛出的ExecutionException（它包装了RejectedExecutionException） - 在 Spring 等框架中，通过
@Async使用线程池时，异常会被吞掉或转为AsyncTaskException，需额外配置异常处理器
