线程池拒绝策略 callerrunspolicy

线程池拒绝策略 CallerRunsPolicy：面试高频考点深入解读

大家面试被问到线程池时，基本逃不掉这个问题：“线程池任务队列满了之后，新任务来了怎么办？” 这时候，线程池拒绝策略就闪亮登场了！而 CallerRunsPolicy 绝对是其中最需要理解的一个策略。今天咱们就从程序员面试角度，掰开了揉碎了聊聊它。

在进入正题前，给需要系统复习的朋友安利个好东西：2025年Java面试宝典（包含大量并发编程实战解析）： <font color='blue'>链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g</font>

线程池拒绝策略是啥？为啥要有拒绝策略？

想象一下线程池是个小餐馆：

核心线程数：固定服务员
最大线程数：忙时可以请的临时工
任务队列：候餐区椅子

当候餐区椅子（队列）都坐满了，新客人（任务）源源不断进来怎么办？餐馆总不能无限加椅子（内存爆掉）或者让客人无限等（饿死）吧？这时就需要拒绝策略来“婉拒”客人了。这就是线程池拒绝策略存在的核心意义——保护系统资源不被耗尽。

拒绝策略 CallerRunsPolicy 的独特之处

Java线程池内置了4种拒绝策略，CallerRunsPolicy（调用者运行策略）是其中一个比较有意思的：

其他策略：直接抛异常（AbortPolicy）、默默丢弃（DiscardPolicy）、丢弃最老任务（DiscardOldestPolicy）。
CallerRunsPolicy 策略：当线程池队列满了且线程数达到最大值时，对于新提交的任务，线程池不会直接拒绝它，而是让提交这个任务的线程（调用者线程）自己去执行这个任务！

面试鸭返利网 (图示：线程池工作流程，拒绝策略是最后一环)

CallerRunsPolicy 怎么工作？用场景说话

假设你写了一个Web应用，用线程池处理用户请求。线程池配置：核心线程数5，最大线程数10，队列容量100。

正常情况：请求到来 -> 核心线程处理 -> 核心线程忙 -> 请求进队列 -> 队列快满 -> 创建临时线程(最多到10个) -> 处理队列任务。
高峰期（队列满+线程数达最大）：又来一个新请求。
- 如果策略是 AbortPolicy：直接抛出 RejectedExecutionException，用户可能看到500错误。
- 如果策略是 CallerRunsPolicy：这时，处理这个新请求的就不是线程池的线程了，而是当初提交这个任务的那个线程（比如处理HTTP请求的Tomcat工作线程）！ Tomcat线程自己撸起袖子去执行这个本该由线程池处理的任务。

选择 CallerRunsPolicy 策略的利与弊

优点（为啥要用它）：

避免崩溃/拒绝：这是最直观的。它不会像 AbortPolicy 那样直接抛异常导致请求失败，给系统一个“缓冲”的机会。用户体验相对好点。
天然的后退机制：让调用者自己执行任务，相当于降低了任务提交的速度。因为提交任务的线程（如Tomcat线程）现在被占用了，它就没办法马上去提交下一个新任务。这有助于缓解系统整体的压力，是一种自适应限流。
保证任务不丢失：任务最终会被执行，不会被丢弃（除非调用者线程挂了）。

缺点（用之前要想清楚）：

可能阻塞调用者：如果任务很耗时，调用者线程（如Tomcat线程）会被长时间占用。这会严重影响调用者线程的正常工作！ 在Web应用中，意味着处理HTTP请求的线程变少，整体吞吐量反而可能下降。
延迟可能更高：调用者线程本身可能有其他职责，让它去执行任务，该任务的执行时机可能被延迟（等调用者线程忙完手头的事）。
可能引发连锁反应：如果调用者线程本身依赖其他资源（如数据库连接池），当大量调用者线程被卡在执行任务上，可能导致这些资源也被耗尽。

面试官问：什么时候该用 CallerRunsPolicy 策略？

在面试中问到线程池拒绝策略选型，特别是问到 CallerRunsPolicy 策略，你可以这样答：

“CallerRunsPolicy 线程池拒绝策略适合那些对任务执行延迟有一定容忍度，且绝对不能丢弃任务的场景。它相当于用调用者线程的资源来兜底，实现一种后退机制。比如一些后台异步日志记录、非核心但需要保证完成的统计任务等。但必须非常小心！ 要评估好任务执行时间，以及阻塞调用者线程对整个系统的影响，避免因小失大。在Web应用这种对响应时间敏感的场合，通常慎用，更倾向于配合队列监控和告警，或者使用 AbortPolicy 快速失败，让上层有重试机制。”