1. 首页
  2. IT资讯

Java 线程池 8 大拒绝策略,面试必问

“u003Cpu003E技术博文,及时送达u003Cu002Fpu003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002FReU3KFWHGbeY5a” img_width=”535″ img_height=”10″ alt=”Java 线程池 8 大拒绝策略,面试必问” inline=”0″u003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003E前言u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E谈到java的线程池最熟悉的莫过于ExecutorService接口了,jdk1.5新增的java.util.concurrent包下的这个api,u003Ci class=”chrome-extension-mutihighlight chrome-extension-mutihighlight-style-1″u003E大大u003Cu002Fiu003E的简化了多线程代码的开发。而不论你用FixedThreadPool还是CachedThreadPool其背后实现都是ThreadPoolExecutor。u003Cu002Fpu003Eu003Cp class=””u003EThreadPoolExecutor是一个典型的缓存池化设计的产物,因为池子有大小,当池子体积不够承载时,就涉及到拒绝策略。JDK中已经预设了4种线程池拒绝策略,下面结合场景详细聊聊这些策略的使用场景,以及我们还能扩展哪些拒绝策略。u003Cu002Fpu003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003E池化设计思想u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E池话设计应该不是一个新名词。我们常见的如java线程池、jdbc连接池、redis连接池等就是这类设计的代表实现。u003Cu002Fpu003Eu003Cpu003E这种设计会初始预设资源,解决的问题就是抵消每次获取资源的消耗,如创建线程的开销,获取远程连接的开销等。就好比你去食堂打饭,打饭的大妈会先把饭盛好几份放那里,你来了就直接拿着饭盒加菜即可,不用再临时又盛饭又打菜,效率就高了。u003Cu002Fpu003Eu003Cpu003E除了初始化资源,池化设计还包括如下这些特征:池子的初始值、池子的活跃值、池子的最大值等,这些特征可以直接映射到java线程池和数据库连接池的成员属性中。u003Cu002Fpu003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003E线程池触发拒绝策略的时机u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E和数据源连接池不一样,线程池除了初始大小和池子最大值,还多了一个阻塞队列来缓冲。u003Cu002Fpu003Eu003Cpu003E数据源连接池一般请求的连接数超过连接池的最大值的时候就会触发拒绝策略,策略一般是阻塞等待设置的时间或者直接抛异常。u003Cu002Fpu003Eu003Cpu003E而线程池的触发时机如下图:u003Cu002Fpu003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002FRefkBG64GAQLsj” img_width=”680″ img_height=”203″ alt=”Java 线程池 8 大拒绝策略,面试必问” inline=”0″u003Eu003Cpu003E如图,想要了解线程池什么时候触发拒绝粗略,需要明确上面三个参数的具体含义,是这三个参数总体协调的结果,而不是简单的超过最大线程数就会触发线程拒绝粗略,当提交的任务数大于corePoolSize时,会优先放到队列缓冲区,只有填满了缓冲区后,才会判断当前运行的任务是否大于maxPoolSize,小于时会新建线程处理。大于时就触发了拒绝策略,总结就是:当前提交任务数大于(maxPoolSize + queueCapacity)时就会触发线程池的拒绝策略了。u003Cu002Fpu003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003EJDK内置4种线程池拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E拒绝策略接口定义u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E在分析JDK自带的线程池拒绝策略前,先看下JDK定义的 拒绝策略接口,如下:u003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic interface RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Ccodeu003E void rejectedExecution(Runnable r, ThreadPoolExecutor executor);u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003E接口定义很明确,当触发拒绝策略时,线程池会调用你设置的具体的策略,将当前提交的任务以及线程池实例本身传递给你处理,具体作何处理,不同场景会有不同的考虑,下面看JDK为我们内置了哪些实现:u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003ECallerRunsPolicy(调用者运行策略)u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic static class CallerRunsPolicy implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public CallerRunsPolicy { }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {u003Cu002Fcodeu003Eu003Ccodeu003E if (!e.isShutdown) {u003Cu002Fcodeu003Eu003Ccodeu003E r.run;u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E功能u003Cu002Fstrongu003E:当触发拒绝策略时,只要线程池没有关闭,就由提交任务的当前线程处理。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E使用场景u003Cu002Fstrongu003E:一般在不允许失败的、对性能要求不高、并发量较小的场景下使用,因为线程池一般情况下不会关闭,也就是提交的任务一定会被运行,但是由于是调用者线程自己执行的,当多次提交任务时,就会阻塞后续任务执行,性能和效率自然就慢了。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003EAbortPolicy(中止策略)u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic static class AbortPolicy implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public AbortPolicy { }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {u003Cu002Fcodeu003Eu003Ccodeu003E throw new RejectedExecutionException(“Task ” + r.toString +u003Cu002Fcodeu003Eu003Ccodeu003E ” rejected from ” +u003Cu002Fcodeu003Eu003Ccodeu003E e.toString);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E功能:u003Cu002Fstrongu003E当触发拒绝策略时,直接抛出拒绝执行的异常,中止策略的意思也就是打断当前执行流程u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E使用场景:u003Cu002Fstrongu003E这个就没有特殊的场景了,但是一点要正确处理抛出的异常。u003Cu002Fpu003Eu003Cpu003EThreadPoolExecutor中默认的策略就是AbortPolicy,ExecutorService接口的系列ThreadPoolExecutor因为都没有显示的设置拒绝策略,所以默认的都是这个。但是请注意,ExecutorService中的线程池实例队列都是无界的,也就是说把内存撑爆了都不会触发拒绝策略。当自己自定义线程池实例时,使用这个策略一定要处理好触发策略时抛的异常,因为他会打断当前的执行流程。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003EDiscardPolicy(丢弃策略)u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic static class DiscardPolicy implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public DiscardPolicy { }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E功能:u003Cu002Fstrongu003E直接静悄悄的丢弃这个任务,不触发任何动作u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E使用场景:u003Cu002Fstrongu003E如果你提交的任务无关紧要,你就可以使用它 。因为它就是个空实现,会悄无声息的吞噬你的的任务。所以这个策略基本上不用了u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003EDiscardOldestPolicy(弃老策略)u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic static class DiscardOldestPolicy implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public DiscardOldestPolicy { }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {u003Cu002Fcodeu003Eu003Ccodeu003E if (!e.isShutdown) {u003Cu002Fcodeu003Eu003Ccodeu003E e.getQueue.poll;u003Cu002Fcodeu003Eu003Ccodeu003E e.execute(r);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E功能:u003Cu002Fstrongu003E如果线程池未关闭,就弹出队列头部的元素,然后尝试执行u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E使用场景:u003Cu002Fstrongu003E这个策略还是会丢弃任务,丢弃时也是毫无声息,但是特点是丢弃的是老的未执行的任务,而且是待执行优先级较高的任务。基于这个特性,我能想到的场景就是,发布消息,和修改消息,当消息发布出去后,还未执行,此时更新的消息又来了,这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。因为队列中还有可能存在消息版本更低的消息会排队执行,所以在真正处理消息的时候一定要做好消息的版本比较。u003Cu002Fpu003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003E第三方实现的拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Edubbo中的线程拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic class AbortPolicyWithReport extends ThreadPoolExecutor.AbortPolicy {u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E protected static final Logger logger = LoggerFactory.getLogger(AbortPolicyWithReport.class);u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private final String threadName;u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private final URL url;u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private static volatile long lastPrintTime = 0;u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private static Semaphore guard = new Semaphore(1);u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public AbortPolicyWithReport(String threadName, URL url) {u003Cu002Fcodeu003Eu003Ccodeu003E this.threadName = threadName;u003Cu002Fcodeu003Eu003Ccodeu003E this.url = url;u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E @Overrideu003Cu002Fcodeu003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {u003Cu002Fcodeu003Eu003Ccodeu003E String msg = String.format(“Thread pool is EXHAUSTED!” +u003Cu002Fcodeu003Eu003Ccodeu003E ” Thread Name: %s, Pool Size: %d (active: %d, core: %d, max: %d, largest: %d), Task: %d (completed: %d),” +u003Cu002Fcodeu003Eu003Ccodeu003E ” Executor status:(isShutdown:%s, isTerminated:%s, isTerminating:%s), in %s:u002Fu002F%s:%d!”,u003Cu002Fcodeu003Eu003Ccodeu003E threadName, e.getPoolSize, e.getActiveCount, e.getCorePoolSize, e.getMau003Ci class=”chrome-extension-mutihighlight chrome-extension-mutihighlight-style-2″u003Exiu003Cu002Fiu003EmumPoolSize, e.getLargestPoolSize,u003Cu002Fcodeu003Eu003Ccodeu003E e.getTaskCount, e.getCompletedTaskCount, e.isShutdown, e.isTerminated, e.isTerminating,u003Cu002Fcodeu003Eu003Ccodeu003E url.getProtocol, url.getIp, url.getPort);u003Cu002Fcodeu003Eu003Ccodeu003E logger.warn(msg);u003Cu002Fcodeu003Eu003Ccodeu003E dumpJStack;u003Cu002Fcodeu003Eu003Ccodeu003E throw new RejectedExecutionException(msg);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private void dumpJStack {u003Cu002Fcodeu003Eu003Ccodeu003E u002Fu002F省略实现u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003E可以看到,当dubbo的工作线程触发了线程拒绝后,主要做了三个事情,原则就是尽量让使用者清楚触发线程拒绝策略的真实原因。u003Cu002Fpu003Eu003Cpu003E1)输出了一条警告级别的日志,日志内容为线程池的详细设置参数,以及线程池当前的状态,还有当前拒绝任务的一些详细信息。可以说,这条日志,使用dubbo的有过生产运维经验的或多或少是见过的,这个日志简直就是日志打印的典范,其他的日志打印的典范还有spring。得益于这么详细的日志,可以很容易定位到问题所在u003Cu002Fpu003Eu003Cpu003E2)输出当前线程堆栈详情,这个太有用了,当你通过上面的日志信息还不能定位问题时,案发现场的dump线程上下文信息就是你发现问题的救命稻草。u003Cu002Fpu003Eu003Cpu003E3)继续抛出拒绝执行异常,使本次任务失败,这个继承了JDK默认拒绝策略的特性u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003ENetty中的线程池拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Eprivate static final class NewThreadRunsPolicy implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Ccodeu003E NewThreadRunsPolicy {u003Cu002Fcodeu003Eu003Ccodeu003E super;u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {u003Cu002Fcodeu003Eu003Ccodeu003E try {u003Cu002Fcodeu003Eu003Ccodeu003E final Thread t = new Thread(r, “Temporary task executor”);u003Cu002Fcodeu003Eu003Ccodeu003E t.start;u003Cu002Fcodeu003Eu003Ccodeu003E } catch (Throwable e) {u003Cu002Fcodeu003Eu003Ccodeu003E throw new RejectedExecutionException(u003Cu002Fcodeu003Eu003Ccodeu003E “Failed to start a new thread”, e);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003ENetty中的实现很像JDK中的CallerRunsPolicy,舍不得丢弃任务。不同的是,CallerRunsPolicy是直接在调用者线程执行的任务。而 Netty是新建了一个线程来处理的。u003Cu002Fpu003Eu003Cpu003E所以,Netty的实现相较于调用者执行策略的使用面就可以扩展到支持高效率高性能的场景了。但是也要注意一点,Netty的实现里,在创建线程时未做任何的判断约束,也就是说只要系统还有资源就会创建新的线程来处理,直到new不出新的线程了,才会抛创建线程失败的异常u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003EactiveMq中的线程池拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Enew RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Ccodeu003E @Overrideu003Cu002Fcodeu003Eu003Ccodeu003E public void rejectedExecution(final Runnable r, final ThreadPoolExecutor executor) {u003Cu002Fcodeu003Eu003Ccodeu003E try {u003Cu002Fcodeu003Eu003Ccodeu003E executor.getQueue.offer(r, 60, TimeUnit.SECONDS);u003Cu002Fcodeu003Eu003Ccodeu003E } catch (InterruptedException e) {u003Cu002Fcodeu003Eu003Ccodeu003E throw new RejectedExecutionException(“Interrupted waiting for BrokerService.worker”);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E throw new RejectedExecutionException(“Timed Out while attempting to enqueue Task.”);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E });u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003EactiveMq中的策略属于最大努力执行任务型,当触发拒绝策略时,在尝试一分钟的时间重新将任务塞进任务队列,当一分钟超时还没成功时,就抛出异常u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003Epinpoint中的线程池拒绝策略u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003Eu003Ccodeu003Epublic class RejectedExecutionHandlerChain implements RejectedExecutionHandler {u003Cu002Fcodeu003Eu003Ccodeu003E private final RejectedExecutionHandler handlerChain;u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E public static RejectedExecutionHandler build(List<RejectedExecutionHandler> chain) {u003Cu002Fcodeu003Eu003Ccodeu003E Objects.requireNon(chain, “handlerChain must not be “);u003Cu002Fcodeu003Eu003Ccodeu003E RejectedExecutionHandler handlerChain = chain.toArray(new RejectedExecutionHandler[0]);u003Cu002Fcodeu003Eu003Ccodeu003E return new RejectedExecutionHandlerChain(handlerChain);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E private RejectedExecutionHandlerChain(RejectedExecutionHandler[] handlerChain) {u003Cu002Fcodeu003Eu003Ccodeu003E this.handlerChain = Objects.requireNon(handlerChain, “handlerChain must not be “);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Cbru003Eu003Ccodeu003E @Overrideu003Cu002Fcodeu003Eu003Ccodeu003E public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {u003Cu002Fcodeu003Eu003Ccodeu003E for (RejectedExecutionHandler rejectedExecutionHandler : handlerChain) {u003Cu002Fcodeu003Eu003Ccodeu003E rejectedExecutionHandler.rejectedExecution(r, executor);u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E }u003Cu002Fcodeu003Eu003Ccodeu003E}u003Cu002Fcodeu003Eu003Cu002Fpreu003Eu003Cpu003Epinpoint的拒绝策略实现很有特点,和其他的实现都不同。他定义了一个拒绝策略链,包装了一个拒绝策略列表,当触发拒绝策略时,会将策略链中的rejectedExecution依次执行一遍。u003Cu002Fpu003Eu003Cpu003Eu003Cstrong toutiao-origin=”strong” class=”highlight-text”u003E结语u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E前文从线程池设计思想,以及线程池触发拒绝策略的时机引出java线程池拒绝策略接口的定义。并辅以JDK内置4种以及四个第三方开源软件的拒绝策略定义描述了线程池拒绝策略实现的各种思路和使用场景。u003Cu002Fpu003Eu003Cpu003E希望阅读此文后能让你对java线程池拒绝策略有更加深刻的认识,能够根据不同的使用场景更加灵活的应用。u003Cu002Fpu003Eu003Cpu003E转自:KL博客u003Cu002Fpu003Eu003Cblockquote toutiao-origin=”span”u003E地址:u003Ci class=”chrome-extension-mutihighlight chrome-extension-mutihighlight-style-3″u003Ewwwu003Cu002Fiu003E.kailing.pubu002Farticleu002Findexu002Farcidu002F255.htmlu003Cu002Fblockquoteu003Eu003Cp class=”pgc-end-source”u003E编辑:Java技术栈(id:javastack)u003Cu002Fpu003E”

原文始发于:Java 线程池 8 大拒绝策略,面试必问

主题测试文章,只做测试使用。发布者:℅傍ㄖ免沦陷dε鬼,转转请注明出处:http://www.cxybcw.com/17950.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code