AbortPolicy在任务无法提交时立即抛出RejectedExecutionException异常，不静默丢弃、不重试、不排队，必须显式捕获处理以避免调用线程中断；触发于execute()或submit()调用瞬间，常见于线程池关闭、队列满且线程达最大值等场景。
当线程池使用 AbortPolicy 作为拒绝策略时，一旦任务无法被提交（比如队列已满、线程数已达最大值且都在忙），它会直接抛出 RejectedExecutionException 异常，**不会静默丢弃，也不会重试或排队**。关键在于：这个异常必须被显式捕获和处理，否则会导致调用线程（如主线程或 Web 请求线程）中断甚至崩溃。
明确异常发生时机
该异常在调用 execute() 方法时立即抛出（submit() 同样触发），不是在线程执行时。也就是说，任务根本没进队列、也没被任何工作线程接手，就在提交那一刻失败了。
- 常见触发场景：线程池已 shutdown、核心线程+队列+最大线程全满、动态调整后容量突降
- 注意：
execute()是 void 方法，异常不会被“吞掉”，必须由调用方负责 try-catch
推荐的异常处理方式
不能放任异常向上冒泡，尤其在服务端应用中。应结合业务语义选择合理降级动作：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
-
记录日志 + 通知监控：记录完整堆栈、当前线程池状态（如
getQueue().size()、getActiveCount()），触发告警 - 同步降级处理：例如转为当前线程直接执行（仅适用于轻量、非阻塞任务，避免阻塞调用方）
- 返回友好响应：Web 场景下可返回 503 Service Unavailable 或自定义限流提示
- 异步重试（谨慎）：仅在幂等且允许延迟的场景下，用带退避的独立线程重试提交，避免雪崩
避免误用 AbortPolicy 的典型错误
很多人以为设了 AbortPolicy 就“自动保护”了系统，其实恰恰相反——它把压力完全转移给了调用方：
立即学习“Java免费学习笔记（深入）”；
- 未 catch 异常，导致上层逻辑中断（如 Spring MVC 接口直接 500）
- 在循环中批量 submit 却只包一层 try-catch，导致一个失败就跳出整个流程
- 把 AbortPolicy 和无界队列（如 LinkedBlockingQueue）混用，看似永不拒绝，实则掩盖内存泄漏风险
替代策略对比（供参考）
如果不想手动处理异常，可考虑其他内置策略：
- CallerRunsPolicy：由调用线程自己执行任务 → 简单降级，但可能拖慢调用方
- DiscardPolicy：静默丢弃 → 适合允许丢失的场景（如日志采集）
- DiscardOldestPolicy：丢弃队首任务再尝试提交 → 可能影响任务顺序
- 自定义策略：继承
RejectedExecutionHandler，实现更精细控制（如写入 Kafka 备份、触发熔断）
