spring线程池获取线程运行结果(Spring正确关闭线程池姿势)
前几天看到一篇文章,关于线程池关闭的知识点,有点收获;给大家分享一下
线程池正确关闭方式我们直接用个案例,公布方法
上面就是常规的线程池的使用
为简化讨论的复杂性,本文的线程池均是指JDK中的java.util.concurrent.ThreadPoolExecutor
关闭线程池的关键是 shutdown awaitTermination或者 ShutdownNow awaitTermination
我们经常会忘掉awaitTermination方法的设置,我们继续往下看
任务状态一个任务会有如下几个状态:
- 未提交,此时可以将任务提交到线程池
- 已提交未执行,此时任务已在线程池的队列中,等待着执行
- 执行中,此时任务正在执行
- 执行完毕
那么,执行shutdown方法或shutdownNow方法之后,将会影响任务的状态
shutdown拒绝新任务提交
待执行的任务不会取消
正在执行的任务也不会取消,将继续执行
shutdownNow拒绝新任务提交
取消待执行的任务
尝试取消执行中的任务(仅仅是做尝试,成功与否取决于是否响应InterruptedException,以及对其做出的反应)
这两个方法都不会等待任务执行完毕,如果需要等待,请使用awaitTermination。该方法带有超时参数:如果超时后任务仍然未执行完毕,也不再等待。毕竟应用总归要停机重启,而不可能无限等待下去,因此超时机制是提供给用户的最后一道底线
综上,shutdown(Now) awaitTermination 确实是实现线程池优雅关闭的关键
应用中如何正确关闭线程池这一节内容其实才是本文要介绍的重心。上一小节内容我们知道了如何优雅关闭线程池,但那是一般意义上方法论指导,如果将线程池运用于我们的应用中,譬如Spring Boot环境中,复杂度将会变得不一样
本一节,将会介绍线程池在Spring (Boot)环境中优雅关闭遇到的一个问题跟挑战,以及解决方案
场景1我们来假设一个场景,有了场景的铺垫,对问题的理解会简单一些
- 自定义线程池,用于异步任务的执行。此处为演示方便使用Executors.newFixedThreadPool(1)生成了只有一个线程的线程池
- 高并发请求/incr接口,每次请求该接口,都会往线程池中添加一个任务,任务异步执行的过程中依赖Redis
此时,要求停机发布新版本,按照Java System#exit 无法退出程序的问题探索文章,我们知道了优雅停机的一般步骤:
1、切断上游流量入口,确保不再有流量进入到当前节点
2、向应用发送kill 命令,在设定的时间内待应用正常关闭,若超时后应用仍然存活,则使用kill -9命令强制关闭
3、当JVM接收到kill命令,会唤起应用中所有的Shutdown Hooks,等待Shutdown Hooks执行完毕便可以正常关机;与此同时,应用会接着处理在途请求,以确保不会向客户端抛出连接中断异常,实现无感知发布
一切看起来很美好,然而…
当JVM收到kill指令后,便会唤醒所有的Shutdown Hook,而其中有一个Shutdown Hook是Spring应用在启动之初注册的,它的作用是对Spring管理的Bean进行回收,并销毁IOC容器
那么问题就产生了:以我们的场景为例,线程池里的任务与Spring Shutdhwon Hook正在并发地执行着,一旦任务执行期依赖的资源先行被释放,那任务执行时必然会报错
在我们的场景中,就很有可能因为Redis连接被回收,从而导致redisTemplate.opsForValue().increment("demo", 1L);抛出异常,执行失败
如图示:
Jedis连接池先行被回收
下一刻,线程池里的任务尝试获取Jedis连接,失败并抛出异常
场景2
除了上述场景外,还有一个场景或许大家也经常会碰到:本地启动一个定时任务,按一定频率将数据从DB加载到Cache中
例如:
1、每100ms向线程池里扔一个任务
2、任务是:从DB中取出数据,放入缓存(例如Local Cache,Redis)
在Spring Shutdown Hook执行期间,新的任务仍然会产生,又或者旧的任务未执行完毕,一旦尝试获取DB资源,就可能由于资源被回收而获取失败,抛出异常
此时的系统关闭已经不优雅—任务执行有异常,这种异常可能对业务有损,我们应尽量避免类似问题的产生,而不是抱着"算了吧,反正产生这个问题的概率很低",或者"算了吧,反正异常对我目前业务影响也不大"的态度,这是技术人的基本修养,也是对自我提高的要求—目前业务影响不大,允许不优先解决,但是期望掌握一种解决方案,将来有一天如果碰到了对业务损伤比较大的场景。
解决方案这个问题产生的根因,是Spring Shutdown Hook与线程池里的任务并发执行,有可能使任务依赖的资源被提前回收导致的。那么一个很直白的思路即是:在切断流量之后,能否让线程池先关闭,再执行Spring 的Shutdown Hook,避免依赖资源被提前回收?
顺着这个思路,有三个问题需要解决:
1、线程池如何关闭
2、线程池如何感知Spring Shutdown Hook将要被执行
3、如何让线程池先于Spring Shutdown Hook关闭
对于第一个问题,本文的上一个小节线程池正确关闭的姿势已经给出了解决方案:即shutdown(Now) awaitTermination
对于第二个问题,Spring Shutdown Hook被触发的时候,会主动发出一些事件,我们只要监听这些的事件,就能够做出相应的反应
对于第三个问题,我们只要在这些事件的监听器中先行将线程池关闭,再让程序走接下来的关闭流程即可
看一下Spring源码
从上图中可以看出,只要在destroyBeans之前关闭线程池即可,因此,有两种解决方案:
- 监听Spring的ContextClosedEvent事件,在事件被触发时关闭线程池
- 实现Lifecycle接口,并在其stop方法中关闭线程池
此处以监听ContextClosedEvent为例:
此处大家或许能看出一些小问题:需要自行管理线程池。在Spring环境中,我们其实有更多的选择:使用Spring提供的org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor,并将实例交给Spring管理
代码如下:
注: ThreadPoolTaskExecutor的waitForTasksToCompleteOnShutdown awaitTerminationSeconds等于ThreadPoolExecutor的shutdown awaitTermination,且在定义线程池时就将优雅关闭行为一同定义完毕,实现了高内聚的目的
在Spring中使用ThreadPoolTaskExecutor,更便捷:
不用再自行管理线程池,获取的时候也很方便,直接注入即可
在需要关闭的时候,直接调用destroy方法即可实现优雅关闭
这样,Spring就会等到线程池关闭(超时)后,才会接着往下执行Bean的销毁、资源回收、应用上下文关闭的逻辑,确保被依赖资源不会被提前回收掉
总结本篇以两种实际场景为例,抛出了一个很切合实际项目的问题:在Spring应用中如何正确地关闭线程池。文中指出,如果非正常关闭将可能会产生异常的问题,同时也分析了问题产生的原因并给出了相应的解决方案。
,免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com