callerrunspolicy的核心思想是调用线程自行执行被拒绝任务，通过反压机制自然限流：当线程池饱和时，提交任务的线程同步执行该任务，阻塞自身以降低后续提交速率，从而缓解系统压力，适用于不可丢任务且可容忍延迟的场景。

CallerRunsPolicy 的核心思想是：当线程池饱和（队列满 + 工作线程全忙）时，不丢任务、不抛异常、也不新建线程，而是让提交任务的**调用线程自己执行这个任务**。这相当于把一部分压力“还给”上层调用方，从而降低线程池的瞬时负载。

为什么能“减压”？

它不增加线程池负担，反而通过阻塞调用线程来自然限流：

• 调用线程（比如 Tomcat 的一个 worker 线程）执行任务时，无法继续接收新请求 → 请求入口变慢 → 后续任务提交频率下降
• 任务在调用线程中同步执行，跳过了入队、调度等开销，但代价是该线程暂时“被占用”
• 对上层系统形成负反馈：越拥塞，提交越慢，客观上抑制了过载恶化

典型适用场景

适合那些可以容忍请求响应稍慢、但必须避免任务丢失或崩溃的场景：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 后台管理类接口（如导出报表、批量审核），用户可接受几秒延迟
• 内部服务间调用，下游已具备一定重试和降级能力
• 非实时性要求高的定时聚合任务
• 作为兜底策略，配合其他拒绝策略（如先用 AbortPolicy，再 fallback 到 CallerRunsPolicy）

如何正确配置与使用

不是设上就生效，关键在**线程池参数协同设计**：

• 队列不能无界：必须用有界队列（如 ArrayBlockingQueue），否则永远不触发拒绝逻辑
• 核心线程数不宜过高：避免所有线程长期 busy，失去“腾出空闲”的机会
• 拒绝策略要显式指定：

  new ThreadPoolExecutor(
      2, 4,
      60L, TimeUnit.SECONDS,
      new ArrayBlockingQueue(10),
      new ThreadPoolExecutor.CallerRunsPolicy()
  );

• 注意调用线程性质：若调用方是 Web 容器线程（如 Spring MVC 的 DispatcherServlet 线程），它执行任务期间无法处理其他请求，会降低整体吞吐——这是减压的代价，也是设计意图

常见误区提醒

别把它当成“万能缓存”或“自动扩容”：

• ❌ 认为用了 CallerRunsPolicy 就不用关心队列大小 → 实际上队列太小会导致频繁触发，调用线程大量阻塞
• ❌ 在 Swing 或 Android 主线程中直接使用 → 会导致 UI 冻结，不可接受
• ❌ 和无界队列（LinkedBlockingQueue 默认容量 Integer.MAX_VALUE）混用 → 拒绝策略永远不会生效
• ✅ 正确做法：结合监控（如 rejected execution count）+ 压测，观察调用线程阻塞时长和上游响应时间变化

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