Quartz是开源任务调度框架中的翘楚,它提供了强大的 任务调度机制。Quartz允许开发人员灵活的定义触发器的调度时间表,并可对触发器和任务进行关联映射。此外,Quartz提供了调度运行环境的持久化机制,可以保存并恢复调度现场,即使系统因故障关闭,任务调度现场数据并不会丢失。此外,Quartz还提供了组件式的侦听器、各种插件、线程池等功能。
一、Quartz基础结构
Quartz对任务调度的领域问题进行了高度抽象,提出了调度器、任务和触发器这3个核心的概念,并在org.quartz通过接口和类的核心概念进行描述。
1)Job:是一个接口,只有一个方法void execute(JobExecutionContext context) ,开发者实现该接口定义需要执行的任务,JobExecutionContext类提供了调度上下文的各种信息。Job运行时的信息保存在JobDataMap实例中。
2)JobDetail:Quartz在每次执行Job时,都重新创建一个Job实例,所以它不是直接接受一个Job的实例,而是接收一个Job实现类,以便运行时通过newInstance()的反射调用的机制实例化Job。因此需要通过一个类来描述Job的实现类及其他相关的静态信息,如Job名称、描述、关联监听器等信息,JobDetail承担了这一角色。通过该类的构造函数可以更具体地了解它的功用:JobDetail(java.lang.String name,java.lang.String group,java.lang.Class jobClass),该构造函数要求指定Job的实现类,以及任务在Scheduler中的组名和Job名称。
3)Trigger:是一个类,描述触发Job执行的时间触发规则。主要有SimpleTrigger和CronTrigger这两个子类。当仅需要触发一次或者以固定间隔周期性执行,SimplegTrigger是最适合的选择;而CronTrigger则可以通过Cron表达式定义出各种复杂的调度方案:如每天早晨9:00执行,每周一、周三、周五下午5:00执行等。
4)Calendar:org.quartz.Calendar和java.util.Calendar不同,它是一些日历特定时间点的集合(可以简单地将org.quartz.Calendar看作java.util.Calendar的集合------java.util.Calendar代表一个日历时间点,无特殊说明后面的Calendar即指org.quartz.Calendar).一个Trigger可以和多个Calendar关联,以便排除或包含某些时间点。假设,我们安排每周星期一早上10:00执行任务,但是如果碰到法定的节日,任务则不执行,这时就需要在Trigger触发机制的基础上使用Calendar进行定点排除。针对不同的时间段类型,Quartz在org.quartz.impl.calendar包下提供了若干个Calendar的实现类,如AnnualCalendar、MonthlyCalendar、WeekleyCalendar分别针对每年、每月和每周进行定义。
5)Scheduler:代表一个Quartz的独立运行容器,Trigger和JobDetail可以注册到Scheduler中,两者在Scheduler中拥有各自的组及名称。组及名称是Scheduler查找定位容器中某一对象的依据,Trigger的组及名称的组合必须唯一,JobDetail的组和名称的组合也必须唯一(但可以和Trigger的组和名称相同,因为它们是不同类型的,处在不同的集合中)。Scheduler定义了多个接口方法,允许外部通过组及名称访问和控制容器中的Trigger和JobDetail。Scheduler可以将Trigger绑定到某一JobDetail中,这样当Trigger被触发时,对应的Job就被执行。一个Job可以对应多个Trigger,但一个Trigger只能对应一个Job. 可以通过SchedulerFactory创建一个Scheduler实例。Scheduler拥有一个SchedulerContext,保存着Scheduler上下文信息,可以对照你熟悉的ServletContext来理解SchedulerContext。Job和Trigger都可以访问SchedulerContext内的信息。SchedulerContext内部通过个Map,以键值对的方式维护这些上下文数据,SchedulerContext为保存和获取数据提供了多个put()和getXxx方法。可以通过Scheduler#getContext()获取对应的SchedulerContext实例。
6)ThreadPool:Scheduler使用一个线程池作为任务运行的基础设施,任务通过共享线程池中的线程提高运行效率。
二、有状态的任务和无状态的任务
Job有一个StatefulJob子接口,代表有状态的任务,该接口是一个没有方法的标签接口,其目的就是让Quartz知道任务的类型,以便采取不同的执行方案。无状态任务在执行时拥有自己的JobDataMap复制,对JobDataMap的更改不会影响下次的执行。而有状态的任务共享一个JobDataMap实例,每次任务执行时对JobDataMap所做的更改会保存下来,后面的执行可以看到这个更改,即每次执行任务后都会对后面的执行发生影响。
正因为这个原因,无状态的Job可以并发执行,而有状态的StatefulJob不能并发执行,这意味着如果前次的StatefulJob还没有执行完毕,下一次的任务将阻塞等待,直到前次任务执行完毕。有状态任务比无状态任务需要考虑更多的因素,程序往往更复杂,因此除非必要,应尽量避免使用有状态的Job.
如果Quartz使用了数据库持久化任务调度信息,无状态的JobDataMap仅会在Scheduler注册任务时保存一次,而有状态任务对应的JobDataMap在每次执行任务后都会进行保存。
Trigger自身也可以拥有一个JobDataMap,期关联的JobDataMap可以通过JobExecutionContext#getTrigger().getJobDataMap获取。不管有状态还是无状态的任务,在任务执行期间对Trigger的JobDataMao所做的更改都不会进行持久化,即不会对下次任务的执行产生影响。
Quartz拥有完善的事件和监听体系,大部分组件都拥有事件、如任务执行前事件、任务执行后事件、触发器触发前事件、触发后事件、调度器开始事件、关闭事件等,可以注册相应的监听器处理感兴趣的事件。
Quartz拥有完善的事件和监听体系,大部分组件都拥有事件、如任务执行前事件、任务执行后事件、触发器触发前事件、触发后事件、调度器开始事件、关闭事件等,可以注册相应的监听器处理感兴趣的事件。
下图描述了Scheduler的内部组件结构,SchedulerContext提供Scheduler全局可见的上下文信息,每一个任务都对应一个JobDataMap,虚线表达的JobDataMap表示对应有状态的任务:
一个Scheduler可以拥有多个Trigger和多个JobDetail,它们可以分到不同的组中。注册Trigger和JobDetail时,如果不显示指定所属的组,Scheduler将放入到默认组中,默认组的组名为Scheduler.DEFAULT_GROUP。组名和名称组成了对象的全名。同一类型对象(即Job或Trigger)的全名不能相同。
Scheduler本身就是一个容器,它维护者Quartz的各种组件并实施调度的规则。Scheduler还拥有一个线程池,线程池为任务提供执行线程-----这比执行任务时简单的创建一个新线程要拥有更高的效率,同时通过共享机制减少资源的占用。通过线程池组件的支持,对于繁忙度高、压力大的任务调度,Quartz可以提供良好的伸缩性。
注:Quartz完整下载包examples目录下拥有10多个实例,它们是快速掌握Quartz应用很好的实例.