CallerRunsPolicy会让提交任务的线程同步执行被拒绝的任务，不丢弃、不抛异常、不扩容，通过反压实现自然限流，适用于不可丢任务且可接受延迟的场景。
当线程池任务队列已满且线程数达到最大值时，CallerRunsPolicy 会让**调用线程（即提交任务的线程）自己执行该任务**，从而实现一种轻量、无丢弃、不抛异常的降级回退方式——它不拒绝任务，也不扩容，而是把压力“反压”回上游，天然具备节流与自我保护能力。
CallerRunsPolicy 的核心行为
该策略不会丢弃任务、不抛 RejectedExecutionException，也不会新建线程或入队等待。它直接在调用者线程中同步执行被拒绝的任务。这意味着：
- 提交任务的线程会阻塞，直到该任务执行完成
- 客观上降低了任务提交速率（因为调用线程被占用），形成自然限流
- 适用于可接受短暂延迟、但不可丢失任务的场景（如日志采集、监控上报）
如何启用 CallerRunsPolicy
创建线程池时，通过 ThreadPoolExecutor 构造器或 setRejectedExecutionHandler 显式设置：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // corePoolSize
4, // maxPoolSize
60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(10), // 队列容量为 10
new ThreadPoolExecutor.CallerRunsPolicy() // 关键：启用该策略
);
也可以后期替换策略：
立即学习“Java免费学习笔记（深入）”；
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
配合业务逻辑实现优雅降级
单纯使用 CallerRunsPolicy 只是基础机制，真正“优雅”取决于你如何设计调用方逻辑。常见做法包括：
-
非关键路径主动降级：例如异步发通知任务，在被
CallerRunsPolicy回退执行时，可记录 warn 日志并跳过耗时校验或重试逻辑 - 控制调用线程类型：避免在 Web 请求线程（如 Tomcat worker 线程）中被阻塞太久。建议将任务提交封装在独立调度线程或带超时的异步包装中
-
结合监控告警：统计调用线程执行任务的频次和耗时，当
CallerRunsPolicy触发率持续偏高，说明线程池长期承压，需预警扩容或优化任务
注意事项与典型误区
该策略看似简单，但容易误用：
- 不要在定时任务或 RPC 响应线程中无防护地使用——可能拖慢整个请求链路
- 若任务本身耗时很长，会导致调用线程长时间阻塞，反而降低系统吞吐
- 它不解决根本瓶颈，只是缓释手段；需配合队列大小、线程数、任务耗时等指标综合调优
- 与
AbortPolicy（抛异常）、DiscardPolicy（静默丢弃）相比，它更“温和”，但对调用方要求更高
