CallerRunsPolicy的核心价值是作为压力调节阀，通过调用者线程同步执行任务实现反压降级；适用于不能丢任务、可容忍短时延迟、上游线程可控的场景，需配合有界队列、合理线程数及短耗时任务（≤200ms）使用。
CallerRunsPolicy 的核心价值，不在于“多执行一个任务”，而在于用调用者线程的同步执行，给系统争取喘息时间。它不是加速器，是压力调节阀。
什么时候该用 CallerRunsPolicy？看三个硬指标
它适合那些不能丢任务、能忍一忍延迟、且上游线程可控的场景。比如内部服务异步通知、日志聚合、非实时报表生成。如果任务本身来自 Web 请求线程（如 Tomcat 的 worker 线程），就要格外小心——让请求线程去执行耗时任务，会直接拖慢接口响应。
- 任务逻辑执行时间短（建议 ≤ 200ms），否则调用线程阻塞太久，影响上游吞吐
- 工作队列必须是有界的（如
ArrayBlockingQueue），无界队列会让拒绝策略永远不触发 - 线程池最大线程数不宜设得过大，否则压力全被扛住，背压效果失效
配置要点：有界队列 + 合理容量 + 明确策略
关键不在“加策略”，而在整套参数协同起效。例如：
- 核心线程数设为 2～4，避免空闲资源浪费
- 最大线程数控制在 6～10，防止线程过多引发上下文切换开销
- 队列长度建议设为 5～20，太小易频繁触发降级，太大则失去缓冲预警作用
- 明确指定
new ThreadPoolExecutor.CallerRunsPolicy()，不依赖默认策略
降级生效时，你该看到什么？
不是报错，而是日志里出现熟悉的线程名突然“越界”执行任务。比如原本只该出现在后台线程里的业务日志，开始在 main、http-nio-8080-exec-7 或 grpc-default-executor-3 这类调用者线程中输出。这说明反压已启动——提交任务的线程正被占用，无法立刻发起下一次提交。
- 监控上会看到线程池活跃线程数稳定在最大值，队列长度持续满载
- 整体 QPS 缓慢下降，但错误率几乎为零，没有
RejectedExecutionException - 部分请求 P95 延迟抬升，但 P50 变化不大，体现的是“选择性减速”，而非崩溃
要避开的坑：递归调用与线程污染
如果任务执行逻辑里又往同一个线程池 submit 新任务，就可能形成调用链闭环：A 提交 → 拒绝 → A 执行 → A 再提交 → 再拒绝 → A 再执行……最终栈溢出或线程卡死。
- 确保被降级执行的任务代码是纯计算或轻量 I/O，不嵌套提交同类任务
- 若任务涉及远程调用，务必设置超时（如
feign的connectTimeout和readTimeout），防止调用者线程无限等待 - 在关键路径上加简单熔断开关，当连续 N 次触发 CallerRunsPolicy 时，主动关闭该异步通道，彻底退到同步直写或本地缓存
