CallerRunsPolicy的核心思想是调用线程自行执行被拒绝任务，通过反压机制自然限流：当线程池饱和时，提交任务的线程同步执行该任务，阻塞自身以降低后续提交速率，从而缓解系统压力，适用于不可丢任务且可容忍延迟的场景。
CallerRunsPolicy 的核心思想是：当线程池饱和（队列满 + 工作线程全忙）时，不丢任务、不抛异常、也不新建线程，而是让提交任务的**调用线程自己执行这个任务**。这相当于把一部分压力“还给”上层调用方，从而降低线程池的瞬时负载。
为什么能“减压”？
它不增加线程池负担，反而通过阻塞调用线程来自然限流：
- 调用线程（比如 Tomcat 的一个 worker 线程）执行任务时，无法继续接收新请求 → 请求入口变慢 → 后续任务提交频率下降
- 任务在调用线程中同步执行，跳过了入队、调度等开销，但代价是该线程暂时“被占用”
- 对上层系统形成负反馈：越拥塞，提交越慢，客观上抑制了过载恶化
典型适用场景
适合那些可以容忍请求响应稍慢、但必须避免任务丢失或崩溃的场景：
- 后台管理类接口（如导出报表、批量审核），用户可接受几秒延迟
- 内部服务间调用，下游已具备一定重试和降级能力
- 非实时性要求高的定时聚合任务
- 作为兜底策略，配合其他拒绝策略（如先用 AbortPolicy，再 fallback 到 CallerRunsPolicy）
如何正确配置与使用
不是设上就生效，关键在**线程池参数协同设计**：
立即学习“Java免费学习笔记（深入）”；
- 队列不能无界：必须用有界队列（如 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）+ 压测，观察调用线程阻塞时长和上游响应时间变化
