线程池拒绝策略报错

兄弟们，最近是不是在面试Java岗的时候经常被问到线程池？尤其是那个经典的“线程池满了之后会怎么处理”？这就是我们今天要深入聊聊的线程池拒绝策略报错问题。搞懂它，面试官都得高看你一眼！

开头先给大家谋个福利！2025年Java面试宝典（含最新面试题及高频考点解析）：点这里速存！提取码：9b3g（建议立刻保存，防止失效）这可是备战金三银四的核武器！

面试鸭返利网

简单说，当你的线程池任务队列满了，并且所有工作线程都在忙，这时候再往线程池里submit新任务，就会触发线程池拒绝策略报错！这本质上是一种保护机制，防止无限制的任务堆积压垮系统。

面试官问你这个问题，绝对不是想听一句“会抛异常”，而是要考察你是否理解线程池的运作原理和资源管理意识。

碰到线程池拒绝策略报错，线程池提供了四种“拒单”方式，直接决定了报错长啥样：

AbortPolicy（直接掀桌）：
- 最常用！直接抛出RejectedExecutionException。
- 面试高频！ 面试官最爱问：“默认策略是啥？会抛什么异常？” 答不上来？凉一半！
- 适用场景：需要明确感知任务被拒绝，方便上层做降级处理。
- 报错信息直白：Task java.util.concurrent.FutureTask@xxxx rejected from java.util.concurrent.ThreadPoolExecutor@xxxx [Running, pool size = x, active threads = x, queued tasks = x, completed tasks = x]
CallerRunsPolicy（让老板自己干）：
- 不抛异常！把新任务退回给调用者线程（比如主线程）去执行。
- 面试坑点：很多同学误以为线程池自己会处理，其实“谁提交谁干活”。
- 适用场景：不想丢任务，能接受主线程/调用线程变慢（同步阻塞）。
DiscardPolicy（假装没看见）：
- 静默丢弃新任务，不抛异常也不执行。悄无声息！
- 风险最大！极易导致数据丢失或业务逻辑缺失，慎用！
- 面试官会追问：“什么场景敢用它？” 答不好容易翻车。
DiscardOldestPolicy（扔旧迎新）：
- 丢弃队列中最老（队头）的一个任务，然后尝试把新任务加入队列。
- 面试加分点：需要理解队列结构（FIFO），知道扔的是队头的“老人”。
- 风险：可能会丢失重要的老任务。适用于允许牺牲部分旧数据的场景（如实时性要求高）。

被问到“线程池满了怎么办”，别慌！结构化输出，展示你的深度：

先点明核心： “当核心线程满、任务队列满、最大线程也满时，再提交任务就会触发线程池拒绝策略报错，具体行为由RejectedExecutionHandler决定。”
掰扯四大金刚： 按上面说的，清晰解释4种策略的行为和区别。重点强调默认是AbortPolicy抛RejectedExecutionException！
场景化选型（加分项！）：
- “比如订单系统，下单失败必须明确通知用户，用AbortPolicy然后捕获异常降级最合适。”
- “日志收集系统，允许少量丢失，可能用DiscardPolicy或DiscardOldestPolicy保吞吐量。”
- “后台计算任务，不想丢数据且能接受调用变慢，可以用CallerRunsPolicy。”
结合实际报错： “线上最常见的就是AbortPolicy抛出的异常堆栈，一看日志就能定位是线程池过载了。”
延伸治理方案：
- 监控报警：线程池活跃度、队列大小。
- 动态调参：根据监控自动调整核心/最大线程数、队列容量（需要框架支持）。
- 业务降级：捕获RejectedExecutionException后降级处理（返回兜底值、记录任务稍后重试）。