小编给大家分享一下基于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 秒之间,先来看一组数据(样本数据越多越生动)
把 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:16 | T2 | T1 执行后时间来到了 01:23:24, 下一次任务 T2 安排在更早的时间,所以立即执行 T2 |
01:23:21 | T3 | T2 完后时间是 01:23:28, T3 的安排时间也比它早,所以也是立即执行 T3 |
01:23:26 | T4 | T3 完后时间是 01:23:40, 无需等待立即执行 T4 |
01:23:31 | T5 | 后面的情况都是一样的, T5.endTime > T6.scheduledTime + fixedRate, 所以立即执行 T6 除非有一些短任务能把时间压缩回去,造成上一次任务结束后需要进行等待 |
01:23:35 | T6 | |
01:23:41 | T7 |
因此,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))); }
输出为
因为第一次任务 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 总是前一次任务完成后,延时固定长度然后执行一次任务
看了网上很多文章,一大段的测试代码,复杂的解释,真的是觉得好多此一举,看的人头疼
其实很简单很简单一两句话就能把fixedRate和fixedDelay的区别解释的一清二楚:
fixedRate=5000:下一次任务的开始时间是这一次开始的时间+5秒
fixedDelay=5000:下一次任务的开始时间是这一次开始的时间+这一次任务的执行耗时+5秒
以上是“基于Spring定时任务的fixedRate和fixedDelay有哪些区别”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。