callerrunspolicy 通过让调用线程自行执行任务来避免任务丢失，不丢弃、不抛异常、不静默；其天然背压机制可抑制负载，但需搭配有界队列并规避长阻塞任务。

CallerRunsPolicy 能避免任务丢失，关键在于它不丢、不抛、不静默——而是把任务“交还”给提交者，让调用线程自己执行。

任务不被丢弃的执行逻辑

当线程池满载（核心线程忙 + 队列满 + 非核心线程达上限）时，CallerRunsPolicy 不走排队或创建新线程的路径，而是直接在当前调用线程中调用 r.run() 执行该任务。这意味着：

• 任务一定被执行，只是执行主体从线程池 Worker 变成了 Tomcat 请求线程、gRPC IO 线程等上游调用方
• 没有异常抛出，调用链不会因 RejectedExecutionException 中断
• 无需额外捕获或兜底代码，天然规避了“未处理异常导致静默丢失”的风险

自带背压机制，间接防止雪崩式堆积

调用线程同步执行任务，会暂时阻塞其后续请求处理能力。这种“慢下来”的效果，本身就是一种轻量级限流：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• Tomcat 线程执行下单任务耗时 300ms → 同一线程在该时段内无法接收新请求 → 提交速率自然下降
• 系统整体负载被反向抑制，为线程池恢复留出缓冲时间
• 避免无界队列+AbortPolicy组合下，OOM 或持续拒绝引发的级联失败

必须配合有界队列才真正可控

CallerRunsPolicy 单独使用并不万能。若搭配 LinkedBlockingQueue（默认无界），队列无限膨胀，内存先撑爆，根本轮不到拒绝策略生效：

• 务必选用 ArrayBlockingQueue 或 LinkedBlockingQueue(容量限制)，例如 new ArrayBlockingQueue(100)
• 队列容量建议按公式粗估：核心线程数 × 平均任务耗时（秒）× 2，再结合压测微调
• 容量过小（如设为 5）会导致频繁触发 CallerRunsPolicy，大量请求线程被拖慢，P99 响应飙升

适用边界与注意事项

它保的是“不丢”，但不保“低延迟”或“高吞吐”。实际落地需守住几条线：

• 任务本身不能是长阻塞型（如等待外部 HTTP 超时 10s），否则调用线程长时间卡死，接口不可用
• 必须配套监控：重点关注 队列使用率、CallerRunsPolicy 触发频次、P99 响应时间，发现持续高位需扩容或拆分任务
• 对超时敏感场景（如用户端 2s 超时），需前置加网关限流（Sentinel / Spring Cloud Gateway），避免调用线程被批量拖住

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