AbortPolicy 是 ThreadPoolExecutor 默认拒绝策略，通过抛出 RejectedExecutionException 明确告知资源耗尽；仅在线程数达 maximumPoolSize 且工作队列满（或线程池已关闭）时触发；异常是过载信号而非 bug，适用于支付、库存等强一致性场景；需结合监控告警、降级兜底、限流前置和容量复盘应对；对可丢弃或弱一致任务应改用 DiscardPolicy、CallerRunsPolicy 或自定义策略。
AbortPolicy 是 ThreadPoolExecutor 的默认拒绝策略，它的核心作用不是“阻止你用线程池”，而是用抛出 RejectedExecutionException 的方式，明确告诉你：资源已耗尽，当前任务无法接纳——必须立刻响应。
触发时机很明确
它只在两个条件同时满足时才生效：
- 线程数已达
maximumPoolSize - 工作队列（如
ArrayBlockingQueue）也已满
注意：线程池处于 shutdown() 或 shutdownNow() 状态时，也会触发。只要没显式设置 setRejectedExecutionHandler(...)，就一定是 AbortPolicy 在起作用。
异常不是 bug，是信号
抛异常本身不等于出错，而是一种主动暴露问题的机制：
立即学习“Java免费学习笔记（深入）”；
- 日志中出现
java.util.concurrent.RejectedExecutionException: Task rejected from ...，说明系统正在过载 - 没加
try-catch就直接崩掉？这不是策略的问题，是调用方没做好防御 - 适合对数据一致性要求高、不能静默丢任务的场景（比如支付扣款、库存预占）
应对方案要分层设计
不能只靠“捕获一下完事”，得结合业务目标来落地：
- 监控告警：在 catch 块里记录 ERROR 日志，并触发 Prometheus + AlertManager 告警，提示线程池水位异常
- 降级兜底：捕获后可返回默认值、走缓存、或调用轻量级本地逻辑（避免级联失败）
- 限流前置：在任务提交前加 Sentinel 或 Resilience4j 限流，把压力挡在入口，减少触发概率
-
容量复盘：持续观察拒绝次数，反推是否需调整
corePoolSize、maxPoolSize或队列类型/大小
什么时候不该用 AbortPolicy
如果业务能容忍少量延迟或丢失，且更看重系统稳定性而非强一致性，那默认策略反而成了负担：
- 日志采集类任务：丢了不影响主链路，可用
DiscardPolicy - 实时性要求不高但不可丢的任务：考虑
CallerRunsPolicy让调用方减速执行 - 希望保活+尽力而为：自定义策略，把被拒任务写入 DB 或 MQ，后续重试
