callerrunspolicy在线程池饱和时由调用execute()的线程同步执行任务，实现反压控制；需搭配有界队列，适用于延迟敏感但可接受减速的场景，如异步发消息、定时批量处理等。
当线程池饱和（队列满 + 所有核心/最大线程都在忙）时，CallerRunsPolicy 会让任务在**调用 execute() 的线程中直接执行**——这不是“丢弃”，而是把压力暂时“还给上游”，让调用方线程自己跑这个任务，从而自然降低提交速率，起到反压（backpressure）效果。
CallerRunsPolicy 的核心机制
它不抛异常、不丢任务、也不新建线程，而是：
- 在
execute()方法被调用的线程（比如主线程、Web 请求线程、定时任务线程等）中，同步执行该任务的run()方法； - 执行完才返回，调用方线程被占用，无法立即提交下一个任务；
- 相当于给上游“踩了一脚刹车”：提交越快，自己卡得越久，客观上迫使上游放慢节奏。
如何配置 CallerRunsPolicy
创建线程池时，显式传入该策略即可：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // corePoolSize
4, // maxPoolSize
60L, // keepAliveTime
TimeUnit.SECONDS,
new ArrayBlockingQueue(5), // 容量有限的队列
new ThreadPoolExecutor.CallerRunsPolicy() // 关键：启用反压
);
注意：必须搭配**有界队列**（如 ArrayBlockingQueue）才有意义。若用无界队列（如 LinkedBlockingQueue），队列永远不会满，拒绝策略永远不触发。
典型适用场景与效果
适合对延迟敏感、但能容忍“慢一点”的业务，例如：
- Web 接口接收请求后异步发消息（如发 MQ、写日志），希望避免突发流量打垮下游；
- 定时任务批量处理数据，但不想因堆积过多任务导致 OOM 或雪崩；
- 上游是单线程或线程数受限（如 Netty EventLoop、Swing EDT），天然具备节流能力。
效果示例：假设每秒提交 100 个任务，但线程池实际吞吐仅 30/s，使用 CallerRunsPolicy 后，超出部分会在调用线程中执行 → 调用线程越来越忙 → 提交频率自动下降 → 最终趋于系统可承载的速率。
注意事项与常见误区
使用时需清醒认识其行为边界：
- 不是兜底保障：如果调用方本身就是关键路径（如 HTTP 请求线程），让它阻塞执行任务会导致接口超时，需权衡是否接受延迟上升；
- 不解决根本瓶颈：它只是缓解提交压力，不能替代扩容、异步拆分、降级等长期优化；
-
日志和监控要跟上：建议包装
execute()，记录被 CallerRuns 执行的任务数量，用于判断是否频繁触发反压； - 慎用于 ForkJoinPool 或自定义线程上下文环境：调用线程可能缺少所需上下文（如 Spring 的 RequestScope、MDC 日志上下文），需手动传递。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
