理解 Spring 定时任务的 fixedRate 和 fixedDelay 的区别

用过  Spring 的 @EnableScheduling 的都知道,我们用三种形式来部署计划任务,即 @Scheduled 注解的 fixedRate(fixedRateString), fixedDelay(fixedDelayString), 以及 cron. cron 不在这里讨论的范畴。我们着重在如何理解 fixedRate 和 fixedDelay 的区别。

在 Spring 的Scheduled 注解的 JavaDoc 对此的解释很简单

public abstract long fixedRate 

Execute the annotated method with a fixed period in milliseconds between invocations.

public abstract long fixedDelay 

Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.

只是说是 fixedRate 任务两次执行时间间隔是任务的开始点,而 fixedDelay 的间隔是前次任务的结束与下次任务的开始。

大致用示意字符串来表示如下(每个 T1, 或 T2 代表任务执行秒数(每次任务执行时间不定),假定 fixedRate 或  fixedDelay 的值是 5 秒,用 W 表示等待的数)

fixedRate:    T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6........

fixedDelay:  T1.T1.WWWWW.T2.T2.T2WWWWW.T3.T3.T3.T3.T3.WWWWW.T4.T4.T4.T4.T4.T4.T4.WWWWWT6.T6......

一般来说能理解到上面两个场景已经差不多了,相比而言 fixedDelay 简单些,盯着上一次任务的屁股就行。

以前我对 fixedRate 还有一个误区就是,以为任务时长超过 fixedRate 时会启动多个任务实例,其实不会; 只不过会在上次任务执行完后立即启动下一轮。除非这个 Job 方法用 @Async 注解了,使得任务不在 TaskScheduler 线程池中执行,而是每次创建新线程来执行。

具体理解我们可以用代码来演示

@EnableScheduling

@SpringBootApplication

public class Application {


    private AtomicInteger number = new AtomicInteger();


    public static void main(String[] args) {

        SpringApplication.run(Application.class, args);

    }


    @Bean

    public TaskScheduler taskScheduler() {

        ThreadPoolTaskScheduler taskScheduler = new ThreadPoolTaskScheduler();

        taskScheduler.setPoolSize(5);

        return taskScheduler;

    }


    @Scheduled(fixedRate = 5000)

    public void job() {

        LocalTime start = LocalTime.now();

        System.out.println(Thread.currentThread() + " start " + number.incrementAndGet() + " @ "  + start);

        try {

            Thread.sleep(ThreadLocalRandom.current().nextInt(15) * 1000);

        } catch (InterruptedException e) {

        }

        LocalTime end = LocalTime.now();

        System.out.println(Thread.currentThread() + " end " + number.get() + " @ " + end

            + ", seconds cost " + (ChronoUnit.SECONDS.between(start, end)));

    }

}

初始化了一个线程池大小为 5  的 TaskScheduler, 避免了所有任务都用一个线程来执行。 上例中的 fixedRate 为 5 秒,任务执行时间在 0 ~ 15 秒之间,先来看一组数据(样本数据越多越生动)

Thread[taskScheduler-1,5,main] start 1 @ 01:23:11.726

Thread[taskScheduler-1,5,main] end 1 @ 01:23:24.732, seconds cost 13

Thread[taskScheduler-1,5,main] start 2 @ 01:23:24.736

Thread[taskScheduler-1,5,main] end 2 @ 01:23:28.737, seconds cost 4

Thread[taskScheduler-2,5,main] start 3 @ 01:23:28.738

Thread[taskScheduler-2,5,main] end 3 @ 01:23:40.739, seconds cost 12

Thread[taskScheduler-1,5,main] start 4 @ 01:23:40.740

Thread[taskScheduler-1,5,main] end 4 @ 01:23:52.745, seconds cost 12

Thread[taskScheduler-3,5,main] start 5 @ 01:23:52.745

Thread[taskScheduler-3,5,main] end 5 @ 01:24:00.748, seconds cost 8

Thread[taskScheduler-3,5,main] start 6 @ 01:24:00.749

Thread[taskScheduler-3,5,main] end 6 @ 01:24:05.750, seconds cost 5

Thread[taskScheduler-3,5,main] start 7 @ 01:24:05.750

Thread[taskScheduler-3,5,main] end 7 @ 01:24:05.750, seconds cost 0

Thread[taskScheduler-3,5,main] start 8 @ 01:24:05.750

Thread[taskScheduler-3,5,main] end 8 @ 01:24:14.752, seconds cost 9

Thread[taskScheduler-3,5,main] start 9 @ 01:24:14.752

Thread[taskScheduler-3,5,main] end 9 @ 01:24:26.756, seconds cost 12

Thread[taskScheduler-3,5,main] start 10 @ 01:24:26.757

Thread[taskScheduler-3,5,main] end 10 @ 01:24:39.757, seconds cost 13

Thread[taskScheduler-3,5,main] start 11 @ 01:24:39.757

Thread[taskScheduler-3,5,main] end 11 @ 01:24:43.761, seconds cost 4

Thread[taskScheduler-3,5,main] start 12 @ 01:24:43.762

Thread[taskScheduler-3,5,main] end 12 @ 01:24:47.763, seconds cost 4

Thread[taskScheduler-3,5,main] start 13 @ 01:24:47.763

Thread[taskScheduler-3,5,main] end 13 @ 01:24:49.766, seconds cost 2

Thread[taskScheduler-3,5,main] start 14 @ 01:24:49.767

把 start 行用红色显示。

任务 1 与 2 之间间隔时间是任务时长 13,所以任务 2 在 1 结束后立即启动

任务 3 与 2 之间间隔还不到 5 秒,也是在任务 2 结束后立即执行

后面都是在上次任务结束后立即执行下一次任务,看到 7 与 8 之间相差 0 秒,13 与 14 之间相关 2 秒

从上面的结果分析,似乎 fixedRate 越到后面都不起作用,总是任务一个接一个的执行。也就是说上面 fixedRate 的示意串

T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6........

已经不成立了,当中间发生了一长时间的任务后,fixedRate 变成了如下的形式

T1.T1.WWWT2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T2.T3.T3.T3.T3.T4.T4.T4.T5.T5.T5.......

任务间的等待都被抹除掉了,这是为什么呢?因为 fixedRate 会对将要执行的任务作一个预先编排,由上输出可以第一次任务在 01:23:11 时间点启动,所以  fixedRate 会基于此把一个时间表准备好,如下

01:23:16T2T1 执行后时间来到了 01:23:24, 下一次任务 T2 安排在更早的时间,所以立即执行 T2

01:23:21T3T2 完后时间是 01:23:28, T3 的安排时间也比它早,所以也是立即执行 T3

01:23:26T4T3 完后时间是 01:23:40, 无需等待立即执行 T4

01:23:31T5后面的情况都是一样的, T5.endTime > T6.scheduledTime + fixedRate, 所以立即执行 T6 

除非有一些短任务能把时间压缩回去,造成上一次任务结束后需要进行等待

01:23:35T6

01:23:41T7

 因此,fixedRate 总是在上一次任务结束后从时间表中挑出下一次任务,对比该任务所预先排好的时间是否晚于上次任务启动时间加上 fixedRate 值,是则等待到预定的时间,否则立即执行。

假设 T1 执行完后时间是 T1.endTime, 这时候判断 T1.endTime < T2.scheduledTime + fixedRate,  是则等待到 T2.scheduledTime 启动 T2, 否则立即执行  T2

我们可以用代码进一步来验证上面的说法,其实最具说服力的莫过于源代码,这里只提供感观体验

代码的改动是第一次任务执行时间为 23  秒,此后的任务是不耗时的空操作

    private AtomicBoolean firstTime = new AtomicBoolean(true);


    @Scheduled(fixedRate = 5000)

    public void job() {

        LocalTime start = LocalTime.now();

        System.out.println(Thread.currentThread() + " start " + number.incrementAndGet() + " @ "  + start);

        if (firstTime.getAndSet(false)) {

            try {

                Thread.sleep(23000);

            } catch (InterruptedException e) {

            }

        }

        LocalTime end = LocalTime.now();

        System.out.println(Thread.currentThread() + " end " + number.get() + " @ " + end

            + ", seconds cost " + (ChronoUnit.SECONDS.between(start, end)));

    }

输出为

Thread[taskScheduler-1,5,main] start 1 @ 03:27:54.556

Thread[taskScheduler-1,5,main] end 1 @ 03:28:17.562, seconds cost 23

Thread[taskScheduler-1,5,main] start 2 @ 03:28:17.566

Thread[taskScheduler-1,5,main] end 2 @ 03:28:17.566, seconds cost 0

Thread[taskScheduler-2,5,main] start 3 @ 03:28:17.566

Thread[taskScheduler-2,5,main] end 3 @ 03:28:17.567, seconds cost 0

Thread[taskScheduler-1,5,main] start 4 @ 03:28:17.584

Thread[taskScheduler-1,5,main] end 4 @ 03:28:17.584, seconds cost 0

Thread[taskScheduler-4,5,main] start 5 @ 03:28:17.584

Thread[taskScheduler-4,5,main] end 5 @ 03:28:17.584, seconds cost 0

Thread[taskScheduler-4,5,main] start 6 @ 03:28:19.549

Thread[taskScheduler-4,5,main] end 6 @ 03:28:19.550, seconds cost 0

Thread[taskScheduler-4,5,main] start 7 @ 03:28:24.549

Thread[taskScheduler-4,5,main] end 7 @ 03:28:24.550, seconds cost 0

Thread[taskScheduler-4,5,main] start 8 @ 03:28:29.548

Thread[taskScheduler-4,5,main] end 8 @ 03:28:29.549, seconds cost 0

Thread[taskScheduler-4,5,main] start 9 @ 03:28:34.546

因为第一次任务 23 秒的延误,所以后续的任务 2, 3, 4, 5 都是上次任务(耗时为 0)完后立即执行,任务 6 把 2 秒的差距找回来了,以后都是每隔 5 秒执行一次。

fixedDelay 的逻辑就相当简单了,基本无需用代码来演示。不妨把上面的代码中的 fixedRate 改成 fixedDelay 来一见分晓:

Thread[taskScheduler-1,5,main] start 1 @ 02:54:33.750

Thread[taskScheduler-1,5,main] end 1 @ 02:54:43.756, seconds cost 10

Thread[taskScheduler-1,5,main] start 2 @ 02:54:48.765

Thread[taskScheduler-1,5,main] end 2 @ 02:55:00.767, seconds cost 12

Thread[taskScheduler-2,5,main] start 3 @ 02:55:05.769

Thread[taskScheduler-2,5,main] end 3 @ 02:55:11.772, seconds cost 6

Thread[taskScheduler-1,5,main] start 4 @ 02:55:16.775

Thread[taskScheduler-1,5,main] end 4 @ 02:55:21.781, seconds cost 5

Thread[taskScheduler-3,5,main] start 5 @ 02:55:26.785

Thread[taskScheduler-3,5,main] end 5 @ 02:55:27.787, seconds cost 1

Thread[taskScheduler-3,5,main] start 6 @ 02:55:32.789

Thread[taskScheduler-3,5,main] end 6 @ 02:55:41.792, seconds cost 9

Thread[taskScheduler-3,5,main] start 7 @ 02:55:46.794

总是上次任务结束 5 秒后,由此可见 fixedDelay 不存在任务的预先编排操作了,都是相机而为。

最后小结一下:fixedRate 每次任务结束后会从任务编排表中找下一次该执行的任务,判断是否到时机执行。fixedRate 的任务某次执行时间再长也不会造成两次任务实例同时执行,除非用了 @Async 注解。 fixedDelay 总是前一次任务完成后,延时固定长度然后执行一次任务

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,830评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,992评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,875评论 0 331
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,837评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,734评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,091评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,550评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,217评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,368评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,298评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,350评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,027评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,623评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,706评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,940评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,349评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,936评论 2 341