Quartz体系结构

任务调度场景的核心分为以时间为关注点的调度和资源上的调度。

以时间为关注点的调度如：微博禁言一周、冻结用户账号，在一周之内不能登录等

资源上的调度如：每执行一个任务都要开一个线程，无限制的使用必然耗尽亏空，大多数系统都要对资源使用进行控制——首先服务线程的最大数目必须限制，其次可以考虑使用线程池以便共享服务的线程资源，降低频繁创建、销毁线程的消耗。

任务调度本身涉及到多线程并发、运行时间规则制定及解析、运行现场保持与恢复、线程池维护等诸多方面的工作。

Quartz的核心主要包括三部分：任务（Job）、触发器（Trigger）和调度器（Scheduler），其中Scheduler是整个系统框架的心脏和灵魂。

1、任务Job

job是一个接口，只有一个方法void execute(JobExecutionContext context)，开发者实现该接口定义运行任务。

   JobExecutionContext类提供了调度上下文的各种信息，如获取执行中的JobDetail实例和执行完成后的Trigger对象。当Scheduler决定什么时候执行Job的时候，他会传JobExecutionContext给Job；JobExecutionContext包含了Quartz的运行环境和Job本身的明细数据，相当于ServletContext一样。

   JobDetail描述一个给定Job实例的详细信息。JobDetails是通过JobBuilder来创建和定义的。Quartz在每次执行Job时，都重新创建一个Job实例，所以它不直接接收实现Job接口的实例，相反，它接收一个实现Job接口的一个实现类，以便运行时通过newInstace()的反射机制实例化Job。因此需要一个类来描述Job的实现类及其他的相关信息，如Job类名、方法、描述、Key值、关联监听器等信息，JobDetail承担了这一角色。

   Job运行时的信息保存在JobDataMap实例中。当需要向Job传值的时候就可以通过JobDataMap传入。

Job状态

   有状态的Job（StateFulJob）：

在每次执行完Job后JobDataMap中的值就会存储到JobStore中去，所以在下次执行这个Job的时候，JobDataMap中的数据依然存在。可以通过Map中的put()去改变它的值

   无状态的Job（Job）：

任何时候执行完Job，JobDataMap中的数据都不会被持久化，所以每次创建Job的时候都要对JobDataMap进行数据的添加。

   两者区别

两个或者多个有状态的JobDetail实例都不能并发执行，如果一个有状态的JobDetail再创建两个Trigger来触发这个Job，一个每5分钟触发，另一个也是每5分钟触发，两个Tigger试图在同一时间去触发这个Job，框架是不允许这个的事情发生，第二个会一直被阻塞到第一个执行结束，这是基于安全的考虑

2、触发器Trigger

描述触发Job执行的触发时间规则。主要有SimpleTrigger和CronTrigger两个子类。当仅需触发一次或者以固定时间间隔周期执行，SimpleTrigger是最适合的选择；而CronTrigger则可以通过Cron表达式定义出各种复杂时间规则的调度方案：如周一、周三、周五下午5：00执行。

3、调度器（scheduler）

代表一个Quartz的独立运行容器，Trigger和JobDetails可以注册到Scheduler中，两者在Scheduler中拥有各自的组及名称，组及名称是Scheduler查找定位容器中某一对象的依据，Trigger的组及名称必须唯一，JobDetail的组和名称也必须唯一（但可以和Trigger的组和名称相同，因为它们是不同类型的）。Scheduler定义了多个接口方法，允许外部通过组及名称访问和控制容器中Trigger和JobDetail。

Scheduler可以将Trigger绑定到某一JobDetail中，这样当Trigger触发时，对应的Job就被执行。一个Job可以对应多个Trigger，但一个Trigger只能对应一个Job。可以通过SchedulerFactory创建一个Scheduler实例。