摘要:那天我去面了一家很喜欢的大厂,技术氛围一流,薪资也令人心动。前两轮发挥还不错,第三轮是一位老哥来的,一开场就丢出个问题:
事情发生在上个月。
那天我去面了一家很喜欢的大厂,技术氛围一流,薪资也令人心动。前两轮发挥还不错,第三轮是一位老哥来的,一开场就丢出个问题:
“你熟悉 Java 线程池吗?那你说说 ThreadPoolExecutor 的饱和策略有哪些?”
我一愣。
线程池熟啊,日常用得不能更熟。但“饱和策略”这四个字,把我给问住了。脑袋里只冒出几个关键词:“拒绝策略”、“AbortPolicy”、“CallerRunsPolicy”,但我说得磕磕巴巴,还举不出例子。
面试官点点头:“好,继续聊其他的。”
我心里咯噔一下,知道大概凉了。
回家路上我打开 IDEA,撸了一遍 ThreadPoolExecutor 的源码,一边骂自己怎么把这么重要的一块知识点给漏了。
今天,我就来给你讲清楚这个“容易被忽视但很关键”的 Java 面试题——线程池饱和策略(RejectedExecutionhandler)。
我们都知道,Java 的线程池 ThreadPoolExecutor 是用来管理线程的工具。你提交任务,它就安排线程去执行,能复用线程、减少线程创建销毁的开销,非常高效。
但是……线程池也有上限啊!
一个线程池通常有这些配置:
当你疯狂地往线程池里提交任务,如果满足下面三个条件:
核心线程都在忙(corePoolSize都被用光);任务队列满了(queue也塞不进新任务);最大线程数也到了上限(maximumPoolSize不再增长);这时候,再有新任务进来怎么办?
是的,饱和策略就登场了!
Java 提供了四种默认的饱和策略,你也可以自定义。
ThreadPoolExecutor 中默认提供了四种实现 RejectedExecutionHandler 接口的策略,分别是:
1. AbortPolicy(默认)
策略说明:直接抛出异常
当线程池满了,再提交任务就会抛出 RejectedExecutionException 异常。
这其实是最常见的“拒绝”方式,适合不容错的系统,比如交易系统,出错宁可终止也不能乱来。
适用场景: 高可靠、任务不能丢的系统。
2. CallerRunsPolicy
策略说明:把任务交给调用者线程执行
如果线程池满了,就不让线程池处理了,而是让提交任务的线程(比如 main 线程)自己去执行这个任务。
这么做的好处是让提交任务的速度降下来,从而让线程池有时间喘息。
适用场景: 对任务处理不是特别紧急,允许降速的系统。
3. DiscardPolicy
策略说明:直接丢弃任务,不抛异常
听起来有点激进,但有些系统确实能容忍这种“最好做,做不了也无所谓”的态度。
使用时,线程池会默默地把任务丢掉,连异常都不报,简直是“佛系线程池”。
适用场景: 对任务处理精度要求不高、可丢失的日志处理、指标上报系统。
4. DiscardOldestPolicy
策略说明:丢掉队列里最老的任务,然后尝试执行当前任务
注意,它不是丢弃新任务,而是“挤走”队列最前面的任务,替换成当前这个任务。换句话说,它在一定程度上“优待了新来的”。
适用场景: 某些对实时性要求高、任务可以丢但必须处理当前任务的系统。
我们来模拟一个线程池“饱和”的现场,用 2 个线程,任务队列容量是 1,提交 4 个任务,看看策略如何运作:
你可以尝试把 CallerRunsPolicy 换成其他几种策略再跑一遍,会看到不同的执行效果!
写入日志记录被拒绝的任务;把任务持久化到消息队列;甚至可以报警提示线程池处理能力不足。你只需要把这个 handler 配到 ThreadPoolExecutor 构造函数里即可。
曾经我们系统有一个文件上传转码服务,里面使用了线程池处理上传文件。
某天突然访问量飙升,线程池被打爆,队列满、线程也满,但我们配置的是默认的 AbortPolicy,于是系统开始疯狂抛 RejectedExecutionException,还没加报警,一时之间我们完全不知道有大量文件被拒绝处理……
后来我们做了两件事:
再后来,我们封装了自己的线程池工具类,对业务线程池进行统一管理和监控。
ThreadPoolExecutor 提供了 4 种默认饱和策略,包括:
AbortPolicy:抛异常(默认);
CallerRunsPolicy:交给提交线程执行;
DiscardPolicy:直接丢弃;
DiscardOldestPolicy:丢掉最旧的任务,执行当前的。
如果业务有特殊需求,也可以自定义 RejectedExecutionHandler,比如将任务转存到MQ或落库。
实际使用时,我们会根据任务的重要性、实时性、容错性来选择合适的策略。
最好还能结合你在项目中怎么用的,说出一个场景,比如“我们系统为了防止雪崩用了CallerRunsPolicy,并在业务层做了限流”——稳稳拿捏!
线程池很强大,但你得知道它的极限在哪里。
当线程池处理不过来了,任务还在飞快地来,这时候它会“饱和”——你要知道它会怎么“拒绝”。
这就是 RejectedExecutionHandler 的职责!你可以选择抛异常、丢任务、让自己执行、甚至把最老的赶走,也可以……自定义规则。
别等出问题时才想起它——像我一样就晚了。
点个“赞”让我知道你也关注 Java 基础;转发给正在面试的朋友;关注我,小米,一个还在努力卷进大厂的31岁技术人,下期我们聊聊 线程池中的阻塞队列选型 怎么选~来源:前进教育