前言

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

核心問題

關(guān)于Springboot調(diào)度任務(wù)的工作原理，實際就是兩個問題：

第一個問題，調(diào)度任務(wù)是如何被注冊的？

第二個問題，注冊的調(diào)度任務(wù)是如何觸發(fā)執(zhí)行的？

實現(xiàn)方法

關(guān)于Springboot調(diào)度任務(wù)的具體實現(xiàn)方法已經(jīng)在上一篇文章中詳細介紹過，這里再作一下簡單的梳理、歸納，主要兩種方法：

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

兩種方法都需要使用@EnableScheduling（第一個核心關(guān)鍵類）來開啟調(diào)度任務(wù)功能。

基于注解@Scheduled

基于注解@Scheduled內(nèi)的屬性，可以分為三類調(diào)度任務(wù)：

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

基于接口SchedulingConfigurer

實現(xiàn)SchedulingConfigurer接口，并重寫configureTasks()方法，在重寫configureTasks()里，完成調(diào)度任務(wù)的注冊；

工作原理

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

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

順著SchedulingConfiguration.class進入其內(nèi)部，又發(fā)現(xiàn)了一個大秘密：ScheduledAnnotationBeanPostProcessor（第三個核心關(guān)鍵類）

@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對象初始化前后回調(diào)BeanPostProcessor中定義的兩個方法：
• postProcessBeforeInitialization()方法會在每一個bean對象的初始化方法調(diào)用之前回調(diào)；postProcessAfterInitialization()方法會在每個bean對象的初始化方法調(diào)用之后被回調(diào)

基于注解@Scheduled與基于接口SchedulingConfigurer調(diào)度任務(wù)實現(xiàn)入口是一樣的，其具體實現(xiàn)是不一樣的。

基于注解@Scheduled

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

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

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

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

圖片

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

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

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

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

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

圖片

基于接口SchedulingConfigurer

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

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

圖片

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

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

圖片

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

圖片

圖片

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

圖片

核心類回顧

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

總結(jié)

通過分析Springboot兩種調(diào)度任務(wù)的實現(xiàn)方法的工作原理，有什么收獲呢？

第一，默認情況下，使用單線程的線程池來執(zhí)行調(diào)度任務(wù)，性能上不會太高，適用場景有限；

第二，即便顯性的任務(wù)調(diào)度器配置了擁用較多線程的線程池，與現(xiàn)有其他業(yè)務(wù)同處一個工程，也會擠占其他業(yè)務(wù)的服務(wù)器資源；

所以，在實際使用過程中，應(yīng)根據(jù)實際場景和資源配置進行選擇。