callerrunspolicy 是线程池饱和时强制调用线程同步执行任务的反压机制，需同时满足有界队列、线程数达最大且全忙、队列已满三条件才触发，本质是阻塞而非分担，旨在通过延迟倒逼上游减速。

CallerRunsPolicy 不是让主线程“主动帮忙”，而是当线程池彻底饱和时，系统强制把任务塞回提交线程——主线程（比如 main）、Web 容器线程（如 http-nio-8080-exec-7）或 gRPC 调用线程，会突然停下来同步执行这个本该异步的任务。这不是协作，是反压信号：你提交得太快，系统已无余力，只能让你自己等。

它生效的前提条件很硬

这个“分担”根本不会发生，除非同时满足三个硬性条件：

• 工作队列必须是有界的（例如 new ArrayBlockingQueue(10)），无界队列（如 LinkedBlockingQueue() 默认构造）会让任务无限堆积，拒绝策略永远不触发
• 线程池已达到最大线程数（maximumPoolSize），且所有线程都在忙
• 有界队列也已满，此时第 n+1 个任务才会走拒绝逻辑，落到调用者线程头上

所谓“分担”，其实是主线程被拖慢

主线程不是多干了一件事，而是被卡住、同步执行，直接损失吞吐能力：

• 如果主线程是 Web 请求线程，它执行任务期间无法响应新请求，接口 P95 延迟会上升
• 如果主线程是定时任务调度线程（如 ScheduledThreadPoolExecutor 的核心线程），下一轮调度会被推迟
• 日志里会出现明显线索：原本只在 worker 线程输出的业务日志，突然出现在 main 或 http-nio-xxx 线程名下

真正起作用的是“阻塞感”，不是“多干活”

CallerRunsPolicy 的价值不在执行任务本身，而在于用阻塞让上游自然减速：

• 任务执行耗时 ≤ 200ms 是关键红线；超过这个值，调用线程卡太久，可能引发超时或连接堆积
• 任务内部不能递归提交到同一个线程池，否则形成 A→B→A 死循环，最终栈溢出或线程假死
• 若任务含远程调用，必须设好超时（如 Feign 的 connectTimeout 和 readTimeout），否则主线程可能无限等待

配置上容易忽略的协同细节

单设 CallerRunsPolicy 没用，必须整套参数配合：

• 核心线程数建议 2～4，避免空转浪费
• 最大线程数控制在 6～10，太多会削弱背压效果，上下文切换开销反而上升
• 队列长度设为 5～20，太小导致频繁降级，太大则失去缓冲预警意义
• 拒绝策略必须显式指定：new ThreadPoolExecutor.CallerRunsPolicy()，别依赖默认