线程池任务拒绝处理方法及自定义实现

线程池拒绝任务会中断业务，因默认AbortPolicy抛RejectedExecutionException且调用方未捕获；需自定义异步、可观察、有兜底的拒绝策略，并与线程池参数联动压测验证。

为什么线程池拒绝任务会直接中断业务

线程池拒绝任务本身不抛异常，但默认的 AbortPolicy 会在拒绝时抛出 RejectedExecutionException。如果调用方没捕获、也没做兜底（比如重试或降级），整个请求链就断了——不是线程池“挂了”，而是你没接住这个异常。

• 常见错误现象：接口偶发 500，日志里只有 java.util.concurrent.RejectedExecutionException，没其他堆栈
• 根本原因不是线程池太小，而是拒绝策略没适配业务语义：支付下单不能丢，日志上报可以丢
• 注意 execute() 抛异常，submit() 则把异常包进 Future.get()，容易漏捕获

怎么写一个真正可用的自定义拒绝处理器

别只实现 RejectedExecutionHandler 接口就完事。关键是要让拒绝行为可观察、可控制、不阻塞主线程。

• 拒绝逻辑必须异步执行：比如发告警、写本地日志、投递到 Kafka 备份，绝不能在 rejectedExecution() 里同步调远程服务
• 避免死循环：若备份队列也满，要设上限（如最多缓存 100 条）并丢弃老任务，否则内存持续增长
• 示例骨架：

  public class LoggingAndFallbackPolicy implements RejectedExecutionHandler {
      private final BlockingQueue fallbackQueue = new LinkedBlockingQueue<>(100);
      
      @Override
      public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
          // 记录拒绝事实（注意别打太频繁）
          if (fallbackQueue.offer(r)) {
              // 异步消费 fallbackQueue，例如用单线程 ScheduledExecutorService 定期 drain
          } else {
              // 达上限，直接丢并告警
              log.warn("Fallback queue full, dropping task: {}", r);
          }
      }
  }

四种内置拒绝策略的实际表现差异

不同策略对业务连续性影响天差地别，选错比不配置还危险。

• AbortPolicy（默认）：抛 RejectedExecutionException，适合强一致性场景，但要求调用方全链路处理异常
• CallerRunsPolicy：由提交线程自己执行任务，看似“不丢”，实则可能拖慢上游（比如 HTTP 请求线程被卡住），并发高时雪崩风险大
• DiscardPolicy：静默丢弃，适合纯异步、可丢失的任务（如埋点上报），但无任何反馈，线上难排查
• DiscardOldestPolicy：丢队列头任务，换新任务进来——对有严格时序要求的任务（如订单状态机更新）可能引发状态错乱

线程池配置与拒绝策略必须联动验证

单独改拒绝策略没用，得和 corePoolSize、maximumPoolSize、workQueue 一起压测验证。

• 常见坑：用 LinkedBlockingQueue 且没设容量上限，结果永远不触发拒绝——表面“稳定”，实则 OOM 风险极高
• 性能影响：拒绝策略本身不该成为瓶颈，但若在其中做同步 I/O（如写文件、发 HTTP），会拖慢整个线程池的拒绝响应速度
• 兼容性注意：Spring 的 @Async 默认用 SimpleAsyncTaskExecutor（无队列），不走你配的线程池，拒绝策略对其无效

真正难的不是写个拒绝处理器，是搞清哪些任务绝对不能丢、哪些可以降级、哪些丢了之后有没有补偿路径。拒绝策略只是最后一道闸门，闸门之前得有水位监控、弹性扩缩、流量染色这些配套动作。