前言

源碼的世界是一片汪洋大海，springboot的源碼更是如此，雖然用的時候似乎很簡單，然而正是因為其內部的設計巧妙、復雜，才造就了其使用上的簡單易上手。羅馬不是一天建起來的，要完全理解它也并非一時的事，所以這里給大家分享一些我自己閱讀源碼時的一些體會，那就是不要因為一時看不懂而著急或放棄，慢慢來，一點一點來，早晚能弄明白，另外一點就是，帶著問題去看，時刻要把握好自己的問題是什么，不要在源碼中迷失了自己。

核心問題

關于Springboot調度任務的工作原理，實際就是兩個問題：

第一個問題，調度任務是如何被注冊的？

第二個問題，注冊的調度任務是如何觸發執行的？

實現方法

關于Springboot調度任務的具體實現方法已經在上一篇文章中詳細介紹過，這里再作一下簡單的梳理、歸納，主要兩種方法：

• 基于注解@Scheduled
• 基于接口SchedulingConfigurer

兩種方法都需要使用@EnableScheduling（第一個核心關鍵類）來開啟調度任務功能。

基于注解@Scheduled

基于注解@Scheduled內的屬性，可以分為三類調度任務：

1. cron表達式可以通過若干數字、空格、符號按一定的規則，組成一組字符串，定義調度任務的執行規則；
2. fixedDelay以每次調度任務執行完成后間隔指定時間再開始下一次的調度任務，單位是毫秒；
3. fixedRate以每次調度任務開始的時間間隔指定時間再開始下一次的調度任務，單位是毫秒；

基于接口SchedulingConfigurer

實現SchedulingConfigurer接口，并重寫configureTasks()方法，在重寫configureTasks()里，完成調度任務的注冊；

工作原理

基于注解@Scheduled和基于接口SchedulingConfigurer接口，都需要使用@EnableScheduling來開啟調度任務注冊功能。進入@EnableScheduling注解內部觀察一番，發現通過@Import引入了一個配置類SchedulingConfiguration.class（第二個核心關鍵類）

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
@Documented
public @interface EnableScheduling {
}

順著SchedulingConfiguration.class進入其內部，又發現了一個大秘密：ScheduledAnnotationBeanPostProcessor（第三個核心關鍵類）

@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class SchedulingConfiguration {


   @Bean(name = TaskManagementConfigUtils.SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
   @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
   public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
      return new ScheduledAnnotationBeanPostProcessor();
   }


}

對Spring生命周期比較熟悉的話，一看到XxxxBeanPostProcessor，就能想到postProcessAfterInitialization()方法了。

• BeanPostProcessor，spring的后置處理器，重要的擴展點之一，可以在在Bean對象初始化前后回調BeanPostProcessor中定義的兩個方法：
• postProcessBeforeInitialization()方法會在每一個bean對象的初始化方法調用之前回調；postProcessAfterInitialization()方法會在每個bean對象的初始化方法調用之后被回調

基于注解@Scheduled與基于接口SchedulingConfigurer調度任務實現入口是一樣的，其具體實現是不一樣的。

基于注解@Scheduled

還記得第一個問題是什么嗎？（調度任務是如何被注冊的？）基于注解@Scheduled調度任務的注冊就是在中實現在ScheduledAnnotationBeanPostProcessor#postProcessAfterInitialization()方法中實現的，具體的步驟是：

在spring容器中找出被注解@Scheduled.class,@Schedules.class標記過的方法

圖片

接著遍歷這些方法，而實際的調度任務注冊邏輯也是從這里（processScheduled()方法）開始的

圖片

在實現方法里已經梳理清楚了，springboot的調度任務實際上可以分為三類，在本文中就以常用cron表達式類為例來說明其注冊、執行過程。進入processScheduled()內，首先把@Scheduled標記的方法包裝成一個Runnable任務（實現java多線程的方法之一就是實現java.lang.Runnable接口）

圖片

而在processScheduled()也會根據不同類別的任務分別作處理，這里以cron表達式類的調度任務為例看一下后續是怎么處理的。

圖片

進入thsi.registrat.scheduleCronTask()方法內部（第五個核心關鍵類ScheduledTaskRegistrar），很多人認為下面就是觸發開始執行調度任務的執行了；實際上這么認為是錯的，因為這個時候Spring的容器還未啟動完成，任務的調度器（this.taskScheduleer是null）還未實例化，所以這里只是完成調度任務的注冊。

圖片

分析源碼就是這樣，得慢慢來，不要急，要牢牢把握住自己的問題，千萬不要迷路了。下面開始分析第二個問題：注冊的調度任務是如何觸發執行的。

任務注冊上面說到了ScheduledAnnotationBeanPostProcessor#postProcessAfterInitialization()方法被觸發執行，一直到執行到thsi.registrat.scheduleCronTask()只是完成了調度任務的注冊，并沒有開始執行，實際上注冊完成的調度任務開始執行是在Spring容器啟動完成后，會發布一個啟動完成的事件（ContextRefreshedEvent），ScheduledAnnotationBeanPostProcessor實現了Spring的監聽器接口（ApplicationListener），因此實際觸發已注冊調度任務的執行的入口是在監聽方法中（ScheduledAnnotationBeanPostProcessor#onApplicationEvent）;

圖片

在finishRegistration()中，分別做了哪些事呢？

第一，調用ScheduledAnnotationBeanPostProcessor#resolveSchedulerBean()查找任務調度器（TaskScheduler）；

第二，實際找到了ThreadPoolTaskScheduler作為實際的任務調度器，然后調用ScheduledTaskRegistrar#setTaskScheduler()完成任務調度器的配置；

第三，接著調用ScheduledTaskRegistrar#afterPropertiesSet()開始實際的任務觸發執行；不同類型的調度任務是在ScheduledTaskRegistrar#scheduleTasks()中完成判斷，然后分別調用各自的方法執行的；以cron表達式類型的調度任務為例，實際上最后由ScheduledTaskRegistrar#scheduleCronTask()實際完成。

至此，基于注解@Scheduled的調度任務實現原理基本分析完了，下面是我就調度任務的注冊和執行兩個時機為入口，繪制了整個過程的一個調用時序圖，供大家參考學習：

圖片

基于接口SchedulingConfigurer

基于接口SchedulingConfigurer的Springboot調度任務，與基于注解不同，其調度任務的注冊、執行都是在Spring容器啟動完成以后，發布ContextRefreshedEvent事件后，實現了Srping事件監聽器的接口（ApplicationListener）的ScheduledAnnotationBeanPostProcessor類的onApplicationEvent()被觸發，然后才開始調度任務的注冊和執行，下面具體分析一下：

第一步，查找所有SchedulingConfigurer接口的實現類，然后遍歷所有實現類并執行SchedulingConfigurer#configureTasks，就這么樸實無華，完成了所有通過實現SchedulingConfigurer接口(第四個核心關鍵類)的調度任務注冊；（第一個問題：調度任務是如何被注冊的，到這已經有答案了）

圖片

第二步，從ScheduledTaskRegistrar#afterPropertiesSet()進入開始調度任務的觸發執行階段（第二個問題，注冊的的調度任務是如何被執行的），afterPropertiesSet()中實際是調用了ScheduledTaskRegistrar#scheduleTasks()方法；

如果在實現SchedulingConfigurer接口，重寫configureTasks()，沒有顯性的指定任務調度器（TaskScheduler），在scheduleTasks()里，會初始化一個默認的任務調度器，這里要注意，默認的使用的是單線程的線程池；

圖片

接下來就是根據實際注冊的調度任務類型分別開始調度任務的實際執行了，在上一篇文章中，我注冊的是TriggerTasks類型的任務，所以這里就會調用ScheduledTaskRegistrar#scheduleTriggerTask()方法開始調度任務的執行。

圖片

圖片

至此，基于接口SchedulingConfigurer的Springboot調度任務的工作任務也基本分析完了，下面是整個過程的調用時序圖，大家可以參考一下：

圖片

核心類回顧

• @EnableScheduling，開啟Springboot任務調度功能的標識注解；
• SchedulingConfiguration，Springboot任務調度功能的自動配置類，作用是實例化ScheduledAnnotationBeanPostProcessor；
• ScheduledAnnotationBeanPostProcessor，調用任務的注冊、執行的觸發入口；
• SchedulingConfigurer，調度任務的擴展接口，允許用戶自定義調度任務的注冊；
• ScheduledTaskRegistrar，調度任務注冊中心，調用任務的實際管理者；

總結

通過分析Springboot兩種調度任務的實現方法的工作原理，有什么收獲呢？

第一，默認情況下，使用單線程的線程池來執行調度任務，性能上不會太高，適用場景有限；

第二，即便顯性的任務調度器配置了擁用較多線程的線程池，與現有其他業務同處一個工程，也會擠占其他業務的服務器資源；

所以，在實際使用過程中，應根據實際場景和資源配置進行選擇。