Java线程池拒绝策略是资源耗尽时的最终处置规则，含AbortPolicy（抛异常）、CallerRunsPolicy（调用者执行）、DiscardPolicy（静默丢弃）、DiscardOldestPolicy（丢最老任务）四种内置策略，需根据业务场景选择并配置。
Java线程池的拒绝策略，是当线程池已满（活跃线程数达 maximumPoolSize 且任务队列已满）时，对新提交任务的最终处置规则。它不是“可有可无”的配置，而是系统在资源耗尽边界上的最后一道并发保护机制。
为什么必须设置拒绝策略
线程池不是无限容器。它受三个硬性约束限制：
- 核心线程数（corePoolSize）——常驻线程底线
- 最大线程数（maximumPoolSize）——线程扩容上限
- 任务队列容量（如 ArrayBlockingQueue(10)）——缓冲区大小
只有当三者全部打满，新任务才触发拒绝策略。此时不设策略，系统可能因无节制创建线程或无限堆积任务而OOM或响应雪崩。
四种内置拒绝策略的核心行为
AbortPolicy（默认）：抛出 RejectedExecutionException，调用方必须捕获处理。适合强一致性、需快速失败告警的场景，比如支付下单。
立即学习“Java免费学习笔记（深入）”；
CallerRunsPolicy：让提交任务的线程（如Web容器的Tomcat线程）自己执行该任务。效果是主动降速——调用者被阻塞，自然抑制后续提交节奏。适合允许轻微延迟、但不能丢任务的后台任务。
DiscardPolicy：静默丢弃，不抛异常、不通知。适合日志上报、埋点统计等可丢失、低优先级任务。
DiscardOldestPolicy：丢掉队列里最老的一个任务，再尝试提交当前任务。适用于新数据价值远高于旧数据的流式处理，比如实时行情推送。
如何选择与配置
拒绝策略通过 ThreadPoolExecutor 构造器的 handler 参数指定，也可后期用 setRejectedExecutionHandler() 动态替换：
- 高可用服务（如API网关）倾向 AbortPolicy + 全链路监控告警，确保过载可感知
- 内部批处理系统常用 CallerRunsPolicy，靠业务线程反压实现柔性降级
- 异步通知类模块（邮件/SMS）可选 DiscardPolicy，避免因下游抖动拖垮上游
- 消息消费端若采用有界队列，DiscardOldestPolicy 能防止消息严重积压导致时效性归零
自定义策略不是“炫技”，而是补位
内置策略覆盖常见模式，但真实业务常需组合动作。例如：
- 丢弃时记录到本地文件，供后续补偿
- 拒绝瞬间触发Prometheus指标+企业微信告警
- 将任务转存至Kafka重试队列
只需实现 RejectedExecutionHandler 接口，在 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法中编写逻辑即可。关键是要明确：拒绝不是终点，而是可控的分流起点。
