一、背景
大家好呀,上周我们公司由于定时线程池使用不当出了一个故障,几千万的单子可能没了。

给兄弟们分享分享这个坑,希望兄弟们以后别踩!
业务中大量的使用定时线程池(ScheduledExecutorService)执行任务,有时候会忽略掉 Try/Catch 的异常判断。
当任务执行报错时,会导致整个定时线程池挂掉,影响业务的正常需求。
二、问题
我们来模仿一个生产的例子:
合作方修改频率低且合作方允许最终一致性。
我们有一个定时任务每隔 60 秒去 MySQL 拉取全量的 合作方 数据放至 合作方缓存(本地缓存) 中。
当客户请求时,我们去缓存中拿取合作方即可。

这样的生产例子应该存在于绝大数公司,代码如下:
public class Demo {// 创建定时线程池private static ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);private ListpartnerCache = new ArrayList<>(); public void init() {scheduledExecutorService.scheduleAtFixedRate(new Runnable() {public void run() {// 启动时每隔60秒执行一次数据库的刷新// 将数据缓存至本地loadPartner();}}, 3, 60, TimeUnit.SECONDS);}public void loadPartner() {// 查询数据库当前最新合作方数据ListpartnerList = queryPartners(); // 合作方数据放至缓存partnerCache.clear();partnerCache.addAll(partnerList);}public ListqueryPartners() {// 数据库挂了!throw new RuntimeException();}}
运行上述样例,我们会发现程序不停止,输出一遍 Load start!,一直在运行,但后续不输出 Load start!
这个时候我们可以确认:**异常确实导致当前任务不再执行**
1、为什么任务报错会影响定时线程池?
2、定时线程池是真的挂掉了嘛?
3、定时线程池内部是如何执行的?
跟着这三个问题,我们一起来看一看 ScheduledExecutorService 的原理介绍。
三、原理剖析
对于 ScheduledExecutorService 来说,本质上是 延时队列 + 线程池。
DelayQueue 是一个无界的 BlockingQueue,用于放置实现了Delayed接口的对象,只能在到期时才能从队列中取走。
这种队列是有序的,即队头对象的延迟到期时间最长。
我们看一下 延时队列 里对象的属性:
class MyDelayedTask implements Delayed{// 当前任务创建时间private long start = System.currentTimeMillis();// 延时时间private long time ;// 初始化public MyDelayedTask(long time) {this.time = time;}/*** 需要实现的接口,获得延迟时间(用过期时间-当前时间)*/public long getDelay(TimeUnit unit) {return unit.convert((start+time) - System.currentTimeMillis(),TimeUnit.MILLISECONDS);}/*** 用于延迟队列内部比较排序(当前时间的延迟时间 - 比较对象的延迟时间)*/public int compareTo(Delayed o) {MyDelayedTask o1 = (MyDelayedTask) o;return (int) (this.getDelay(TimeUnit.MILLISECONDS) - o.getDelay(TimeUnit.MILLISECONDS));}}

所以,延时队列的实现原理也很简单:
生产端:投递消息时增加时间戳(当前时间+延时时间)
消费端:用当前时间与时间戳进行比较,若小于则消费,反之则循环等待

当前的线程池个数低于核心线程数,直接添加核心线程即可。
当前的线程池个数大于核心线程数,将任务添加至阻塞队列中。
如果添加阻塞队列失败,则需要添加非核心线程数处理任务。
如果添加非核心线程数失败(满了),执行拒绝策略。
我们从定时线程池的创建看:
scheduledExecutorService.scheduleAtFixedRate(myTask, 3L, 1L, TimeUnit.SECONDS);
public ScheduledFuture scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) {// 初始化我们的任务// triggerTime:延时的实现ScheduledFutureTasksft = new ScheduledFutureTask (command,null,triggerTime(initialDelay, unit),unit.toNanos(period)); RunnableScheduledFuturet = decorateTask(command, sft); sft.outerTask = t;delayedExecute(t);return t;}private void delayedExecute(RunnableScheduledFuture task) {// 将当前任务丢进延时队列super.getQueue().add(task);// 创建核心线程并启动ensurePrestart();}// 时间轮算法private long triggerTime(long delay, TimeUnit unit) {return now() + delay;}
从这里我们可以得到结论:定时线程池通过延时队列来达到定时的目的。
有一个问题:我们仅仅向 Queue 里面放了一个任务,他是怎么保证执行多次的呢?
带着这个问题,我们看一下他拉取任务启动的代码:
for (;;) {// 从延时队列中获取任务Runnable r = workQueue.take();}public RunnableScheduledFuture take(){for (;;) {// 获取队列第一个任务RunnableScheduledFuture first = queue[0];// 【重点】如果当前队列任务为空,则等待if (first == null){available.await();}// 获取当前任务的时间long delay = first.getDelay(NANOSECONDS);if (delay <= 0){// 弹出当前任务return finishPoll(first);}}}// 时间戳减去当前时间public long getDelay(TimeUnit unit) {return unit.convert(time - now(), NANOSECONDS);}
当拿到任务(ScheduledFutureTask)之后,会执行任务:task.run()
public void run() {// 执行当前的任务if (ScheduledFutureTask.super.runAndReset()) {setNextRunTime();reExecutePeriodic(outerTask);}}protected boolean runAndReset() {if (state != NEW){return false;}int s = state;try {Callablec = callable; if (c != null && s == NEW) {try {// 执行任务c.call();// 【重点!!!】如果任务正常执行成功的话,这里会将ran置为true// 如果你的任务有问题,会被下面直接捕捉到,不会将此处的ran置为trueran = true;} catch (Throwable ex) {// 出现异常会将state置为EXCEPTIONAL// 标记当前任务执行失败并将异常赋值到结果setException(ex);}finally {s = state;}}}// ran:当前任务是否执行成功// s:当前任务状态// ran为false:当前任务执行失败// s == NEW = false:当前任务状态出现异常return ran && s == NEW;}
如果我们的 runAndReset 返回 false 的话,那么进不去 setNextRunTime 该方法:
if (ScheduledFutureTask.super.runAndReset()) {// 修改当前任务的TimesetNextRunTime();// 将任务重新丢进队列reExecutePeriodic(outerTask);}
最终,任务没有办法被丢进队列,我们的线程无法拿到任务执行,一直在等待。
四、结论
通过上面的分析,我们回头看一下开篇的三个问题:
任务报错不会影响线程池,只是线程池将当前任务给丢失,没有继续放到队列中。
定时线程池没有挂,挂的只是报错的任务。
线程池 + 延时队列
所以,通过上述的讲解,我们应该认识到:定时任务一定要加Try Catch。
不然一旦发生异常,你就会和作者一样,背故障让公司损失几千万,血的教训!
五、总结
鲁迅先生曾说:独行难,众行易,和志同道合的人一起进步。彼此毫无保留地分享经验,才是对抗互联网寒冬的最佳选择。
其实很多时候,并不是我们不够努力,很可能就是自己努力的方向不对,如果有一个人能稍微指点你一下,你真的可能会少走几年弯路。
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721