abortpolicy 直接抛出 rejectedexecutionexception 中断调用并丢弃任务，适合可重试场景；callerrunspolicy 由调用线程同步执行任务以实现反压，适合不可丢但可延迟的任务。

AbortPolicy 和 CallerRunsPolicy 是 Java 线程池最常用的两种拒绝策略，它们应对“任务无法提交”这一场景的思路完全不同：一个选择立刻中断、暴露问题；另一个选择让调用方自己执行，以慢换稳。

触发条件完全一致

两者都只在以下两个条件同时满足时才会被触发：

• 线程池中线程数已达 maximumPoolSize
• 工作队列（如 ArrayBlockingQueue 或 LinkedBlockingQueue）已满

也就是说，不是随便任务多就触发，而是线程和队列双重耗尽后的“最后防线”。此时线程池已无任何缓冲余地。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

AbortPolicy：快失败，靠调用方兜底

它不做任何妥协，直接抛出 RejectedExecutionException，中断当前 execute() 调用。

• 任务彻底丢弃，不执行也不重试
• 异常必须由上层捕获——否则会导致业务线程中断
• 适合上游具备重试能力的场景，比如 HTTP 查询、RPC 调用
• 配合监控告警使用效果最好：一抛异常，立刻知道系统过载，需要扩容或限流

CallerRunsPolicy：慢执行，把压力传回去

它不抛异常，也不丢任务，而是让提交任务的那个线程（比如 Tomcat 的 worker 线程、Netty 的 EventLoop 线程）同步执行这个被拒的任务。

• 任务不会丢失，但执行延迟明显上升
• 调用线程被阻塞，自然降低任务提交速率，形成反向背压
• 适合不可丢、可延迟的后台任务，比如日志写入、指标聚合、审计记录
• 风险在于：若大量触发，可能拖垮 Web 容器线程池，导致请求堆积甚至雪崩

怎么选，关键看三件事

不用纠结理论，直接问自己：

• 这个任务丢了影响大不大？——影响大就别用 AbortPolicy
• 系统能不能接受响应变慢？——不能就慎用 CallerRunsPolicy
• 上游调用方能不能处理失败？——能重试、能降级，AbortPolicy 反而是更干净的选择

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南