聊透Spring定时任务调度

迷南。 2023-10-08 21:31 9阅读 0赞

由于新的专栏还在筹备中，本文我们还是聊一聊Spring的话题，本文我们聊一下Spring定时任务调度。这个主题，相信大家都比较熟悉，平时用的应该也比较多。不过说起实现原理，了解的小伙伴应该就不太多了，网上对应的文章虽然很多，不过基本都是使用教程。即使有少部分提及原理，说的也是含糊不清，更有甚者是胡说八道。

其实Spring的定时任务调度，并不神秘，也不是Spring特有的，本质还是借助JDK的能力实现的，只是**在使用方式上更Spring一点**，也就是更简洁、更便捷一点。

> 关于JDK的定时任务，主要是借助 `ScheduledThreadPoolExecutor`实现的，感兴趣的小伙伴可以可以自行了解其实现原理。这里我们主要聊Spring的相关细节，关于JDK部分我们不会详细介绍。
> 
> 当然，如果你们有需要，恰巧我也有时间的话，也可以拿出来说一说，毕竟说啥不是说呢，是吧。

## 1. Spring定时任务的类型 ##

关于Spring定时任务的使用，小伙伴们应该都比较熟悉，就是直接在方法上加上`@Scheduled`注解即可。Spring会根据你指定的频率，定时调度该方法的执行，这一点完全不用你关心。

使用自然是很简单的，这是Spring一贯的风格。关于Spring是怎么做的，读过贰师兄前面文章的小伙伴应该也可以猜到，至少得先把这些标注了`@Scheduled`注解的定时方法找出来，然后在想办法让它定时执行。当然前面我们也说了，这部分是借助JDK的能力来实现的。

> 不熟悉这个路数的小伙伴，可以参考[聊透Spring事件机制][Spring]中@EventListener注解的解析和注册过程，套路是一样的。

但是在使用Spring定时调度的过程，也有一些细节需要先和小伙伴们介绍清楚。首先就是Spring支持的三种类型任务的执行逻辑，这里恐怕能说清楚的小伙伴们不多，尤其是在碰到单线程模型，我们先梳理一下：

Spring支持CRON表达式类型、fixedDelay间隔执行、fixedRate间隔执行三种任务类型。关于这三种类型在任务执行上的差别，我们一一介绍一下。

### 1.1 CRON表达式类型任务 ###

关于CRON表达式含义，这里我们不再介绍，相信小伙伴们都比较熟悉，实在不熟悉自行查阅资料吧。

我们要说的是，在单线程执行的情况下，`如果CRON任务执行时间过长，以至于下次执行的时间都到了，但是上次任务还没有执行结束，下次任务要怎么办。`

这里先给结论：`放弃`，也就是`下一次任务执行就被放弃了，也就是少执行了一次`。这里拿任务设置为每五秒执行一次的表达式，说明一下：

1.  假设10:00:00s时，任务第一次执行，但是任务执行时间很长，执行了7s。
2.  根据任务的执行计划，10:00:05s时，应该要执行第二次任务，但是此时发现有任务在执行(上一次任务需要执行到10:00:07s)，那么，`此次执行计划直接放弃，也就是本次任务不执行了`。
3.  根据任务的执行计划，10:00:10s时，应该要执行第三次任务，此时发现没有任务执行，本次任务正常执行。

![format_png][]

这里大家一定要注意，单线程模型下，由于第一次任务执行时间较长，导致第二次任务不执行，也就是少执行了一次。这里可能会影响预期、从而产生业务影响。

### 1.2 fixedDelay间隔类型任务 ###

fixedDelay是最简单的一种方式模型，间隔执行：也就是延迟指定的间隔后，再次执行下次任务。计算公式为：`下次执行时间 = 上次任务执行结束时间 + 间隔时间`。相同的问题：如果任务执行时间较长，下次执行时间也会晚于预期。这里以任务间隔为五秒，说明一下：

1.  假设10:00:00s时，任务第一次执行，任务执行时间较长，执行了7s。
2.  第一次任务执行结束后(10:00:07)，等待5s后，再次执行下一次任务(10:00:12)，第二次任务执行了3s。
3.  第二次任务执行结束后(10:00:15)，等待5s后，再次执行下一次任务，依此类推。

![format_png 1][]

这里需要注意，单线程模型下，如果存在任务执行时间较长，`整体的执行计划都会往后顺延`。

### 1.3 fixedRate间隔类型任务 ###

fixedRate也是间隔执行的方式，只是这个间隔不是按照任务结束时间计算的，而是按照开始时间。计算公式为：`下次执行时间 = 上次任务执行开始时间 + 间隔时间`。当然，如果任务执行时间较长，超过间隔时间，下次执行时间也要顺延，毕竟不能强暴的直接打断吧。

不过fixedRate会将间隔会自动缩小，尽量追赶计划执行时间，一旦赶上或者追平，继续按照指定间隔执行。这里还是以间隔为五秒的情况，说明一下：

1.  假设10:00:00s时，任务第一次执行，任务执行时间较长，执行了7s。
2.  根据任务的执行计划，10:00:05s时，应该要执行第二次任务，但是此时第一次任务还在执行中，所以第二次执行时间只能等待顺延。
3.  第一次任务执行结束后(10:00:07)，发现已经晚于第二次执行的计划时间了。会追赶进度，所以第二次任务立即执行。
4.  这里假设第二次任务只需要执行2s，在10:00:09就执行结束了。计划第三次执行时间为：10:00:10，也就是第二次任务已经追平了，无需继续追赶，此时会遵循计划，在10:00:10时，正常执行第三次任务。

![format_png 2][]

这里需要注意，`fixedRate会自动调整间隔，使任务尽快追平计划时间，追平后遵循计划执行`。当然这里讨论的也是单线程模型下。

好了，关于定时任务的三种类型的讨论就这么多。大家注意在单线程模型下，上面的讨论才有意义。大家清楚不同任务类型，发生任务执行时间过长，对下次执行时间的影响即可。再次强调，是单线程模型下，如果是多线程执行，影响情况需要结合线程池配置分析了，这里我们不具备讨论条件。

> 这里为什么执着的讨论单线程模型，因为Spring默认的就是单线程模型，而往往我们又不指定调度线程池。所以其实单线程模型才是最最常用的。

## 2. @Scheduled注解解析 ##

通过上一章节对Spring三种定时任务类型的介绍，相信小伙伴们已经很清楚他们之间的区别了。在Spring中，定时任务都是由@Scheduled标识的，三种任务类型分别对应@Scheduled的三种属性，分别是`cron`、`fixedDelay`、`fixedRate`，设置对应的值，即为开启对应类型的任务。

我们在上面也介绍过了，Spring要执行这些定时任务，第一步就是需要先解析出来这些定时任务，然后才能交由JDK处理。那么本章节我们就来看一下解析过程。

### 2.1 @EnableScheduling开启任务调度功能 ###

在探索解析流程之前，我们先介绍一下`@EnableScheduling`。大家知道，在使用Spring的定时任务调度功能前，是需要在类上先添加@EnableScheduling开启的，这究竟有什么用呢。

关于Spring的`@EnableXXX`，通常到时开启某种能力，比如EnableScheduling开启定时任务调度、 @EnableAsync开启异步调用等。其实原理也很简单，都是借助`@Import`能力导入某些`BeanPostProcessor`（也有可能是其他类型的），这些BeanPostProcessor，会在bean的生命周期的各个流程发挥重要作用，从而使Spring具有强大的能力。

关键这个过程完全是可插拔的，加入某个BeanPostProcessor，就具备响应能力了，拓展能力极强。这也正是`@EnableXXX`的原理，可以简单理解为：开启某项功能。

> `BeanPostProcessor`是Spring留给我们的一种拓展方式，能力非常强悍，甚至很多Spring的核心能力，比如`@AutoWired`和`@Resource`属性注入，都是借助它实现的。当然，`@EnableXXX`\+`@Import`的组合不仅仅能导入BeanPostProcessor，导入普通配置类也是可以的，并没有导入类型方面的限制。

下面我们看一下@EnableScheduling的做法，实现和我们上面说的一样的，他使用`@Import`导入了`SchedulingConfiguration`这个配置类，这个配置类中使用@Bean将`ScheduledAnnotationBeanPostProcessor`对象放入到Spring容器中。

@Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    @Import(SchedulingConfiguration.class) // 导入SchedulingConfiguration
    @Documented
    public @interface EnableScheduling {
    
    }
    
    @Configuration
    @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
    public class SchedulingConfiguration {
       //使用@Bean将ScheduledAnnotationBeanPostProcessor对象实例放入Spring容器
       @Bean(name = TaskManagementConfigUtils.SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
       @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
       public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
          return new ScheduledAnnotationBeanPostProcessor();
       }
    }
    复制代码

![format_png 3][]

这里的`ScheduledAnnotationBeanPostProcessor`一定是Spring具备定时任务调度能力的关键。正如我们前面提到的，它确实是继承了`BeanPostProcessor`，也就是大名鼎鼎的Bean的后置处理器。确实，这个bean的后置处理器，负责了@Scheduled标注的定时方法的解析、封装、调度执行等全部功能。没有它，这些工作没有人做，确实就不具备定时调度能力了。

> 读过贰师兄[聊透Spring依赖注入][Spring 1]一文的小伙伴，一定马上就能想到，支撑`@AutoWired`属性注入的`AutowiredAnnotationBeanPostProcessor`，和支撑`@Resource`属性注入的`CommonAnnotationBeanPostProcessor`，不都是`BeanPostProcessor`嘛。

这里贰师兄在啰嗦一下，关于bean的后置处理器，大家真的有必要去研究一下，其实Spring的很多强大功能，都是依赖各个不同的`BeanPostProcessor`构筑出来的。他作用于bean的生命周期中的各个阶段，对bean进行功能增强，从而使bean强大无比，去[聊透Spring bean的生命周期][Spring bean]了解一下吧，求求你们了。

### 2.2 创建bean时解析@Scheduled注解方法 ###

现在清楚了`@EnableScheduling`的本质是将`ScheduledAnnotationBeanPostProcessor`放到Spring容器中，它会负责@Scheduled标注的定时方法的解析、封装、调度执行等全部功能。那这些操作什么时候触发呢，又是怎么做的呢，是我们接下来探究的关键。

关于@Scheduled解析流程，贰师兄打开`ScheduledAnnotationBeanPostProcessor`类，大致浏览了一下就找到是在`postProcessAfterInitialization()`完成的。很明显，这里上来就是反射查找@Scheduled的方法，不是他是谁，我们先来简单看一下源码：

// ScheduledAnnotationBeanPostProcessor.java
    public Object postProcessAfterInitialization(Object bean, String beanName) {
       
        // 1：反射解析加了@Scheduled的方法
        Map<Method, Set<Scheduled>> annotatedMethods = MethodIntrospector.selectMethods(targetClass,
            (MethodIntrospector.MetadataLookup<Set<Scheduled>>) method -> {
               Set<Scheduled> scheduledMethods = AnnotatedElementUtils.getMergedRepeatableAnnotations(
                     method, Scheduled.class, Schedules.class);
               return (!scheduledMethods.isEmpty() ? scheduledMethods : null);
            });
    
         // 2：处理加了@Scheduled的方法，(封装成调度任务)
         annotatedMethods.forEach((method, scheduledMethods) ->
               scheduledMethods.forEach(scheduled -> processScheduled(scheduled, method, bean)));
               
         // ...省略其他代码
    }
    
    
    protected void processScheduled(Scheduled scheduled, Method method, Object bean) {
        // 将bean对象、方法信息封装为Runnable对象
        Runnable runnable = createRunnable(bean, method);
        
        // 处理cron表达式
        String cron = scheduled.cron();
        if (StringUtils.hasText(cron)) {
             // 封装成ScheduledTask，保存到tasks中
             tasks.add(this.registrar.scheduleCronTask(new CronTask(runnable, new CronTrigger(cron, timeZone))));
        }
    
        // ...省略fixedDelay和fixedRate任务的解析
    }
    复制代码

这里的解析流程其实比较清晰，就是`反射查找当前创建的bean，是否存在@Scheduled标注的定时任务方法`。如果存在，就对定时任务方法解析、封装处理。解析无非就是对@Scheduled字段的解析；关于为什么封装，这里需要和小伙伴解释一下，后续定时调度这些方法是通过反射的方式，反射我们比较了解，需要method和对象信息的，而定时任务执行时间依赖@Scheduled注解信息，所以需要将三者封装成`ScheduledTask`对象，先保存起来，供后续使用。

![format_png 4][]

> 这里之所以先保存起来，也是Spring一贯的做法都是先解析暂存，后续再使用。之所以这样是因为Spring依赖关系复杂，容器启动过程和bean创建过程中，每个流程都做了很多事情，通常没有办法在一个时机做完某个功能所需的所有事情，所以会分散在各个流程里，这也是Spring源码复杂最主要的原因。

关于@Scheduled解析时机，解析方法都找到了，看一下调用关系就可以了，发现是在创建bean时，初始化回调时进行的，这也合理，创建bean时，解析一下bean中@Scheduled标注的定时方法。

## 3. @Scheduled定时任务调度执行 ##

现在Spring已经将加了@Scheduled的调度任务解析出来了，那下一步就是调度任务的执行了。之前我们也说过，这部分借助的是JDK的定时任务调度能力，Spring只是做了融合翻译的工作，也就是`把@Scheduled标注的定时方法，翻译成符合DJK规定的定时调度任务，再交由JDK的ScheduledThreadPoolExecutor执行`。

这里可以看到，Spring所做的并不复杂，不过还是有一些细节需要注意，第一个问题就是：`执行任务的调度线程池从何而来`。我们知道，对JDK定时任务调度而言，调度线程池至关重要，通常第一步就是先创建一个`ScheduledThreadPoolExecutor`，然后对这个调度线程池提交任务的。我们先来看一下原生的做法：

> 这里贰师兄没有自己写，而是从RocketMQ摘取了部分相关源码。rocketMQ中有大量的定时任务使用，也是使用JDK的能力，这里我们参考一下：。

protected void initializeResources() {
        // 1： 创建ScheduledThreadPoolExecutor
        this.scheduledExecutorService = new ScheduledThreadPoolExecutor(1,
            new ThreadFactoryImpl("BrokerControllerScheduledThread", true, getBrokerIdentity()));
    }
    
    protected void initializeBrokerScheduledTasks() {
        // 2：提交任务到scheduledExecutorService，定时进行broker统计的任务
        this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                try {
                    BrokerController.this.getBrokerStats().record();
                } catch (Throwable e) {
                    LOG.error("BrokerController: failed to record broker stats", e);
                }
            }
        }, initialDelay, period, TimeUnit.MILLISECONDS);
    }
    复制代码

之所以选择RocketMQ源码，主要是更具有代表性，免得大家说我使用不规范。当然，另外一个原因也是贰师兄比较熟悉rocketMQ的源码，找起来比较快。

### 3.1 选择合适的线程池执行任务 ###

相对于原生使用的直接创建调度线程池，Spring会有一些小小的麻烦，那就是`选择合适的调度线程池`。如果用户指定了调度线程池还好，如果没有指定呢，不然执行了，还是直接创建一个默认的，如果使用默认兜底，那线程数设置多少合适呢，毕竟线程数的设置要参考：任务数和执行频率啊，这两个值每个项目又都不一样。

> 这里贰师兄需要重点强调一下，给定时任务设置合适的线程池非常重要，第一章节就分析过了，线程池设置的过小，会导致有些调度任务久久不能执行，从而影响数据的准确性，这一点小伙伴们一定要特别注意。

这里Spring的做法是先看用户是否配置了调度线程池，如果配置了，使用用户配置的；如果没有配置，创建一个默认的，但是，Spring创建的默认调度线程池，`是单线程的，是单线程，是单线程！！！`，重要的事情说三遍，贰师兄就在这个上面吃过亏，我们一会看一下具体场景，加深一下小伙伴们的印象。

#### 3.1.1 Spring查找调度线程池 ####

我们先来看一下Spring选择调度线程池的逻辑，逻辑我们已经说清楚了，直接在源码中验证一下。

private void finishRegistration() {
          try {
             // 2.1： 获取容器中配置的TaskScheduler，没有或存在多个，都会抛出异常
             this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, false));
          }
          catch (NoUniqueBeanDefinitionException ex) {
             try {
                //2.2 存在多个的话，再通过名称确定一个
                this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, true));
             }
          }
          catch (NoSuchBeanDefinitionException ex) {
             try {
                // 2.3： 不存在TaskScheduler类型，获取ScheduledExecutorService类型
                this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, false));
             }
             catch (NoUniqueBeanDefinitionException ex2) {
                try {
                   // 2.4： 获取多个ScheduledExecutorService，通过名字确定一个
                   this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, true));
                }
                catch (NoSuchBeanDefinitionException ex3) {
                // 2.5: 没有打印日志即可
             }
             catch (NoSuchBeanDefinitionException ex2) {
                // 2.5: 没有打印日志即可
          }
       }
       // 调度任务执行，如果容器中不存在调度线程池，会创建默认线程池
       this.registrar.afterPropertiesSet();
    }
    复制代码

这部分的源码比较简单，通过`resolveSchedulerBean()`去Spring容器查找特定类型的bean，查找不到会抛出`NoSuchBeanDefinitionException`异常，查找到多个会抛出`NoUniqueBeanDefinitionException`异常，这里都进行了异常捕捉，再次处理对应的逻辑。

按照源码的逻辑，那就是：`先查找TaskScheduler类型的bean`，如果不存在该类型的bean，`再次尝试查找ScheduledExecutorService类型的bean`，实在查找不到，也就是打印一下了一下日志，而且还是debug级别的。找到多个再次根据名称过滤一下，选定一个。

![format_png 5][]

> 这里可以看到，使用用户指定的调度线程池，是看容器中有没有，所以想要指定，直接将想要使用的调度线程池放入Spring容器即可。
> 
> 还有一点需要解释一下，这一步并没有构建默认的线程池，构建默认线程池的流程在下一步哦。

#### 3.1.2 Spring构建的默认调度线程池 ####

在Spring容器中无法找到调度线程池时，Spring会创建默认的调度线程池，我们也看一下这部分的逻辑。

protected void scheduleTasks() {
       if (this.taskScheduler == null) {
          // 重点：没有设置taskScheduler，默认才用单线程
          this.localExecutor = Executors.newSingleThreadScheduledExecutor();
          this.taskScheduler = new ConcurrentTaskScheduler(this.localExecutor);
       }
    }
    
    // 构建默认单线程的调度线程池
    public static ScheduledExecutorService newSingleThreadScheduledExecutor() {
        return new DelegatedScheduledExecutorService
            (new ScheduledThreadPoolExecutor(1));
    }
    
    // 构建corePoolSize为1的调度线程池
    public ScheduledThreadPoolExecutor(int corePoolSize) {
        super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
              new DelayedWorkQueue());
    }
    复制代码

![format_png 6][]

#### 3.1.3 使用默认单线程的调度线程池，导致心跳丢失的案例分析 ####

> 这里简单介绍一下业务场景，项目有两个定时任务，一个是计算任务，定时凌晨2点执行，执行大概时间5分钟；还有一个心跳发送的定时任务，每10s执行一下上报，服务端有检测逻辑，如果实例超过30s未上报心跳，进行实例摘除。当时的场景就是：项目没有设置调度线程池，故自动使用了Spring默认的单线程调度线程池。

这里我们用代码简单模拟一下：

@Component
    public class ScheduledJob {
    
       /** 计算任务，凌晨2点执行，耗时五分钟 */
       @Scheduled(cron = "0 0 2 * * ?")
       void calculation() throws InterruptedException {
          System.out.println("任务1,"+Thread.currentThread().getName()+"开始执行:"+new Date());
          Thread.sleep(5 * 60 * 1000);
          System.out.println("任务1,"+Thread.currentThread().getName()+"执行结束:"+new Date());
       }
    
       /** 心跳任务，每10s上报一次，耗时1s */
       @Scheduled(cron = "*/5 * * * * ?")
       void heartbeat() throws InterruptedException {
          System.out.println("任务2,"+Thread.currentThread().getName()+"开始执行:"+new Date());
          Thread.sleep(1000);
          System.out.println("任务2,"+Thread.currentThread().getName()+"执行结束:"+new Date());
       }
    }
    复制代码

代码如上所示，后来项目发现：每天夜里2:00-2:05期间，实例没有心跳上报了，时间演远远超过30s，最终导致实例被摘除，进而导致其他一系列问题。后来排查下来，就是因为没有配置调度线程池，使用了Spring默认单线程调度线程池导致的。我们分析一下当时的场景：

1.  在2:00前，只有心跳任务执行，因为执行时间短，任务不会阻塞，每次心跳都能正常上报。
2.  在2:00时左右，计算任务启动，唯一的线程资源被占用，执行需要持续五分钟，唯一的执行线程资源在2:05才能被释放。
3.  2:00:10 心跳任务`应该被执行，但是由于没有可以线程，任务只能被放弃`。直到2:05前，都是如此，导致`近五分钟不能上报心跳`。
4.  2:05时左右，计算任务结束，心跳任务才有资源执行，继续上报心跳。

上述案例就是调度线程池设置的不合理，导致实例摘除的真实情况。通过这个案例，希望加深小伙伴们对设置合适的调度线程池有多么重要的深刻意识。赶紧检查一下自己项目调度线程池的设置吧，尤其是连设置都没有设置的小伙伴，更要小心了。

#### 3.1.4 配置合适的调度线程池 ####

现在，我们已经知道配置合适的调度线程池有多么的重要。关于如何创建，连Spring如何查找的底裤都被我们扒出来了，如何配置还不是小菜一碟。为了完整性，我们还是给大家展示一下吧。

@EnableScheduling
    @Configuration
    public class ScheduleConfig {
       @Bean("threadPoolTaskScheduler")
       public TaskScheduler threadPoolTaskScheduler(){
          ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
          scheduler.setPoolSize(10);
          return scheduler;
       }
    }
    复制代码

是不是很简单，直接放入Spring容器中就可以了。关于你是想用`@Bean`、还是想用`@Component`、或者想用`@Import`亦或是自定义`BeanPostProcessor`这些奇技淫巧，那就随你便了。

### 3.2 定时任务调度执行 ###

现在定时任务也查找出来了，调度线程池也有了，可谓是万事俱备，只欠东风了。我们也终于来到任务调度执行得最后一关了。关于调度执行，当然是先把之前解析封装出来`ScheduledTask`任务取出来，转换翻译一下，交给JDK的调度线程池了。不过三种任务类型还不完全一样，我们逐个来看一下。

![format_png 7][]

#### 3.2.1 cron表达式类型的任务执行 ####

其实JDK的ScheduledThreadPoolExecutor本身是不支持cron表达式类型的，这部分能力是Spring赋予的，当然，底层借助的是ScheduledThreadPoolExecutor\#schedule()单次任务调度，spring只是玩了一些小花样，从而使其具备了cron可以重复执行的能力。

这里的具体实现是：Spring先进行cron表达式的解析，计算出下一次任务的具体执行时间，然后交由ScheduledThreadPoolExecutor\#schedule()进行下次调度。不过这还是单次的啊，不具备重复执行的能力啊，这里Spring的小把戏就来了，在执行时间到，ScheduledThreadPoolExecutor执行了先前提交的任务后，会再次计算出下次任务的执行时间，再次提交给ScheduledThreadPoolExecutor。哦，原来是通过`本次执行后，会提交下次任务的方式`，使其具备了CRON重复执行的能力，不得不说，Spring很聪明。

我们直接看一下源码：

public ScheduledTask scheduleCronTask(CronTask task) {
    
       // 重点：2：任务调度执行阶段，将任务提交给调度线程池
       if (this.taskScheduler != null) {
          scheduledTask.future = this.taskScheduler.schedule(task.getRunnable(), task.getTrigger());
       }
       // 1：@Schedule解析时机，taskScheduler为null，仅仅只是将任务包装保存起来即可
       else {
          addCronTask(task);
          this.unresolvedTasks.put(task, scheduledTask);
       }
    }
    
    // # ConcurrentTaskScheduler.java
    public ScheduledFuture<?> schedule(Runnable task, Trigger trigger) {
        //封装ReschedulingRunnable，并调度任务
        return new ReschedulingRunnable(task, trigger, this.scheduledExecutor, errorHandler).schedule();
    }
    复制代码

我们发现，在任务执行的时候，先将任务封装成了`ReschedulingRunnable`，然后调用schedule()进行调用，貌似离核心秘密不远了，我们继续跟踪一下。

public ScheduledFuture<?> schedule() {
       synchronized (this.triggerContextMonitor) {
          // 1：根据cron表达式，计算下次执行时间
          this.scheduledExecutionTime = this.trigger.nextExecutionTime(this.triggerContext);
          if (this.scheduledExecutionTime == null) {
             return null;
          }
          //2：计算下次执行还有多少时间
          long initialDelay = this.scheduledExecutionTime.getTime() - System.currentTimeMillis();
          //3： 将自己作为任务提交给调度线程池执行。
          this.currentFuture = this.executor.schedule(this, initialDelay, TimeUnit.MILLISECONDS);
          return this;
       }
    }
    复制代码

这里终于发现我们想要的地方了，第一步就解析cron表达式，计算出任务执行时间，然后交给ScheduledThreadPoolExecutor\#schedule()执行，这里是第一次执行任务。

> 关于ScheduledThreadPoolExecutor的调度原理，本质上是将定时任务，按照执行时间，有序的维护在内部队列里，然后循环从队列获取执行时间符合的任务，交由线程池执行。只是在正常线程池的任务执行的基础上，引入了时间的概念，感兴趣的小伙伴可以自行查阅资料了解一下。

另外，关于把`this`传递给`schedule()`去执行，可能也有点懵，什么鬼，把自己提交给调度线程池了，这啥啊。小伙伴们冷静想一想，调度线程池本质是个线程池，根据JAVA规范，我们向线程池提交的什么，是不是`Runnable`实例，然后线程池执行的是`Runnable#run()`。

那巧了，`ReschedulingRunnable`就实现了`Runnable`，所以，把自己提交过去，到时候执行的就是`ReschedulingRunnable#run()`。这就需要我们去看一下run()的具体实现，看一下实现逻辑是不是我们之前分析的：先`反射执行@Schedule标注的定时方法`，然后`再提交CRON表达式对应的下一次任务`。

public void run() {
       Date actualExecutionTime = new Date();
       //1： 执行我们定义的@Schedule方法
       super.run();
       Date completionTime = new Date();
       synchronized (this.triggerContextMonitor) {
          Assert.state(this.scheduledExecutionTime != null, "No scheduled execution");
          //2： 更新执行时间信息
          this.triggerContext.update(this.scheduledExecutionTime, actualExecutionTime, completionTime);
          if (!obtainCurrentFuture().isCancelled()) {
             //3：再次调用schedule方法，提交下一次任务
             schedule();
          }
       }
    }
    复制代码

果然不出所料，就是执行了我们定义的@Schedule定时方法，然后提交一下车任务，不过还有一些其他的工作，比如记录一下执行时间信息，目的是：方便进行下一次执行时间的计算。

这里就从源码的角度，带大家窥探了Spring CRON表达式实现的奥秘，总结起来就是：还是借助ScheduledThreadPoolExecutor\#schedule()实现的，对于其不支持的循环执行的问题，Spring采用了`执行完一次任务后，回调schedule()，计算下一次执行时间，重新提交新的任务的方式，使其具备了循环调用的逻辑。`

> 这里有小伙伴对于super.run()是调用我们定义的@Schedule定时方法有所不解，这里之所以可以这样调用，是因为在任务解析时，已经将反射需要的method信息和对象信息封装成`ScheduledMethodRunnable`了，其对应的`run()`就是反射执行该方法。在任务解析时，保存在了CronTask中。
> 
> 再创建ReschedulingRunnable时，又把ScheduledMethodRunnable传递了过来，最后在父类DelegatingErrorHandlingRunnable的run()调用了ScheduledMethodRunnable的run()，所以这里的super.run()，其实就是ScheduledMethodRunnable\#run()，也就是反射执行@Schedule标注的定时方法。

我们总结一下cron任务的调度流程：

![format_png 8][]

#### 3.2.2 FixedDelay任务执行 ####

关于FixedDelay任务的执行，则是直接借助`ScheduledThreadPoolExecutor#scheduleWithFixedDelay()`完成的，这里我们简单看一下：

public ScheduledTask scheduleFixedDelayTask(IntervalTask task) {
       // 转换任务类型为FixedDelayTask
       FixedDelayTask taskToUse = (task instanceof FixedDelayTask ? (FixedDelayTask) task :
             new FixedDelayTask(task.getRunnable(), task.getInterval(), task.getInitialDelay()));
       return scheduleFixedDelayTask(taskToUse);
    }
    
    public ScheduledFuture<?> scheduleWithFixedDelay(Runnable task, Date startTime, long delay) {
        long initialDelay = startTime.getTime() - System.currentTimeMillis();
        //直接使用ScheduledThreadPoolExecutor#scheduleWithFixedDelay()执行，
        // 但是先构建提交的Runnable对象，构建的DelegatingErrorHandlingRunnable类型
        return this.scheduledExecutor.scheduleWithFixedDelay(decorateTask(task, true), initialDelay, delay, TimeUnit.MILLISECONDS);
        // ...省略非核心代码
    }
    复制代码

这里通过源码可以很清楚的看到，在计算了相关参数后，也是先构建了任务提交需要的Runnable对象，然后就直接交由ScheduledThreadPoolExecutor\#scheduleWithFixedDelay()调度执行了。

这里我们就不看构建的DelegatingErrorHandlingRunnable的run()方法了，这里也是`直接反射执行@Schedule标注的定时方法`，并没有在做其他的事情。关于根据间隔循环调度执行，ScheduledThreadPoolExecutor本身就支持啊，这里是不需要再做什么的。

![format_png 9][]

#### 3.2.3 FixedRate任务执行 ####

关于FixedRate的执行，和FixedDelay完全一样，都是借助ScheduledThreadPoolExecutor本身的能力实现的，这里只是做转交而已，只是FixedRate调用的是scheduleWithFixedRate()而已。

![format_png 10][]

> 另外关于FixedRate和FixedDelay，在单线程模型下，任务执行时间过长，对于下次任务执行时间的影响，本身也是JDK的能力和逻辑，和Spring本身无关哦。

![format_png 11][]

### 3.3 定时任务触发执行的时机 ###

现在关于定时任务调度执行的细节，都已经说清楚了。还有一个问题在给小伙伴补充下，就是这些定时任务是什么时候开始调度的。

其实这个问题不讨论也完全无伤大雅，不过贰师兄之前在使用一贯自研的、深度融合Spring的工具时，在碰到定时调度任务时，遇到了问题，后来排查下来发现：定时任务触发时机，和自研工具初始化时机重合，导致在定时任务中使用自研工具，出现了问题。所以这里和大家简单介绍一下：

&emsp，首先我们得先知道，Spring定时任务调度执行，是在接收到`ContextRefreshedEvent`事件后。而自研工具也是接收到这个事件后做核心类创建，然后注入Spring容器中的。

由于是同一时机触发的，先后完成情况无法保证，出现了调度任务已经开始执行，但是核心工具类初始化还没有完成的情况，进而出现了，在调度任务中，使用自研工具出现空指针的情况。故这里和大家简单介绍一下，给大家避个坑。

// 接收ContextRefreshedEvent事件，调度定时任务
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
       if (event.getApplicationContext() == this.applicationContext) {
          // 查找调度线程池，提交调度任务
          finishRegistration();
       }
    }
    复制代码

![format_png 12][]

> 这里需要注意，从代码上看，在所有bean实例化后回调阶段(也就是`afterSingletonsInstantiated()`被调用时)，也有可能会触发定时调度任务的执行，因为代码中也会调用`finishRegistration()`。
> 
> 不过时机分析下来，却没有在这个时机调用，因为此时`applicationContext`已经有值了，这就涉及到`ApplicationContextAware`的回调时机了，贰师兄在[聊透Spring bean的生命周期][Spring bean]文章有介绍，小伙伴们根据这篇文章，自行分析一下吧，相信一定会有所收获的，这里不再赘述了。

作者：贰师兄的屠宰场  
链接：https://juejin.cn/post/7213203008964509752

[Spring]: https://juejin.cn/post/7140849555607650335#heading-12
[format_png]: https://img-blog.csdnimg.cn/img_convert/6b2e8547c80461009e1baa894816ce81.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/bc67bb730cffab6dbee3805f3236f126.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/c77c9c98b0cd87fb85b8612635d2a031.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/bd33af30642b77b89d5b6c16e15a31a4.webp?x-oss-process=image/format,png
[Spring 1]: https://juejin.cn/post/7143419261657022472
[Spring bean]: https://juejin.cn/post/7155884227714613285
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/132079170df5221b3d3ae90112d0ee2b.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/a18850f38cb859a7abb09e4f2d2bfe6e.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/277b9b033a4d8e0d5f69a4351b0d76cd.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/b5c3f13c83aac63597eed249dc1ef26d.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/cd90d9a39b51df2f000e7dbb96305efc.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/3521fd141341f0e6506bd82d8f9abd4e.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/06ead0f38246eaab84ba4161b3d3545a.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/282283428147934fc39df708583457b5.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/b4e095949cf1cbb00663708d187fc2ca.webp?x-oss-process=image/format,png