【quartz】 理论知识

属性的介绍

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

二、线程池属性：这些线程在 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，它可以知足大多数用户的需求。这个线程池实现具有简单的行为，并经很好的测试过。它在调度器的生命周期中提供固定大小的线程池。你能根据需求建立本身的线程池实现，若是你想要一个随需可伸缩的线程池时也许须要这么作。这个属性没有默认值，你必须为其指定值。

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

四、其余插件属性：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 时可要谨慎了