1. 从一次线上告警说起为什么拒绝策略不是摆设那天晚上十一点手机突然开始疯狂震动。打开监控一看核心服务的接口响应时间曲线直接拉成了一条直线紧接着就是一连串的“服务不可用”告警。紧急登录服务器jstack一看好家伙线程池里堆积了上千个等待执行的任务队列早就满了而新来的请求还在源源不断地往里挤。最要命的是日志里除了满屏的RejectedExecutionException几乎看不到任何有意义的业务错误信息。用户只看到“服务器繁忙”而我们却不知道到底是谁、因为什么被拒绝了。这次事故让我彻底明白Java 线程池的拒绝策略RejectedExecutionHandler绝不是一个可以随意选择、甚至忽略的配置项。它是在系统资源边界被触及时守护应用稳定性的最后一道也是至关重要的一道防线。很多人包括曾经的我都以为把corePoolSize、maxPoolSize和workQueue配好就万事大吉拒绝策略随便选个AbortPolicy抛个异常了事。但现实是当流量洪峰真的来临时这道防线的表现直接决定了是“优雅降级”还是“雪崩崩溃”。线程池的拒绝策略发生在什么时刻简单说就是当线程池无法接受新任务的时候。具体触发条件有三个必须同时满足1. 线程池的线程数已经达到maximumPoolSize最大线程数2. 任务队列workQueue也已经满了3. 此时仍然有新的任务被提交通过execute方法。这三个条件像三道闸门全部关闭后ThreadPoolExecutor就会调用我们设定的RejectedExecutionHandler来处理这个“无家可归”的任务。理解这四个内置策略AbortPolicy,CallerRunsPolicy,DiscardOldestPolicy,DiscardPolicy的细微差别和适用场景是构建健壮并发系统的必备技能。这不仅仅是面试八股文更是血与泪换来的经验。2. 策略一AbortPolicy —— 默认的“熔断器”AbortPolicy是ThreadPoolExecutor默认采用的拒绝策略。它的行为非常直接且“暴力”当新任务被拒绝时直接抛出一个RejectedExecutionException运行时异常。// ThreadPoolExecutor 默认构造函数使用的就是 AbortPolicy public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue) { this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, Executors.defaultThreadFactory(), new AbortPolicy()); // 看这里 } // AbortPolicy 的简单实现 public static class AbortPolicy implements RejectedExecutionHandler { public AbortPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { throw new RejectedExecutionException(Task r.toString() rejected from e.toString()); } }为什么这是默认策略这其实体现了一种“快速失败”Fail-Fast的设计哲学。在开发、测试阶段或者对系统稳定性要求极高、不允许任何任务丢失的场景下AbortPolicy是最佳选择。它像一个严厉的哨兵一旦系统负载超过预设的承载能力立刻以异常的方式大声告警迫使开发者必须正面处理资源不足的问题而不是让任务悄无声息地堆积、延迟最终导致内存溢出或线程死锁。我经历过一次教训在某个数据同步服务中为了“不丢数据”最初选择了沉默的DiscardPolicy。结果在源头系统爆发脏数据时线程池默默丢弃了大量任务导致下游数据严重不一致排查起来极其困难。如果当时用的是AbortPolicy异常日志会第一时间告诉我们系统过载了我们就能更快地介入比如触发流控或报警。它的核心价值在于“可观测性”和“防止状态不一致”。抛出的异常会沿着调用链向上传播你可以通过全局异常处理器如 Spring 的ControllerAdvice捕获它然后将其转化为对用户友好的错误提示如“系统繁忙请稍后再试”并同时触发监控告警。这比系统默默承受、内部队列不断膨胀最终拖垮整个服务要安全得多。注意使用AbortPolicy时调用方必须做好异常处理。不能简单地execute(task)了事至少要用try-catch包裹或者在提交任务时使用Future并在后续get()时处理异常。否则未捕获的RejectedExecutionException可能导致线程意外终止如果提交任务的是单个线程或错误信息丢失。那么AbortPolicy适合什么场景核心交易链路比如支付、下单。这些操作必须保证要么成功、要么明确失败绝不能静默丢弃。失败后应有明确回滚或补偿机制。资源严格受限的实时系统系统承载能力有明确上限超出的部分必须立刻拒绝以保护系统不崩溃。开发和测试环境帮助开发者快速发现线程池配置不合理如队列过长、最大线程数过小的问题。它的缺点也很明显对调用方有侵入性需要处理异常。在突发流量下如果大量请求被拒绝并抛异常可能会快速消耗完调用方的资源如 Web 容器的线程池或者给用户带来不好的体验。因此它通常需要与上游的限流、熔断组件如 Sentinel、Hystrix配合使用构成多级防护。3. 策略二CallerRunsPolicy —— “谁调用谁负责”的回退方案CallerRunsPolicy提供了一个非常巧妙的回退机制当线程池饱和时它不会在池内拒绝任务而是让调用execute方法的那个线程自己去执行这个被拒绝的任务。public static class CallerRunsPolicy implements RejectedExecutionHandler { public CallerRunsPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { if (!e.isShutdown()) { r.run(); // 注意这里是 run()不是 start()意味着在当前线程同步执行。 } } }这个策略的行为初看有些反直觉但它的妙处在于实现了某种程度的自适应流量整形和负反馈。想象一下你的 Web 应用使用一个线程池来处理业务逻辑。当这个线程池满载时新来的 HTTP 请求由 Tomcat 的线程处理如果提交任务被拒CallerRunsPolicy会让这个 Tomcat 线程自己去执行业务逻辑。这会导致什么会导致这个 Tomcat 线程被占用更长时间从而减慢它处理新请求的速度。对于调用方这里是 Tomcat 线程池来说它提交任务的速度自然就降下来了。这形成了一个天然的负反馈循环从源头降低了任务提交的压力给了线程池喘息和消化队列中任务的机会。它如何起到“削峰填谷”的作用在流量脉冲场景下线程池短时间过载CallerRunsPolicy通过让调用线程参与工作暂时降低了新任务的涌入速率避免了队列无限增长。一旦线程池中的任务被处理一些有了空闲资源调用线程就能很快恢复正常的提交速度而不会因为抛异常导致大量请求立即失败。我曾在处理一个图片缩略图生成服务时应用此策略。高峰期生成请求暴涨使用AbortPolicy会导致大量用户看到生成失败。改用CallerRunsPolicy后前端请求的响应时间虽然会变长因为 Tomcat 线程被用来执行生成任务但绝大多数请求最终都能成功完成用户体验从“频繁失败”变成了“等待后成功”是一个可接受的降级。但是使用CallerRunsPolicy有非常严格的先决条件踩坑点极多调用线程必须能够承受阻塞如果调用线程本身是异步事件循环如 Netty 的 I/O 线程或者有严格的响应时间要求如 RPC 框架的客户端线程让它们去执行一个可能耗时的任务会严重破坏其原有的职责可能导致更严重的连锁故障。比如一个数据库连接池的管理线程如果被阻塞可能会引起连接泄漏。任务不能有线程上下文依赖有些任务依赖ThreadLocal变量如 Spring 的事务上下文、安全上下文。当任务从线程池线程“转移”到调用者线程执行时这些上下文可能会丢失或错乱导致业务逻辑错误。可能引起死锁或性能瓶颈如果调用链是同步的且调用者线程在等待任务完成虽然run()是同步的但任务内部可能再提交子任务可能会形成复杂的锁依赖甚至死锁。更常见的是如果大量调用者线程被拖慢它们本身可能成为新的全局性能瓶颈。适用场景分析批处理任务的领导者-跟随者模式一个主控线程调用者产生任务交给线程池执行。当池满时主控线程自己处理不会影响任务产生的逻辑。可以接受同步延迟的 Web 后端服务如上文的图片处理例子前提是评估好对 Web 容器线程池的影响。测试或原型阶段作为一种简单的、无需额外组件的流量控制手段。不适用场景异步编程模型如 Reactor, Vert.x。对响应时间极其敏感的在线服务。调用者线程本身是共享资源且不可阻塞的情况。4. 策略三DiscardOldestPolicy 与 DiscardPolicy —— 沉默的代价与选择当任务可以容忍丢失时我们会考虑丢弃策略。Java 提供了两种DiscardOldestPolicy和DiscardPolicy。它们的共同点是“沉默”即拒绝时不会抛出异常但行为上有关键区别。DiscardOldestPolicy丢弃队列中最老的任务。public static class DiscardOldestPolicy implements RejectedExecutionHandler { public DiscardOldestPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { if (!e.isShutdown()) { e.getQueue().poll(); // 丢弃队列头部的任务最老的 e.execute(r); // 尝试重新执行当前任务 } } }这个策略试图做一个“权衡”它牺牲队列里等待时间最长的那个任务来换取新任务的执行机会。这听起来似乎有点“喜新厌旧”但在某些场景下有奇效。例如在一个实时股票价格推送系统中队列里积压的是一分钟前的价格而新到来的是当前最新价格。显然最新的价格信息价值更高丢弃旧的价格是合理的。又比如一个监控数据采集服务如果处理速度跟不上丢弃一些历史采样点确保最新的系统状态能被记录可能比让队列堆积导致整个采集进程停滞更好。然而它的风险极高任务丢失不可控你丢弃的可能是某个关键任务。如果队列中的任务有前后依赖关系丢弃一个可能导致后续一系列任务状态错误。公平性问题对最早提交的任务不公平可能导致某些用户或请求永远得不到服务。调试地狱任务静默消失没有日志没有异常。当出现业务逻辑问题时你很难定位是不是因为任务被丢弃了。这是我踩过最深的一个坑在一个订单状态更新服务中使用了这个策略结果偶尔会出现订单状态“卡住”不更新的诡异情况。排查了几天数据库、消息队列最后才怀疑到线程池通过给每个任务添加唯一ID和日志才发现是旧的状态更新任务被丢弃导致订单状态机无法推进。DiscardPolicy直接丢弃当前被拒绝的任务。public static class DiscardPolicy implements RejectedExecutionHandler { public DiscardPolicy() { } public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { // 什么都不做直接丢弃任务r } }这是最“彻底”的沉默策略。新任务来了池满队列满直接当作什么都没发生。它的使用场景非常狭窄仅适用于那些完全无状态、可任意丢弃、且丢弃后无任何副作用的任务。例如一些非关键的日志记录、无关紧要的统计信息上报、或者周期性的缓存刷新因为下次周期还会执行。在实际生产环境中我几乎从未见过可以安全使用DiscardPolicy的场景。任何有价值的数据或操作其丢失都需要被感知和记录。那么如果真的需要丢弃任务正确的做法是什么答案是不要直接使用这两个内置策略而是实现自定义的拒绝策略。在自定义策略中你可以在丢弃任务前做以下几件关键的事记录日志和指标至少用WARN级别记录下被丢弃的任务信息如任务ID、类型、提交时间。同时递增一个监控指标如 Metrics 中的计数器这样你可以在仪表盘上清晰地看到任务丢弃的速率。根据任务类型决策可以在任务Runnable对象上增加一个priority字段或canDiscard标记。在拒绝时先判断任务属性只丢弃那些低优先级或可丢弃的。触发告警当丢弃速率超过某个阈值时主动发送告警提示运维人员系统可能已处于亚健康状态。public class LoggingDiscardPolicy implements RejectedExecutionHandler { private static final Logger LOG LoggerFactory.getLogger(LoggingDiscardPolicy.class); private final Meter discardMeter; // 假设使用Micrometer指标库 Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 1. 记录详细日志 LOG.warn(Task rejected and discarded. Pool: {}, Task: {}, executor, r); // 2. 记录指标 discardMeter.mark(); // 3. 可选这里可以加入更复杂的逻辑如尝试放入一个二级缓存队列或者发送到死信队列 // 4. 最终如果决定丢弃就什么也不做相当于DiscardPolicy或者可以调用其他策略 } }总之内置的DiscardOldestPolicy和DiscardPolicy是“危险品”除非你非常清楚自己在做什么并且有完备的监控和补救措施否则应避免直接使用。自定义的、增强的丢弃策略才是工程上的最佳实践。5. 实战配置如何为你的场景选择与定制策略了解了四种策略的脾性我们来看看在实际项目中如何做选择。这不是一个简单的单选题而需要结合业务特性、系统架构和运维能力来综合决策。我通常会遵循以下决策流程第一步分析任务特性这是最重要的前提。问自己几个问题任务是否允许失败如果不允许AbortPolicy或其变种是唯一选择。失败后是否需要立即告知调用方如果需要AbortPolicy。任务是否有优先级新任务是否比老任务更重要如果是可以考虑增强版的DiscardOldestPolicy配合优先级判断。任务是否完全无关紧要如果否绝不要用纯DiscardPolicy。调用者线程是否适合执行任务检查调用链判断CallerRunsPolicy是否可行。第二步评估系统架构调用方是谁是同步的 Web 请求是异步的消息监听器还是定时任务调度器不同的调用方对CallerRunsPolicy的承受能力天差地别。是否有上游流控如果系统前方有 API 网关、负载均衡器或专门的限流组件如 Sentinel它们已经承担了第一道防护那么线程池的拒绝策略可以更激进一些如AbortPolicy因为超量请求本就不该到达这里。是否有下游熔断和降级如果调用方有熔断机制当捕获到RejectedExecutionException时可以快速熔断避免持续冲击。这时AbortPolicy也能很好地配合。第三步制定组合策略与降级方案单一策略往往不够。我常用的模式是“主策略 自定义兜底”。场景案例一个电商平台的订单创建服务。核心诉求订单创建不能静默丢失但也要尽量避免直接给用户返回“系统繁忙”。策略设计主策略使用AbortPolicy。因为订单数据必须保证一致性不允许随意丢弃。自定义兜底在提交订单任务的代码处用try-catch包裹execute()。当捕获到RejectedExecutionException时不直接向用户报错而是执行降级逻辑。降级逻辑实现public class OrderService { Resource private ThreadPoolExecutor orderTaskExecutor; // 配置了AbortPolicy Resource private OrderAsyncQueue orderAsyncQueue; // 一个高可用的持久化队列如Redis Stream/RabbitMQ public CreateOrderResponse createOrder(CreateOrderRequest request) { // ... 参数校验等前置逻辑 ... try { orderTaskExecutor.execute(() - { // 核心的、耗时的订单创建和库存扣减逻辑 doCreateOrder(request); }); return CreateOrderResponse.success(订单提交处理中); } catch (RejectedExecutionException e) { // 线程池饱和触发降级 log.warn(Order thread pool saturated, fallback to async queue. RequestId: {}, requestId); // 1. 记录监控指标 metrics.counter(order.threadpool.rejected).increment(); // 2. 将订单请求放入异步队列 orderAsyncQueue.push(request); // 3. 立即返回用户告知订单已进入排队 return CreateOrderResponse.success(订单已进入排队请稍后在订单列表中查看结果); } } }这样我们既利用了AbortPolicy的快速失败特性及时感知系统压力又通过业务层的降级逻辑将瞬时压力转移到了更抗压的异步队列中保证了用户体验的平滑。后台可以有独立的消费者从orderAsyncQueue中取出任务以较慢但稳定的速度处理。第四步配置监控与告警无论选择哪种策略监控必须到位。关键监控项包括线程池活跃度activeCount,poolSize,largestPoolSize任务队列情况queueSize,remainingCapacity拒绝次数这是最重要的指标之一你需要暴露RejectedExecutionHandler被调用的次数。如果是自定义策略在里面打点如果是内置策略可以通过ThreadPoolExecutor的getRejectedExecutionCount()方法获取需要子类覆写rejectedExecution方法并计数或通过 JMX 监控。任务处理耗时completedTaskCount以及自定义的任务处理时间直方图。告警规则示例当“拒绝次数在1分钟内增长超过100次”或“队列持续占用率超过80%达5分钟”时触发告警提醒研发或运维介入检查。6. 超越内置实现自定义拒绝策略的进阶技巧当内置的四种策略都无法完美满足需求时自定义拒绝策略是必然选择。除了前面提到的日志、指标和降级这里分享几个更进阶的自定义策略实现技巧。技巧一动态策略切换根据系统实时负载动态切换拒绝策略。例如在业务低峰期为了不丢失任何任务可以采用CallerRunsPolicy在业务高峰期或系统已知承载能力不足时切换为AbortPolicy并结合上游限流。这可以通过一个包装类来实现public class DynamicRejectedExecutionHandler implements RejectedExecutionHandler { private RejectedExecutionHandler lowLoadHandler new CallerRunsPolicy(); private RejectedExecutionHandler highLoadHandler new LoggingAbortPolicy(); // 自定义的带日志的Abort private volatile boolean isHighLoad false; // 可以由外部监控系统通过JMX或HTTP接口调用此方法来切换模式 public void setHighLoad(boolean highLoad) { this.isHighLoad highLoad; } Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { if (isHighLoad) { highLoadHandler.rejectedExecution(r, executor); } else { lowLoadHandler.rejectedExecution(r, executor); } } }技巧二带重试机制的拒绝策略对于一些暂时性的过载任务可能只是需要稍等片刻。我们可以实现一个策略将被拒绝的任务暂存到一个轻量的、内存安全的延迟队列中稍后重试。public class RetryLaterPolicy implements RejectedExecutionHandler { private final ScheduledExecutorService retryScheduler Executors.newSingleThreadScheduledExecutor(); private final BlockingQueueRunnable retryQueue new LinkedBlockingQueue(1000); // 控制重试队列大小 public RetryLaterPolicy() { // 启动一个后台线程定期从重试队列中取出任务重新提交 retryScheduler.scheduleAtFixedRate(this::drainRetryQueue, 1, 1, TimeUnit.SECONDS); } Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { log.info(Task rejected, adding to retry queue.); if (!retryQueue.offer(r)) { log.error(Retry queue is full, task will be discarded.); // 队列也满了执行最终的降级如记录到死信队列 sendToDeadLetterQueue(r); } } private void drainRetryQueue() { ListRunnable tasks new ArrayList(); retryQueue.drainTo(tasks); // 批量取出 for (Runnable task : tasks) { if (!executor.isShutdown()) { try { executor.execute(task); // 重试提交 } catch (RejectedExecutionException e) { // 重试时再次被拒放回队列等待下次重试 retryQueue.offer(task); } } } } }注意这种策略要非常小心因为它实际上扩大了系统的承载能力内存队列如果任务生产速度持续大于消费速度会导致重试队列膨胀最终 OOM。必须设置队列上限并设计队列满后的最终处理方案如丢弃或持久化。技巧三与线程池参数联动的智能策略拒绝策略不应该孤立存在。一个更智能的策略可以观察线程池的当前状态如队列剩余容量、活跃线程数并做出更精细的决策。例如可以判断如果队列只剩下很少容量则直接丢弃如果队列还很空但线程数已满则尝试让调用者执行类似CallerRunsPolicy。这需要对ThreadPoolExecutor的内部状态有深入的了解。技巧四面向切面AOP的增强在 Spring 环境中你可以利用 AOP 来统一增强所有线程池的拒绝行为而无需修改每个线程池的配置。定义一个切面拦截ThreadPoolExecutor的execute方法在抛出RejectedExecutionException时进行统一处理如记录日志、发送事件、触发降级等。这样可以将拒绝处理的逻辑与业务代码解耦。7. 避坑指南那些年我们踩过的拒绝策略的“坑”理论说再多不如踩一次坑记得牢。下面是我和团队在多年实践中总结的几个典型陷阱。坑一误用CallerRunsPolicy导致上游服务雪崩这是最常见的坑。在一个微服务架构中服务 A 调用服务 B服务 B 使用线程池处理请求并配置了CallerRunsPolicy。当服务 B 的线程池饱和时调用者线程即服务 A 的 HTTP 客户端线程可能是 Feign 或 RestTemplate 的线程被阻塞去执行任务。这导致服务 A 调用服务 B 的线程大量被占用且响应变慢。服务 A 本身也是一个 Web 服务它处理外部请求的线程池因此被间接拖慢进而导致服务 A 对外部用户的响应变慢。故障就这样从服务 B 向上游服务 A 传导最终可能引发整个调用链的雪崩。避坑方法在微服务间调用或任何跨进程/跨组件的场景下谨慎使用CallerRunsPolicy。明确调用者线程的身份和职责。如果调用方是业务无关的、专用于远程调用的线程池则绝对禁止使用此策略。更安全的做法是使用AbortPolicy并在调用方配置合理的超时、重试和熔断机制。坑二DiscardOldestPolicy导致状态不一致如前文订单状态更新的例子。任务 A状态待支付 - 已支付先进入队列任务 B状态已支付 - 已完成后进入。如果线程池饱和DiscardOldestPolicy会丢弃任务 A然后执行任务 B。但任务 B 依赖任务 A 的结果状态“已支付”由于任务 A 未执行状态仍然是“待支付”导致任务 B 执行时逻辑错误或失败。这种由任务依赖关系引发的静默错误极其难查。避坑方法在设计任务时尽量避免任务间有强状态依赖。如果必须有依赖要么将它们合并成一个原子任务要么使用更高级的框架如 CompletableFuture 链、工作流引擎来管理依赖。绝对不要在存在依赖关系的任务队列中使用DiscardOldestPolicy。坑三忽略shutdown状态下的拒绝行为ThreadPoolExecutor在shutdown()或shutdownNow()之后会拒绝所有新提交的任务。此时无论配置何种拒绝策略rejectedExecution方法都会被调用。但很多自定义策略的实现没有检查executor.isShutdown()。例如在shutdown后如果自定义策略还试图将任务重新放入队列或尝试重试可能会导致任务在关闭阶段被意外执行干扰资源的正常释放甚至造成死锁。避坑方法在自定义RejectedExecutionHandler的rejectedExecution方法中第一行代码就应该是if (executor.isShutdown()) { return; }。确保线程池关闭时拒绝策略不会执行任何可能干扰关闭过程的逻辑。坑四没有监控等于盲人骑马使用了DiscardPolicy或静默的自定义策略却没有配套的监控指标。线上系统任务处理量莫名下降业务出现数据缺口排查起来如同大海捞针。你无法确定是任务没有被生产还是被线程池静默丢弃了。避坑方法为每一个线程池的拒绝事件建立监控。无论策略多么“沉默”在业务层面必须“有声”。可以通过继承ThreadPoolExecutor并重写rejectedExecution方法在里面调用super.rejectedExecution的同时递增一个计数器如使用 Micrometer 的Counter。将这个计数器暴露给 Prometheus 或类似的监控系统并设置告警。这是线上系统稳定性的生命线。线程池的拒绝策略这个看似简单的配置点实则是并发编程中“防御性编程”思想的集中体现。它要求我们在设计系统时就必须思考其边界和失败模式。没有一种策略是银弹只有深刻理解其原理、结合具体业务场景、并辅以完善的监控告警才能让线程池真正成为我们手中稳定而强大的工具而不是系统中的一个“暗雷”。下次配置线程池时不妨多花几分钟思考一下如果洪水来临这里的堤坝该如何决口才能将损失降到最低