Spring+quatz 架构及源码详解

由于工作需要优化现有系统的spring+quartz中一些任务的执行策略，我特地花了几天时间看了spring+quartz的源码以及参考了网上相关的文章，现就做一下总结真理，其中主体结构和大部内容都是借鉴 “quatz学习笔记”这篇文章的，后面参考资料有链接。我按自己的思路重新做了解析和整理。下面开始介绍

一.前提知识点

1.InitializingBean 与 afterPorpertiesSet()

关于在spring 容器初始化 bean 和销毁前所做的操作定义方式有三种：

第一种：通过@PostConstruct 和 @PreDestroy 方法实现初始化和销毁bean之前进行的操作

第二种是：通过在xml中定义init-method 和 destory-method方法

第三种是：通过bean实现InitializingBean和 DisposableBean接口

Spirng的InitializingBean为bean提供了定义初始化方法的方式。InitializingBean是一个接口，它仅仅包含一个方法：afterPropertiesSet()。在spring 初始化后，执行完所有属性设置方法(即setXxx)将自动调用 afterPropertiesSet(), 在配置文件中无须特别的配置，但此方式增加了bean对spring 的依赖，应该尽量避免使用。

实现org.springframework.beans.factory.DisposableBean接口允许一个bean，可以在包含它的BeanFactory销毁的时候得到一个回调。DisposableBean也只指定了一个方法：

void destroy() throws Exception;

2.SmartLifecycle系列

有时候我们可能需要一些组件的功能随着spring容器的启动而启动（如新开启一个线程来进行监听），容器的销毁而销毁。为此spring提供了一个接口，从方法名字很容易看到方法的作用：

public interface Lifecycle {

void start();

void stop();

boolean isRunning(); //Check whether this component is currently running

}

当启动的时候，由于组件之间的依赖，启动的顺序是相当重要的。depends-on属性可以决定多个lifecycle的实现的顺序，但是有时候依赖是未知的。为此spring定义可一个新的接口，SmartLifecycle:

public interface Phased {

int getPhase(); //Return the phase value of this object. 调用优先级

}

public interface SmartLifecycle extends Lifecycle, Phased {

boolean isAutoStartup(); //是否自启动

void stop(Runnable callback);

}

isAutoStartup决定是随着容器的启动自启动，Phased接口定义的方法则决定了启动顺序，其返回值越小启动越早，越大启动越晚。如果一个Lifecycle未实现Phased接口，则默认其值为0.Stop方法可以异步的执行析构函数，spring默认会为每一个Phase等待30秒钟。这个时间是可以配置的。

二. spring+quartz源码学习

第一节.从入口开始

Quartz与Spring的整合，Spring提供一组Bean来支持。一下通过具体的配置来说明,一般情况下都是采用这样配置的：

实际上spring在加载时，通过SchedulerFactoryBean来创建scheduler实例并完成初始化的，现在我们就从这个入口源码开始看起：SchedulerFactoryBean的定义如下图，可以看到它实现了InitializingBean和SmartLifecycle接口（如不熟悉，可查看第一节），所以IOC容器初始化完成后会调用该类afterPropertiesSet方法，事实上分析代码可知整个quatz初始化(核心部分)即是在这里完成的，scheduler容器在此创建，同时该类在start()实现中启动了scheduler的线程。

具体来分析afterPropertiesSet()和start()，可以看出afterPropertiesSet()的核心步骤：

1. 实例化一个SchdulerFactory，此处使用的是默认的StdSchedulerFactory.class

2. 通过Factory获取一个scheduler实例容器。

3. 配置/添加对该容器指定的listener、jobs、triggers等，本质是将注入的上述属性配合到上步创建的Scheduler容器当中，比较简单，后续忽略介绍。

代码说明的截图：

start()择更为简单，直接启动上面创建的scheduler容器的实例，代码说明截图如下：其中有一个startupDelay的参数，即启动延时，默认都是为0的，一般也是需要即时启动的。

综上，可以看到quatz启动的大概步骤，利用spring提供的两个回调接口，分别在bean实例的构造和容器启动阶段实现了 Scheduler容器的构造和 scheduler的启动。

当然理解架构只到此程度是远远不够的，上述部分的核心是通过Factory获取到一个scheduler实例，即createScheduler()方法，下一节对这个过程做出详细的说明。

第二节.scheduler容器获取(构造)过程

首先，createScheduler()之中的主流程调用树结构如下，其核心是在instantiate()完成的，外部的2层主要做了些读取配置和条件判断等。

直接来看instantiate()的代码，类比较大且复杂，只列出核心行

1.创建了一个线程池，默认使用的是SimpleThreadPool，代码中tp对象

2.创建了一个jobStore，默认使用的是RAMJobStore，代码中的js对象

3.创建一个QuartzScheduler对象，代码中的qs对象, 下图列出他的创建树。

大体上有4步，有2个关键点需要掌握

a.QuartzScheduler对象保存有QuartzSchedulerThread的引用，实际的调度工作基本上是由QuartzSchedulerThread这个对象做的. 当然实例化QuartzScheduler的目的主要也在于去实例化QuartzSchedulerThread。

b.QuartzSchedulerThread在构造函数中实例化，并一经创建就自启动，它是一个独立的线程，至于自启后做什么，在后面章节说明。下面是quartzScheduler的创建过程

4.创建了scheduler.

4.1. QuartzSchedulerResources 对象，代码中的rsrcs对象

Contains all of the resources，可以将其视为资源缓存对象，包含了所有定时模块的资源的引用。

4.2. Scheduler对象。看源代码它的直接实例是StdScheduler，但实际StdScheduler中直接引用了QuartzScheduler（qs）且仅止于此，没有额外的动作。简单的你可以认为这是一层封装。因此你可以认为真正在工作的其实就是QuartzScheduler或者说是 QuartzSchedulerThread

本节主要讲述了整个scheduler容器创建时的过程，以及4个重要的步骤节点。后续章节来分别详述这些核心步骤的具体创建和工作原理。

至此，通过SchedulerFactory构建Scheduler的过程已完成，可以总结为三个要点。

1. 创建线程池

2. 创建JobStore

3. 通过QuartzScheduler启动一个QuartzSchedulerThread

他们的关系如下图，最终返回的这是QuatzScheduler的引用。本图转自网络。

第三节. 对第二节的一个小结

通过对上节真个启动过程的源码解读，应该可以较为深入的理解spring 管理的Quatz的启动流程，网络上一张时序图可以作为很好的参考：

第四节.QuartzSchedulerThread是如何工作的。

在第二节中讲到启动是一个核心步骤就是创建QuartzSchedulerThread并启动它，因为它是继承自Thread的，因此我们可以跟踪它的run方法看它究竟做哪些工作

解析这个方法如下：

1. 方法体是一个无限循环，一直在等任务的出现，然后启动执行。

2. 刚被启动时，是在等pause信号量。这个信号在何时改变了，也行你已经在上面时序图中看到了，前面章节提到的start()的实现其本质的工作就是修改这个pause信号量。使

QuartzSchedulerThread正式进入工作状态（虽然其构造时就被启动，但没有真正开始工作）。

3.总会从jobstore里找出下个应该执行的trigger任务（具体步骤后面解析），然后等待这一时刻到来。（通过不停的比较trigger的时间和当前系统时间）

4. 之后通过jobstore将其对应的jobdetail封装成一个runShell （具体步骤后面解析）

5. 将runShell交给线程池去执行，runInThread方法，下节会具体讲解。

6. 继续循环寻找下一个执行trigger，依次往复。

因此上面提到过其实在quartz里面，真正做实际工作的调度线程其实就是它。

第五节.SimpleThreadPool的介绍

总体来讲，SimpleThreadPool的实现很简单。

第2节介绍createScheduler过程时，提到第一个步骤便是创建一个线程池，该默认的线程池便是SimpleThreadPool. 跟踪源代码可见，最然构建tp实例时未做任何操作，但在实例之后，又调用了SimpleThreadPool.initialize(), 此方法相当于初始配置tp以及启用它。下面来分析源码

a.代码比较简单，注意一点是创建的线程是WorkerThread，因此看具体工作还需要追踪到WorkerThread里面。

B.WorkerThread是一个内部类，看下被启动是具体做什么工作（run方法）。

比较简单，“一直不停的在等待runable类型的事件的注入，一旦进来，就执行”。

本节和上节可以结合在一起归纳一下，QuartzSchedulerThread一直寻找可执行目标，找到后就交给SimpleThreadPool具体执行，而相应的SimpleThreadPool的线程们也被设计成随时等待runnable事件的注入。举个通俗的例子，QuartzSchedulerThread就是青楼的老妈子，SimpleThreadPool

里的线程就是待接客的姑娘们，老妈子负责不断寻找/接待客人，然后将目标客户引给闲置的姑娘，具体的接待工作由姑娘完成。

现在提出两个问题，“客人”是如何被找到的？ “姑娘”是如何开始接待的？在下节讨论。

6.RAMJobStore的介绍

JobStore负责保存所有配置到调度器里的工作数据：jobs，triggers，calendars等等,“RAM”顾名思义就是利用内存来持久化调度程序信息。这种作业存储类型最容易配置、构造和运行，但是当应用程序停止运行时，所有调度信息将被丢失。RAMJobStore是spring+quatz默认的jobstore

在第4节中讲解QuartzSchedulerThread的工作原理中多次提到了jobStore，其中有一个步骤便是通过jobStore获取下一个应该执行的trigger，现在就来具体分析。

A. 利用jobStore获取下一个需要执行的trigger, 此处调用的是acquireNextTrigger()方法。注意一点，在这步中一般情况下是先将第一个执行的trigger从treeset中删除，然后返回它。 treeset是按照触发是每个trigger最近一次应该执行的时间排序的。大概原理是这样的，1.往队列添加trigger的时候，是以该trigger的下次触发时间来

确定它在treeset的顺序 2.要执行trigger时，是直接将trigger移出treeset. 3.在恰当的时刻，将该trigger按照第一步加入到treeset