callerrunspolicy是threadpoolexecutor的拒绝策略之一，触发条件为线程数达maximumpoolsize、有界队列已满且线程池处于running状态；它让调用线程同步执行被拒任务，实现反压限流，不丢任务也不抛异常。
ThreadPoolExecutor 的 CallerRunsPolicy 不是“饱和策略”，而是一种**拒绝策略**，它在真正饱和（即线程池无法接纳新任务）时才被触发。它的作用不是避免饱和，而是让系统在饱和后仍能可控运行——通过把压力“还给”调用方，实现自然限流与反压。
CallerRunsPolicy 触发的真实条件
它只在三个条件同时满足时生效：
- 当前活跃线程数已达 maximumPoolSize
- 工作队列（如 LinkedBlockingQueue、ArrayBlockingQueue）已满（仅对有界队列有效）
- 线程池状态为 RUNNING（非 shutdown 或 stop 状态）
此时，新提交的任务无法入队、无法创建新线程、也无法被已有线程立即处理，于是交由 RejectedExecutionHandler 处理——CallerRunsPolicy 就是其中一种实现。
它怎么“减压”：核心是同步执行 + 阻塞调用线程
该策略不丢任务、不抛异常、也不新建线程，而是让提交任务的那个线程（比如 Tomcat 的一个 worker 线程、或你主线程中的某个线程）直接同步执行这个 Runnable。效果是：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 调用线程被占用，无法立刻提交下一个任务 → 后续任务提交速率自动下降
- 跳过排队和调度开销，但代价是调用线程暂时“卡住”
- 对上游形成负反馈：越忙，提交越慢；越慢，下游压力越小
例如：Web 请求线程池满载，第 101 个请求到来时触发 CallerRunsPolicy，Tomcat 的这个请求线程就自己执行业务逻辑（比如查数据库），执行完才返回响应——这等于变相拉长了 RT，但保住了任务不丢失。
适用场景与配置要点
它适合不能丢任务、可接受延迟上升、且调用方具备一定弹性的系统，比如内部服务调用、后台批处理、非强实时风控等。
- 务必搭配有界队列（如
new ArrayBlockingQueue(200)），无界队列（如默认的LinkedBlockingQueue）几乎不会触发拒绝策略 - 设置合理的
corePoolSize和maximumPoolSize，避免线程数无节制增长 - 使用方式：
new ThreadPoolExecutor(..., new ThreadPoolExecutor.CallerRunsPolicy()) - 注意：若调用线程本身是关键路径（如 UI 线程或 Netty EventLoop），自行执行可能引发阻塞问题，需谨慎评估
它不是万能解药：要配合监控与容量规划
CallerRunsPolicy 是兜底机制，不是性能优化手段。长期高频触发说明线程池配置不合理或系统已超负荷。应结合以下动作：
- 记录拒绝日志（可包装 Handler 添加打印或上报）
- 监控
getCompletedTaskCount()、getQueue().size()、拒绝次数等指标 - 压测验证最大吞吐，预留 20%~30% 余量
- 必要时升级为熔断（如切换为 AbortPolicy + Sentinel）或异步降级（如写入 Kafka 重试）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
