【quartz】 理论知识

属性的介绍

1.调度器属性：分别设置调度器的实例名(instanceName) 和实例 ID (instanceId)。属性 org.quartz.scheduler.instanceName 可以是你喜欢的任何字符串。默认名字一般都采用QuartzScheduler，第二个属性org.quartz.scheduler.instanceId和instaneName 属性一样，instanceId 属性也允许任何字符串。这个值必须是在所有调度器实例中是唯一的，尤其是在一个集群当中。假如你想 Quartz 帮你生成这个值的话，可以设置为 AUTO。

2、线程池属性：这些线程在 Quartz 中是运行在后台担当重任的。threadCount 属性控制了多少个工作者线程被创建用来处理 Job。原则上是，要处理的 Job 越多，那么需要的工作者线程也就越多。threadCount 的数值至少为 1。Quartz 没有限定你设置工作者线程的最大值，但是在多数机器上设置该值超过100的话就会显得相当不实用了，特别是在你的 Job 执行时间较长的情况下。这项没有默认值，所以你必须为这个属性设定一个值。

threadPriority 属性设置工作者线程的优先级。优先级别高的线程比级别低的线程更优先得到执行。threadPriority 属性的最大值是常量 java.lang.Thread.MAX_PRIORITY，等于10。最小值为常量 java.lang.Thread.MIN_PRIORITY，为1。这个属性的正常值是 Thread.NORM_PRIORITY，为5。大多情况下，把它设置为5，这也是没指定该属性的默认值。

最后一个要设置的线程池属性是 org.quartz.threadPool.class。这个值是一个实现了 org.quartz.spi.ThreadPool 接口的类的全限名称。Quartz 自带的线程池实现类是 org.quartz.smpl.SimpleThreadPool，它能够满足大多数用户的需求。这个线程池实现具备简单的行为，并经很好的测试过。它在调度器的生命周期中提供固定大小的线程池。你能根据需求创建自己的线程池实现，如果你想要一个随需可伸缩的线程池时也许需要这么做。这个属性没有默认值，你必须为其指定值。

3、作业存储属性：作业存储部分的设置描述了在调度器实例的生命周期中，Job 和 Trigger 信息是如何被存储的。把调度器信息存储在内存中非常的快也易于配置。当调度器进程一旦被终止，所有的 Job 和 Trigger 的状态就丢失了。要使 Job 存储在内存中需通过设置 org.quartz.jobStrore.class 属性为 org.quartz.simpl.RAMJobStore，在Cron Trigger 和“作业存储和持久化”会用到的不同类型的作业存储实现。

4、其他插件属性：org.quartz.plugin.jobInitializer.class = org.quartz.plugins.xml.JobInitializationPlugin默认时，JobInitializationPlugin插件会在 classpath 中搜索名为 quartz_jobs.xml 的文件并从中加载 Job 和 Trigger 信息。其他插件后叙……

org.quartz.Job 接口

把 Quartz 作用到 Java 类上唯一要做的就是让它实现 org.quartz.Job 接口。你的 Job 类可以实现任何其他想要的接口或继承任何需要的基类，但是它自己或是它的超类必须实现这个 Job 接口。这个 Job 接口只定义了单个方法：
public void execute(JobExecutionContext context) throws JobExecutionException;

当 Scheduler 决定了是时候运行 Job 时，方法 execute() 就会被调用，并传递一个 JobExecutionContext 对象给这个 Job。Quartz 加给方法 execute() 要承担的唯一合约责任就是如果在 Job 中出现严重问题时，必须抛出一个 org.quartz.JobExecutionException 异常

JobExecutionContext

当 Scheduler 调用一个 Job，一个 JobexecutionContext 传递给 execute() 方法。JobExecutionContext 对象让 Job 能访问 Quartz 运行时候环境和 Job 本身的明细数据。这就类似于在 Java Web 应用中的 servlet 访问 ServletContext 那样。通过 JobExecutionContext，Job 可访问到所处环境的所有信息，包括注册到 Scheduler 上与该 Job 相关联的 JobDetail 和 Triiger。Quartz Job 的一个非常基础的代码。PrintInfoJob 获得存储在 JobExecutionContext 中的 JobDetail 对象.

public class PrintInfoJob implements Job {
public void execute(JobExecutionContext context) throws JobExecutionException {
JobDetail jobDetail = context.getJobDetail();
}}

JobDetail

从以前的例子可以看的出JobDetail 被加到 Scheduler 中了，而不是 job。Job 类是作为 JobDetail 的一部份，但是它直到 Scheduler 准备要执行它的时候才会被实例化的。

Job 的实例要到该执行它们的时候才会实例化出来。每次 Job 被执行，一个新的 Job 实例会被创建。其中暗含的意思就是你的 Job 不必担心线程安全性，因为同一时刻仅有一个线程去执行给定 Job 类的实例，甚至是并发执行同一 Job 也是如此。

使用 JobDataMap 对象设定 Job 状态

你能使用 org.quartz.JobDataMap 来定义 Job 的状态。JobDataMap 通过它的超类 org.quartz.util.DirtyFlagMap 实现了 java.util.Map 接口，你可以向 JobDataMap 中存入键/值对，那些数据对可在你的 Job 类中传递和进行访问。这是一个向你的 Job 传送配置的信息便捷方法。通过 JobExecutionContext 对象访问 JobDataMap， JobDataMap jobDataMap =context.getJobDetail().getJobDataMap();当你获得了 JobDataMap，你可以当它是任何 map 实例一样调用它的方法。一般的，你会自己选择一个预定义的键值来访问 JobDataMap 中的数据。在 Quartz 1.5 中，JobDataMap 在 Trigger 级也是可用的。它的用途类似于 Job 级的 JobDataMap，此外它还能支持应用在同一个 JobDetail 上的多个 Trigger 上。伴随着加入到 Quartz 1.5 中的这一增强特性，可以使用 JobExecutionContext 的一个新的更方便的方法获取到 Job 和 Trigger 级的并集的 map 中的值。这个方法就是 getMergedJobDataMap()，它能够在 Job 中使用。从 Quartz 1.5 之后，使用这个方法被认为是获取 JobDataMap 最佳实践。

无状态的 Job

信息可插入到 JobDataMap 中然后被 Job 访问到。然而，对于每一次的 Job 执行，都会为特定的 Job 取用存储在某处(例如，数据库中)的值创建一个新的 JobDataMap 实例。因此，无法为两次 Job 调用之间持有那些信息，除非你使用有状态的 Job.

使用有状态的 Job

当你需要在两次 Job 执行间维护状态的话，Quartz 框架为此提供了 org.quartz.StatefulJob 接口。StatefulJob 接口仅仅是扩展了 Job 接口，未加入新的方法。你只需要通过使用与 Job 接口相同的 execute() 方法简单的实现 StatefulJob 接口即可。假如你有已存在的 Job 类，你所有要做的只是改变 Job 的接口为 org.quartz.StatefulJob。

Job 和 StatefulJob 在框架中使用中存在两个关键差异。首先，JobDataMap 在每次执行之后重新持久化到 JobStore 中。这样就确保你对 Job 数据的改变直到下次执行仍然保持着。你可以在有状态 Job 中简单的通过 map 的 put() 方法来修改 JobDataMap.已存在的任何数据会被新的数据覆盖掉。你也能对无状态的 Job 这么做，但是因为对于无状态 Job 来说，JobDataMap 不会持久化，所以数据不会保存下来。对于 Trigger 和 JobExecutionContext 上的 JobDataMap 的数据修改也是没能保存下来的。

另一个无状态和有状态

Job 重大区别就是：两个或多个有状态的 JobDetail 实例不能并发执行。说的是你创建并注册了一个有状态 JobDetail 到 Scheduler 上。你还建立了两个 Trigger 来触发这个 Job：一个每五分钟触发，另一个也是每五分钏触发。假如这两个 Trigger 试图在同一时刻触发 Job，框架是不允许这种事情发生的。第二个 Trigger 一直会被阻塞直到第一个结束。

在你使用 StatefulJob 时可要谨慎了