基于Spring定时任务的fixedRate和fixedDelay的区别

目录
  • Spring定时任务的fixedRate和fixedDelay区别
  • 定时任务fixedRate和fixedDelay区别最简单的解释

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和fixedDelay的区别解释的一清二楚:

  • fixedRate=5000:下一次任务的开始时间是这一次开始的时间+5秒
  • fixedDelay=5000:下一次任务的开始时间是这一次开始的时间+这一次任务的执行耗时+5秒

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • springboot 定时任务@Scheduled实现解析

    这篇文章主要介绍了springboot 定时任务@Scheduled实现解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 1.pom.xml中导入必要的依赖: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version&g

  • Spring Task定时任务的配置和使用详解

    记录下Spring自带的定时任务用法. spring中使用定时任务 基于xml配置文件使用定时任务 首先配置spring开启定时任务 <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/

  • SpringBoot定时任务两种(Spring Schedule 与 Quartz 整合 )实现方法

    前言 最近在项目中使用到定时任务,之前一直都是使用Quartz 来实现,最近看Spring 基础发现其实Spring 提供 Spring Schedule 可以帮助我们实现简单的定时任务功能. 下面说一下两种方式在Spring Boot 项目中的使用. Spring Schedule 实现定时任务 Spring Schedule 实现定时任务有两种方式 1. 使用XML配置定时任务, 2. 使用 @Scheduled 注解. 因为是Spring Boot 项目 可能尽量避免使用XML配置的形式,

  • 基于Spring定时任务的fixedRate和fixedDelay的区别

    目录 Spring定时任务的fixedRate和fixedDelay区别 定时任务fixedRate和fixedDelay区别最简单的解释 Spring定时任务的fixedRate和fixedDelay区别 用过 Spring 的 @EnableScheduling 的都知道,我们用三种形式来部署计划任务,即 @Scheduled 注解的 fixedRate(fixedRateString), fixedDelay(fixedDelayString), 以及 cron. cron 不在这里讨论的

  • 基于Spring中的线程池和定时任务功能解析

    1.功能介绍 Spring框架提供了线程池和定时任务执行的抽象接口:TaskExecutor和TaskScheduler来支持异步执行任务和定时执行任务功能.同时使用框架自己定义的抽象接口来屏蔽掉底层JDK版本间以及Java EE中的线程池和定时任务处理的差异. 另外Spring还支持集成JDK内部的定时器Timer和Quartz Scheduler框架. 2.线程池的抽象:TaskExecutor TaskExecutor涉及到的相关类图如下: TaskExecutor接口源代码如下所示: p

  • 基于Spring + Spring MVC + Mybatis 高性能web构建实例详解

    一直想写这篇文章,前段时间痴迷于JavaScript.NodeJs.AngularJS,做了大量的研究,对前后端交互有了更深层次的认识. 今天抽个时间写这篇文章,我有预感,这将是一篇很详细的文章,详细的配置,详细的注释,看起来应该很容易懂. 用最合适的技术去实现,并不断追求最佳实践.这就是架构之道. 希望这篇文章能给你们带来一些帮助,同时希望你们可以为这个项目贡献你的想法. 源码地址:https://github.com/Eliteams/quick4j 点击打开 源码地址:https://gi

  • 详解基于Spring Boot与Spring Data JPA的多数据源配置

    由于项目需要,最近研究了一下基于spring Boot与Spring Data JPA的多数据源配置问题.以下是传统的单数据源配置代码.这里使用的是Spring的Annotation在代码内部直接配置的方式,没有使用任何XML文件. @Configuration @EnableJpaRepositories(basePackages = "org.lyndon.repository") @EnableTransactionManagement @PropertySource("

  • 基于Spring MVC 简介及入门小例子(推荐)

    一.什么是 Spring MVC Spring MVC 属于 SpringFrameWork 的后续产品,已经融合在 Spring Web Flow 里面,是一个强大灵活的 Web 框架.Spring MVC 提供了一个 DispatcherServlet 作为前端控制器来分配请求.通过策略接口,Spring 框架是高度可配置的.Spring MVC 还包含多种视图技术,如 Java Server Pages(JSP).Velocity.Tiles.iText 和 POI 等.Spring MV

  • 基于spring 方法级缓存的多种实现

    方案实施 1. spring和ehcache集成 主要获取ehcache作为操作ehcache的对象. spring.xml中注入ehcacheManager和ehCache对象,ehcacheManager是需要加载ehcache.xml配置信息,创建ehcache.xml中配置不同策略的cache. <!-- ehCache 配置管理器 --> <bean id="ehcacheManager" class="org.springframework.ca

  • 基于spring boot 的配置参考大全(推荐)

    如下所示: # =================================================================== # COMMON SPRING BOOT PROPERTIES # # This sample file is provided as a guideline. Do NOT copy it in its # entirety to your own application. ^^^ # =============================

  • 基于spring中的aop简单实例讲解

    aop,即面向切面编程,面向切面编程的目标就是分离关注点,比如:一个骑士只需要关注守护安全,或者远征,而骑士辉煌一生的事迹由谁来记录和歌颂呢,当然不会是自己了,这个完全可以由诗人去歌颂,比如当骑士出征的时候诗人可以去欢送,当骑士英勇牺牲的时候,诗人可以写诗歌颂骑士的一生.那么骑士只需要关注怎么打仗就好了.而诗人也只需要关注写诗歌颂和欢送就好了,那么这样就把功能分离了.所以可以把诗人当成一个切面,当骑士出征的前后诗人分别负责欢送和写诗歌颂(记录).而且,这个切面可以对多个骑士或者明人使用,并不只局

  • 基于Spring@Autowired注解与自动装配详谈

    1 配置文件的方法 我们编写spring 框架的代码时候.一直遵循是这样一个规则:所有在spring中注入的bean 都建议定义成私有的域变量.并且要配套写上 get 和 set方法. Boss 拥有 Office 和 Car 类型的两个属性: 清单 3. Boss.java package com.baobaotao; public class Boss { private Car car; private Office office; // 省略 get/setter @Override p

  • 详解基于Spring Boot/Spring Session/Redis的分布式Session共享解决方案

    分布式Web网站一般都会碰到集群session共享问题,之前也做过一些Spring3的项目,当时解决这个问题做过两种方案,一是利用nginx,session交给nginx控制,但是这个需要额外工作较多:还有一种是利用一些tomcat上的插件,修改tomcat配置文件,让tomcat自己去把Session放到Redis/Memcached/DB中去.这两种各有优缺,也都能解决问题. 但是现在项目全线Spring Boot,并不自己维护Tomcat,而是由Spring去启动Tomcat.这样就会有一

随机推荐