线程池拒绝策略有几种

线程池拒绝策略有几种？面试必考点解析！

大家好！今天咱们来聊聊面试里贼爱考的一个点：线程池拒绝策略。这玩意儿平时写代码可能不太关注，但面试官贼喜欢问，因为它能考察你对线程池运行机制的理解深度。搞懂它，面试就能稳稳拿分！

线程池拒绝策略，说白了就是当你的线程池实在“扛不住”新任务时，该怎么处理这些“被拒之门外的可怜任务”。Java标准库ThreadPoolExecutor给我们提供了4种内置的拒绝策略。下面一个个拆开讲：

---

1. AbortPolicy：直接拒绝，抛异常！（默认策略）

• 工作方式： 当任务被拒绝时，二话不说，直接给你甩一个RejectedExecutionException异常！
• 适用场景： 适用于需要明确感知任务失败的场景。你觉得任务被拒绝是个严重问题，需要上层逻辑立即捕获并处理这个异常，比如发告警、记录日志、尝试其他补偿手段等。
• 面试怎么说： “默认策略是AbortPolicy。这个策略比较干脆，线程池满员+队列满员时，新任务提交就直接抛RejectedExecutionException。它的好处是能让调用方第一时间知道任务提交失败了，便于做异常处理和兜底方案。坏处嘛，如果上层没处理好，异常可能导致程序中断。”

关键词覆盖： 线程池拒绝策略、线程池拒绝策略、拒绝策略、线程池拒绝策略、任务被拒绝

---

2. CallerRunsPolicy：调用者自己干！

• 工作方式： 如果线程池已经饱和（核心线程、最大线程、队列都满了），那么新任务不会进池子，也不会被立即丢弃。而是让提交这个任务的线程自己去执行这个任务！相当于“谁发起的任务，谁自己干”。
• 适用场景： 适用于不希望丢失任务，并且提交任务的线程本身可以承受额外任务执行时间的情况。它提供了一种简单的“反压”机制，能有效降低新任务的提交速度（因为提交任务的线程被用来执行任务了，自然就慢下来了）。
• 面试怎么说： “第二种策略是CallerRunsPolicy。这个策略挺有意思，当线程池饱和了，它不拒绝任务，而是让提交任务的线程亲自下场去执行这个任务！相当于主线程或者任务提交线程临时充当了工作线程。这样保证了任务不会丢失，同时也是一种简单的流量控制，因为提交任务的线程忙于执行任务，自然就减缓了后续任务提交的速度。需要注意执行任务的线程可能不是线程池的线程，可能影响提交线程的响应速度。”

关键词覆盖： 线程池拒绝策略、线程池拒绝策略、拒绝策略、线程池拒绝策略、任务被拒绝

---

3. DiscardPolicy：默默丢弃，当无事发生

• 工作方式： 这是最“佛系”的策略。线程池饱和了？新任务来了？直接丢掉！没有任何通知，没有任何异常抛出，仿佛这个任务从来没有提交过一样。
• 适用场景： 适用于那些不重要的任务，丢了就丢了，对系统整体逻辑没影响。或者是一些心跳、日志之类的可丢弃任务。需要谨慎使用，因为任务悄无声息地丢失了，排查问题会很困难。
• 面试怎么说： “第三种是DiscardPolicy。这个策略最简单也最‘无情’，任务被拒绝时，它啥也不干，直接悄无声息地把这个新任务给丢弃了！既不抛异常，也不做任何记录。这种策略风险很大，任务丢了都不知道，很难定位问题。所以只适合处理一些无足轻重、丢失了也无所谓的任务，比如一些非关键性的监控信息上报。”

关键词覆盖： 线程池拒绝策略、线程池拒绝策略、拒绝策略、线程池拒绝策略、任务被拒绝

---

4. DiscardOldestPolicy：丢掉最老的，腾位置给新的

• 工作方式： 当线程池饱和时，它会尝试做出一个“牺牲”。它会把任务队列中等待时间最长的那个任务（队列头部的任务）给丢掉，然后再尝试把新提交的任务放入队列尾部。
• 适用场景： 适用于可以容忍丢失部分历史老任务，但希望尽量执行最新任务的场景。有点像消息队列的某些策略。但同样存在任务丢失的问题。
• 面试怎么说： “最后一种是DiscardOldestPolicy。这个策略会优先保证新任务有‘插队’的机会。线程池饱和时，它会先尝试把任务队列里排队最久的那个任务（也就是最早入队的任务）扔掉，腾出空间，然后再把新提交的任务放进队列尾部。它适用于那些新任务比老任务更重要的场景。不过缺点也很明显：老任务被无缘无故丢弃了，而且依然存在任务丢失的风险，只是丢的是旧任务而已。”

关键词覆盖： 线程池拒绝策略、线程池拒绝策略、拒绝策略、线程池拒绝策略、任务被拒绝、任务队列

---

实战场景与选择

面试官可能会问：“比如一个高并发秒杀接口，你用线程池处理下单请求，你会选哪种拒绝策略？”

• 关键点： 核心是保流量 or 保数据完整性？
  • AbortPolicy： 前端可以明确感知失败（返回“系统繁忙”），引导用户重试。确保未处理的请求不被积压太多导致雪崩。配合限流熔断。
  • CallerRunsPolicy： 能保证每个提交的请求最终都被处理（即使慢一点），不会丢失订单请求。但可能拖垮调用线程（如Tomcat工作线程），导致整体服务不可用。
  • DiscardPolicy/DiscardOldestPolicy： 用户点了下单，后端默默丢弃了请求，用户却不知道！订单丢失！这是灾难性的选择！

通常推荐方案： 结合AbortPolicy（快速失败） + 外层限流（如Guava RateLimiter, Sentinel） + 友好的前端提示（“当前排队人数过多，请稍后再试”）。或者使用有界队列配合合适的队列大小和最大线程数，尽量避免触发拒绝策略。

📌 2025年Java面试宝典重磅福利！
备战面试怎能没有宝典？立即获取这份超全资料：
🔗 点击下载：2025年Java面试宝典
提取码: 9b3g

---

最后的小贴士：省钱通道！

搞懂这些线程池拒绝策略，面试绝对加分！如果你正在准备面试，需要更系统、更深入的学习资料（比如面试题汇总、详解），推荐看看 面试鸭 的会员服务。题库更新快，解析透彻。

对了，悄悄告诉你个省钱秘诀： 如果需要购买面试鸭会员，可以通过 面试鸭返利网 找到我下单，可以享受 25元返利 哦！能省一点是一点，把预算花在刀刃上！直达链接：mianshiyafanli.com

理解线程池的运行机制，特别是拒绝策略，对写出健壮、高性能的并发程序至关重要，也是面试中展示你技术深度的好机会。祝你面试顺利，拿下心仪Offer！