<font color="blue">2025年Java面试宝典最新版已更新！</font>

网盘地址：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g

---

Java线程池拒绝策略：面试必问的核心考点

在Java多线程面试中，线程池的拒绝策略几乎是必问的题目。很多同学在回答时能说出四种策略的名称，但一旦被问到**"实际项目中如何选择？为什么用这种策略？遇到过哪些坑？"**，就容易卡壳。今天我们从面试实战的角度，深入剖析线程池拒绝策略的底层逻辑和应用场景。

---

为什么需要拒绝策略？

Java线程池通过ThreadPoolExecutor实现，当任务提交速度超过处理能力时，就会触发拒绝策略。面试官问这个问题，其实是想考察：

1. 你是否理解线程池的资源管理机制
2. 你是否有过高并发场景的实战经验
3. 你对系统稳定性设计的思考深度

举个例子：假设核心线程数是5，最大线程数10，队列容量100。当同时涌入200个任务时，队列满了且线程数达到最大值，剩下的90个任务就会触发拒绝策略。这时如何处理这些"超载任务"，直接关系到系统的健壮性。

---

四种拒绝策略的底层逻辑

1. AbortPolicy（默认策略）

直接抛出RejectedExecutionException异常，强制开发者处理任务堆积问题。适合对稳定性要求高的场景，比如支付系统。如果放任任务堆积，可能导致内存溢出，但粗暴拒绝也可能引发数据丢失，需要配合降级策略（比如记录日志、异步重试）。

2. CallerRunsPolicy

让提交任务的线程自己执行任务。比如主线程提交任务被拒绝后，主线程会转而执行这个任务。这种策略的巧妙之处在于天然限流——当线程池满载时，提交任务的速度会因为主线程被占用而自然降低。适合不允许任务丢失但可以接受延迟的场景，比如订单系统的库存扣减。

3. DiscardPolicy

直接静默丢弃任务，没有任何通知。这种策略风险极高，除非业务场景允许数据丢失（比如实时日志采集），否则不建议使用。曾经有团队在用户行为统计系统中使用该策略，结果因为流量突增导致30%的数据丢失，后来改用DiscardOldestPolicy才缓解问题。

4. DiscardOldestPolicy

丢弃队列中最老的任务，然后尝试重新提交新任务。这种策略适合时效性敏感的场景，比如实时竞价系统，宁可丢弃过期的出价请求，也要保证最新报价能进入队列。但需要警惕队列中可能存在的重要任务被意外丢弃。

---

面试回答技巧

当被问到"你们项目用哪种拒绝策略"，可以这样回答：

"我们电商系统用的是CallerRunsPolicy。因为在促销活动时，瞬时流量可能是平时的100倍，用这种策略既能保证核心交易链路不崩溃，又能通过主线程限流保护数据库。不过我们在外层做了熔断机制，如果线程池负载持续超过80%，会触发报警并降级非核心功能。"

如果遇到开放性问题"如果让你设计一个自定义拒绝策略"，可以结合具体场景：

"比如在IM消息推送系统，我会把被拒绝的任务存入Redis队列，启动一个补偿线程定时重试。同时记录消息ID，防止重复推送。"

---

如何避免策略选择失误？

1. 监控线程池状态：通过ThreadPoolExecutor#getQueue().size()监控队列堆积
2. 动态调整参数：结合Apollo等配置中心实时修改核心线程数
3. 设置拒绝阈值：比如连续拒绝100个任务后触发服务降级

---

最后的小提醒

如果大家需要购买面试鸭会员，可以通过面试鸭返利网找我，返利25元。用省下来的钱买杯咖啡，继续刷题备战金九银十吧！