Quartz作业调度

备注：若有不正之处，请多谅解并欢迎批评指正。转载请标明链接：https://www.cnblogs.com/pmbb/p/11471430.html 

你了解 Quartz 吗？

Quartz 是一个完全由 Java 编写的开源作业调度框架，为在 Java 应用程序中进行作业调度提供了简单却强大的机制。

Quartz 可以与 J2EE 与 J2SE 应用程序相结合也可以单独使用。

Quartz 允许程序开发人员根据时间的间隔来调度作业。

Quartz 实现了作业和触发器的多对多的关系，还能把多个作业与不同的触发器关联。

Quartz 核心概念

1.Job 表示一个工作，要执行的具体内容。此接口中只有一个方法，如下：

void execute(JobExecutionContext context) 

2.JobDetail 表示一个具体的可执行的调度程序，Job 是这个可执行程调度程序所要执行的内容，另外 JobDetail 还包含了这个任务调度的方案和策略。 

3.Trigger 代表一个调度参数的配置，什么时候去调。 

4.Scheduler 代表一个调度容器，一个调度容器中可以注册多个 JobDetail 和 Trigger。当 Trigger 与 JobDetail 组合，就可以被 Scheduler 容器调度了。

Quartz快速入门指南

• 下载Quartz
• 安装Quartz
• 根据您自己的特殊需求配置Quartz
• 启动示例应用程序

下载并安装

首先，下载最新的稳定版本 - 不需要注册。打开发行版的包装并安装它，以便您的应用程序可以看到它。

Quartz JAR文件

quartz安装包根目录的lib/目录下有很多的jar包。其中，quartz-xxx.jar（其中xxx是版本号）是最主要的。为了使用quartz，必须将该jar包放在应用的classpath下；

下载后，解压，然后将quartz-xxx.jar放到你的应用中。

我主要是在应用服务器的环境中使用quartz，所以一般将quartz jar包放到应用中（.ear或.war）。当然，如果你希望在很多应用中使用quartz，将quartz的jar包放在应用服务器(appserver)的classpath下即可。如果你只是希望在独立的应用中使用quartz，将quartz的jar包和你的应用依赖的其它jar包放在一起即可。

quzrtz依赖一些第三方的库（以jar包的形式），这些库位于quartz安装包的lib目录下。要使用quartz的所有功能，必须将所有的第三方jar包都放到classpath下。如果你开发的是一个独立的quartz应用，建议将所有的jar包都放到classpath下；如果是在应用服务器环境下使用quartz，其中有些包可能已经存在于classpath中了，因此你需要自己选择。

在应用服务器环境下，如果同一个jar文件，存在两个不同的版本，要注意，可能会产生一些奇怪的结果；
比如，WebLogic包含了一个J2EE的实现（在weblogic.jar中），该实现与servlet.jar的实现可能不一致。
此时，应该从你的应用中排除掉servlet.jar，这样你就知道使用的是哪个类了。

属性文件

quartz使用名为quartz.properties的配置文件。刚开始时该配置文件不是必须的，但是为了使用最基本的配置，该文件必须位于classpath下。

基于我的个人情况举个例子，我的应用是基于WebLogic Workshop开发的。我将所有的配置文件（包括quartz.properties）放到应用根目录下的一个项目中。当我将项目打包成.ear文件时，放置配置文件的项目会以jar包的形式进入最终的.ear包，所以quartz.properties文件就自动位于classpath中了。

如果你准备构建一个使用quartz的web应用（以.war包的形式），你应该将quartz.properties文件放到WEB-INF/classes目录下。

组态

这里包含很多内容。quartz是一个配置很灵活的应用。配置quartz最好的方式是，编辑quartz.properties文件，然后放到应用的classpath下。

quartz的安装包中包含了一些配置文件的示例，位于example/目录下。我建议你创建自己的quartz.properties文件，而不是简单地从示例中拷贝并删除不需要的部分。这样看起来更整洁，而且你也会了解到quartz的更多功能。

关于quartz配置文件的详细文档，请查阅Quartz配置参考

为了使用quartz，一个基本的quartz.properties配置文件如下所示：

org.quartz.scheduler.instanceName = MyScheduler
org.quartz.threadPool.threadCount = 3
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

由此配置创建的scheduler具有以下特征：

• org.quartz.scheduler.instanceName - 此调度程序的名称将为“MyScheduler”。
• org.quartz.threadPool.threadCount - 线程池中有3个线程，这意味着最多可以同时运行3个job。
• org.quartz.jobStore.class quartz的所有数据，包括job和trigger的配置，都会存储在内存中（而不是数据库里）。如果你想使用quartz的数据库存储功能（校对注：设置成另外一个类），我们建议在使用数据库存储之前，先使用内存存储（RamJobStore）。

启动示例应用程序

下载和安装完quartz后，是时候开发一个示例应用，并让它跑起来了。下面的示例代码，获取scheduler实例对象，启动，然后关闭。

QuartzTest.java

import org.quartz.Scheduler; 
import org.quartz.SchedulerException; 
import org.quartz.impl.StdSchedulerFactory; 
import static org.quartz.JobBuilder.*; 
import static org.quartz.TriggerBuilder.*; 
import static org.quartz.SimpleScheduleBuilder.*; 
public class QuartzTest {
 public static void main(String[] args) { 
try { 
// Grab the Scheduler instance from the Factory 
Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler(); 
// and start it off 
scheduler.start(); 
scheduler.shutdown(); } 
catch (SchedulerException se) {
 se.printStackTrace(); 
    } 
  } 
}  

• 当你调用StdSchedulerFactory.getDefaultScheduler()获取scheduler实例对象后，在调用scheduler.shutdown()之前，scheduler不会终止，因为还有活跃的线程在执行。。

注意示例代码中的静态导入(static import)，下面的代码中也会用到它们。

如果你没有配置日志输出，所有的日志会输出到控制台.

你可以在start()和shutdown()之间做一些有趣的事情：

// define the job and tie it to our HelloJob class 
JobDetail job = newJob(HelloJob.class) 
.withIdentity("job1", "group1") 
.build(); 
// Trigger the job to run now, and then repeat every 40 seconds Trigger trigger = newTrigger() 
.withIdentity("trigger1", "group1") 
.startNow() 
.withSchedule(simpleSchedule() 
.withIntervalInSeconds(40) 
.repeatForever()) 
.build(); 
// Tell quartz to schedule the job using our trigger scheduler.scheduleJob(job, trigger);

在调用shutdown()之前，你需要给job的触发和执行预留一些时间，比如，你可以调用Thread.sleep(60000)让线程睡眠一段时间。

Quartz API

Quartz API的关键接口是：

• Scheduler - 与调度程序交互的主要API。
• Job - 由希望由调度程序执行的组件实现的接口。
• JobDetail - 用于定义作业的实例。
• Trigger（即触发器） - 定义执行给定作业的计划的组件。
• JobBuilder - 用于定义/构建JobDetail实例，用于定义作业的实例。
• TriggerBuilder - 用于定义/构建触发器实例。

Scheduler的生命期，从SchedulerFactory创建它时开始，到Scheduler调用shutdown()方法时结束；Scheduler被创建后，可以增加、删除和列举Job和Trigger，以及执行其它与调度相关的操作（如暂停Trigger）。但是，Scheduler只有在调用start()方法后，才会真正地触发trigger（即执行job），见教程一。

Quartz提供的“builder”类，可以认为是一种领域特定语言（DSL，Domain Specific Language)。定义job的代码使用的是从JobBuilder静态导入的方法。

定义job的代码使用的是从JobBuilder静态导入的方法。同样，定义trigger的代码使用的是从TriggerBuilder静态导入的方法 。 另外，也导入了SimpleSchedulerBuilder类的静态方法；

DSL的静态导入可以通过以下导入语句来实现：

import static org.quartz.JobBuilder.*; 
import static org.quartz.SimpleScheduleBuilder.*; 
import static org.quartz.CronScheduleBuilder.*; 
import static org.quartz.CalendarIntervalScheduleBuilder.*; 
import static org.quartz.TriggerBuilder.*; 
import static org.quartz.DateBuilder.*;

SchedulerBuilder接口的各种实现类，可以定义不同类型的调度计划（schedule）；

DateBuilder类包含很多方法，可以很方便地构造表示不同时间点的java.util.Date实例（如定义下一个小时为偶数的时间点，如果当前时间为9:43:27，则定义的时间为10:00:00）。

Job和Trigger

一个job就是一个实现了Job接口的类，该接口只有一个方法：

Job接口：

package org.quartz; 
public interface Job { 
public void execute(JobExecutionContext context) 
throws JobExecutionException; 
}

当Job的一个trigger被触发（稍后会讲到）时，execute（）方法由调度程序的一个工作线程调用。传递给execute()方法的JobExecutionContext对象向作业实例提供有关其“运行时”环job的一个trigger被触发后（稍后会讲到），execute()方法会被scheduler的一个工作线程调用；传递给execute()方法的JobExecutionContext对象中保存着该job运行时的一些信息 ，执行job的scheduler的引用，触发job的trigger的引用，JobDetail对象引用，以及一些其它信息。

JobDetail对象是在将job加入scheduler时，由客户端程序（你的程序）创建的。它包含job的各种属性设置，以及用于存储job实例状态信息的JobDataMap。本节是对job实例的简单介绍，更多的细节将在下一节讲到。Trigger用于触发Job的执行。当你准备调度一个job时，你创建一个Trigger的实例，然后设置调度相关的属性。Trigger也有一个相关联的JobDataMap，用于给Job传递一些触发相关的参数。Quartz自带了各种不同类型的Trigger，最常用的主要是SimpleTrigger和CronTrigger。

SimpleTrigger主要用于一次性执行的Job（只在某个特定的时间点执行一次），或者Job在特定的时间点执行，重复执行N次，每次执行间隔T个时间单位。CronTrigger在基于日历的调度上非常有用，如“每个星期五的正午”，或者“每月的第十天的上午10:15”等。

为什么既有Job，又有Trigger呢？很多任务调度器并不区分Job和Trigger。有些调度器只是简单地通过一个执行时间和一些job标识符来定义一个Job；其它的一些调度器将Quartz的Job和Trigger对象合二为一。在开发Quartz的时候，我们认为将调度和要调度的任务分离是合理的。在我们看来，这可以带来很多好处。

例如，Job被创建后，可以保存在Scheduler中，与Trigger是独立的，同一个Job可以有多个Trigger；这种松耦合的另一个好处是，当与Scheduler中的Job关联的trigger都过期时，可以配置Job稍后被重新调度，而不用重新定义Job；还有，可以修改或者替换Trigger，而不用重新定义与之关联的Job。

Key

将Job和Trigger注册到Scheduler时，可以为它们设置key，配置其身份属性。Job和Trigger的key（JobKey和TriggerKey）可以用于将Job和Trigger放到不同的分组（group）里，然后基于分组进行操作。同一个分组下的Job或Trigger的名称必须唯一，即一个Job或Trigger的key由名称（name）和分组（group）组成。

您现在有一个关于什么Job和触发器的一般概念，您可以在第3课中了解更多信息有关作业和作业详细信息以及第4课：有关触发器的更多信息。

Job与JobDetail介绍

本节主要关注：Job的特点、Job接口的execute方法以及JobDetail。

你定义了一个实现Job接口的类，这个类仅仅表明该job需要完成什么类型的任务，除此之外，Quartz还需要知道该Job实例所包含的属性；这将由JobDetail类来完成。

JobDetail实例是通过JobBuilder类创建的，导入该类下的所有静态方法，会让你编码时有DSL的感觉：

import static org.quartz.JobBuilder.*;

让我们先看看Job的特征（nature）以及Job实例的生命期。不妨先回头看看第1课中的代码片段：

现在考虑这样定义的作业类“HelloJob”：

public class HelloJob implements Job {
public HelloJob() { }
public void execute(JobExecutionContext context) throws JobExecutionException {
System.err.println("Hello! HelloJob is executing."); 
   } 
}

可以看到，我们传给scheduler一个JobDetail实例，，因为我们在创建JobDetail时，将要执行的job的类名传给了JobDetail，所以scheduler就知道了要执行何种类型的job；每次当scheduler执行job时，在调用其execute(…)方法之前会创建该类的一个新的实例；执行完毕，对该实例的引用就被丢弃了，实例会被垃圾回收；这种执行策略带来的一个后果是，job必须有一个无参的构造函数（当使用默认的JobFactory时）；另一个后果是，在job类中，不应该定义有状态的数据属性，因为在job的多次执行中，这些属性的值不会保留。那么如何给job实例增加属性或配置呢？如何在job的多次执行中，跟踪job的状态呢？答案就是:JobDataMap，JobDetail对象的一部分。

JobDataMap

JobDataMap中可以包含不限量的（序列化的）数据对象，在job实例执行的时候，可以使用其中的数据；

JobDataMap是Java Map接口的一个实现，额外增加了一些便于存取基本类型的数据的方法。

将job加入到scheduler之前，在构建JobDetail时，可以将数据放入JobDataMap，如下示例：

// define the job and tie it to our DumbJob class 
JobDetail job = newJob(DumbJob.class) 
.withIdentity("myJob", "group1") // name "myJob", group "group1" 
.usingJobData("jobSays", "Hello World!") 
.usingJobData("myFloatValue", 3.141f) 
.build();

在job的执行过程中，可以从JobDataMap中取出数据，如下示例：

public class DumbJob implements Job {
public DumbJob() { }
public void execute(JobExecutionContext context)
throws JobExecutionException
{ JobKey key = context.getJobDetail().getKey();
JobDataMap dataMap = context.getJobDetail().getJobDataMap();
String jobSays = dataMap.getString("jobSays");
float myFloatValue = dataMap.getFloat("myFloatValue");
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);

  } 
}

如果你使用的是持久化的存储机制（本教程的JobStore部分会讲到），在决定JobDataMap中存放什么数据的时候需要小心，因为JobDataMap中存储的对象都会被序列化，因此很可能会导致类的版本不一致的问题；Java的标准类型都很安全，如果你已经有了一个类的序列化后的实例，某个时候，别人修改了该类的定义，此时你需要确保对类的修改没有破坏兼容性；更多细节，参考现实中的序列化问题。另外，你也可以配置JDBC-JobStore和JobDataMap，使得map中仅允许存储基本类型和String类型的数据，这样可以避免后续的序列化问题。如果你在job类中，为JobDataMap中存储的数据的key增加set方法（如在上面示例中，增加setJobSays(String val)方法），那么Quartz的默认JobFactory实现在job被实例化的时候会自动调用这些set方法，这样你就不需要在execute()方法中显式地从map中取数据了。

在Job执行时，JobExecutionContext中的JobDataMap为我们提供了很多的便利。它是JobDetail中的JobDataMap和Trigger中的JobDataMap的并集，但是如果存在相同的数据，则后者会覆盖前者的值。

下面的示例，在job执行时，从JobExecutionContext中获取合并后的JobDataMap：

public class DumbJob implements Job {
public DumbJob() { }
public void execute(JobExecutionContext context) 
throws JobExecutionException {
JobKey key = context.getJobDetail().getKey(); 
JobDataMap dataMap = context.getMergedJobDataMap();
// Note the difference from the previous example
String jobSays = dataMap.getString("jobSays");
float myFloatValue = dataMap.getFloat("myFloatValue");
ArrayList state = (ArrayList)dataMap.get("myStateData");
state.add(new Date());
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);
  } 

}

如果你希望使用JobFactory实现数据的自动“注入”，则示例代码为：

public class DumbJob implements Job {
String jobSays;
float myFloatValue;
ArrayList state;
public DumbJob() { }

public void execute(JobExecutionContext context) 
throws JobExecutionException {
JobKey key = context.getJobDetail().getKey();
JobDataMap dataMap = context.getMergedJobDataMap();// Note the difference from the previous example
state.add(new Date());
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);
}
public void setJobSays(String jobSays) { this.jobSays = jobSays; }
public void setMyFloatValue(float myFloatValue) { myFloatValue = myFloatValue; }

public void setState(ArrayList state) { state = state; } 
}

你也许发现，整体上看代码更多了，但是execute()方法中的代码更简洁了。而且，虽然代码更多了，但如果你的IDE可以自动生成setter方法，你就不需要写代码调用相应的方法从JobDataMap中获取数据了，所以你实际需要编写的代码更少了。当前，如何选择，由你决定。

Job实例

很多用户对于Job实例到底由什么构成感到很迷惑。我们在这里解释一下，并在接下来的小节介绍job状态和并发。你可以只创建一个job类，然后创建多个与该job关联的JobDetail实例，每一个实例都有自己的属性集和JobDataMap，最后，将所有的实例都加到scheduler中。

比如，你创建了一个实现Job接口的类“SalesReportJob”。该job需要一个参数（通过JobdataMap传入），表示负责该销售报告的销售员的名字。因此，你可以创建该job的多个实例（JobDetail），比如“SalesReportForJoe”、“SalesReportForMike”，将“joe”和“mike”作为JobDataMap的数据传给对应的job实例。

当一个trigger被触发时，与之关联的JobDetail实例会被加载，JobDetail引用的job类通过配置在Scheduler上的JobFactory进行初始化。默认的JobFactory实现，仅仅是调用job类的newInstance()方法，然后尝试调用JobDataMap中的key的setter方法。你也可以创建自己的JobFactory实现，比如让你的IOC或DI容器可以创建/初始化job实例。

在Quartz的描述语言中，我们将保存后的JobDetail称为“job定义”或者“JobDetail实例”,将一个正在执行的job称为“job实例”或者“job定义的实例”。当我们使用“job”时，一般指代的是job定义，或者JobDetail；当我们提到实现Job接口的类时，通常使用“job类”。

Job状态与并发

关于job的状态数据（即JobDataMap）和并发性，还有一些地方需要注意。在job类上可以加入一些注解，这些注解会影响job的状态和并发性。

@DisallowConcurrentExecution：将该注解加到job类上，告诉Quartz不要并发地执行同一个job定义（这里指特定的job类）的多个实例。请注意这里的用词。拿前一小节的例子来说，如果“SalesReportJob”类上有该注解，则同一时刻仅允许执行一个“SalesReportForJoe”实例，但可以并发地执行“SalesReportForMike”类的一个实例。所以该限制是针对JobDetail的，而不是job类的。但是我们认为（在设计Quartz的时候）应该将该注解放在job类上，因为job类的改变经常会导致其行为发生变化。

@PersistJobDataAfterExecution：将该注解加在job类上，告诉Quartz在成功执行了job类的execute方法后（没有发生任何异常），更新JobDetail中JobDataMap的数据，使得该job（即JobDetail）在下一次执行的时候，JobDataMap中是更新后的数据，而不是更新前的旧数据。和 @DisallowConcurrentExecution注解一样，尽管注解是加在job类上的，但其限制作用是针对job实例的，而不是job类的。由job类来承载注解，是因为job类的内容经常会影响其行为状态（比如，job类的execute方法需要显式地“理解”其”状态“）。

如果你使用了@PersistJobDataAfterExecution注解，我们强烈建议你同时使用

@DisallowConcurrentExecution注解，因为当同一个job（JobDetail）的两个实例被并发执行时，由于竞争，JobDataMap中存储的数据很可能是不确定的。

Job的其它特性

通过JobDetail对象，可以给job实例配置的其它属性有：

• Durability：如果一个job是非持久的，当没有活跃的trigger与之关联的时候，会被自动地从scheduler中删除。也就是说，非持久的job的生命期是由trigger的存在与否决定的；
• RequestsRecovery：如果一个job是可恢复的，并且在其执行的时候，scheduler发生硬关闭（hard shutdown)（比如运行的进程崩溃了，或者关机了），则当scheduler重新启动的时候，该job会被重新执行。此时，该job的JobExecutionContext.isRecovering() 返回true。

JobExecutionException

最后，是关于Job.execute(..)方法的一些额外细节。execute方法中仅允许抛出一种类型的异常（包括RuntimeExceptions），即JobExecutionException。因此，你应该将execute方法中的所有内容都放到一个”try-catch”块中。你也应该花点时间看看JobExecutionException的文档，因为你的job可以使用该异常告诉scheduler，你希望如何来处理发生的异常。

Quartz中Triggers介绍

与job一样，trigger也很容易使用，但是还有一些扩展选项需要理解，以便更好地使用quartz。trigger也有很多类型，我们可以根据实际需要来选择。

最常用的两种trigger会分别在第5课：SimpleTrigger和第6课：CronTrigger中讲到。

Trigger的公共属性

所有类型的trigger都有TriggerKey这个属性，表示trigger的身份；除此之外，trigger还有很多其它的公共属性。这些属性，在构建trigger的时候可以通过TriggerBuilder设置。

trigger的公共属性有：

• jobKey属性：当trigger触发时被执行的job的身份；
• startTime属性：设置trigger第一次触发的时间；该属性的值是java.util.Date类型，表示某个指定的时间点；有些类型的trigger，会在设置的startTime时立即触发，有些类型的trigger，表示其触发是在startTime之后开始生效。比如，现在是1月份，你设置了一个trigger–“在每个月的第5天执行”，然后你将startTime属性设置为4月1号，则该trigger第一次触发会是在几个月以后了(即4月5号)。
• endTime属性：表示trigger失效的时间点。比如，”每月第5天执行”的trigger，如果其endTime是7月1号，则其最后一次执行时间是6月5号。

其它的属性，会在下文中解释。

优先级(priority)

如果你的trigger很多(或者Quartz线程池的工作线程太少)，Quartz可能没有足够的资源同时触发所有的trigger；这种情况下，你可能希望控制哪些trigger优先使用Quartz的工作线程，要达到该目的，可以在trigger上设置priority属性。比如，你有N个trigger需要同时触发，但只有Z个工作线程，优先级最高的Z个trigger会被首先触发。如果没有为trigger设置优先级，trigger使用默认优先级，值为5；priority属性的值可以是任意整数，正数、负数都可以。

注意：只有同时触发的trigger之间才会比较优先级。10:59触发的trigger总是在11:00触发的trigger之前执行。

注意：如果trigger是可恢复的，在恢复后再调度时，优先级与原trigger是一样的。

错过触发(misfire Instructions)

trigger还有一个重要的属性misfire；如果scheduler关闭了，或者Quartz线程池中没有可用的线程来执行job，此时持久性的trigger就会错过(miss)其触发时间，即错过触发(misfire)。不同类型的trigger，有不同的misfire机制。它们默认都使用“智能机制(smart policy)”，即根据trigger的类型和配置动态调整行为。当scheduler启动的时候，查询所有错过触发(misfire)的持久性trigger。然后根据它们各自的misfire机制更新trigger的信息。当你在项目中使用Quartz时，你应该对各种类型的trigger的misfire机制都比较熟悉，这些misfire机制在JavaDoc中有说明。关于misfire机制的细节，会在讲到具体的trigger时作介绍。

日历示例(calendar)

Quartz的Calendar对象(不是java.util.Calendar对象)可以在定义和存储trigger的时候与trigger进行关联。Calendar用于从trigger的调度计划中排除时间段。比如，可以创建一个trigger，每个工作日的上午9:30执行，然后增加一个Calendar，排除掉所有的商业节日。

任何实现了Calendar接口的可序列化对象都可以作为Calendar对象，Calendar接口如下：

package org.quartz;
public interface Calendar {
public boolean isTimeIncluded(long timeStamp);
public long getNextIncludedTime(long timeStamp);
}

注意到这些方法的参数类型为long。你也许猜到了，他们就是毫秒单位的时间戳。即Calendar排除时间段的单位可以精确到毫秒。你也许对“排除一整天”的Calendar比较感兴趣。Quartz提供的org.quartz.impl.HolidayCalendar类可以很方便地实现。

Calendar必须先实例化，然后通过addCalendar()方法注册到scheduler。如果使用HolidayCalendar，实例化后，需要调用addExcludedDate(Date date)方法从调度计划中排除时间段。以下示例是将同一个Calendar实例用于多个trigger：

HolidayCalendar cal = new HolidayCalendar(); cal.addExcludedDate( someDate ); 
cal.addExcludedDate( someOtherDate );
sched.addCalendar("myHolidays", cal, false);
Trigger t = newTrigger() 
.withIdentity("myTrigger") 
.forJob("myJob") 
.withSchedule(dailyAtHourAndMinute(9, 30)) // execute job daily at 9:30 
.modifiedByCalendar("myHolidays") // but not on holidays 
.build();
// .. schedule job with trigger

Trigger t2 = newTrigger() 
.withIdentity("myTrigger2") 
.forJob("myJob2") 
.withSchedule(dailyAtHourAndMinute(11, 30)) // execute job daily at 11:30 
.modifiedByCalendar("myHolidays") // but not on holidays .build();
// .. schedule job with trigger2

接下来的几个课程将介绍触发器的施工/建造细节。现在，只要认为上面的代码创建了两个触发器，每个触发器都计划每天触发。然而，在日历所排除的期间内发生的任何发射都将被跳过。

Simple Trigger

SimpleTrigger可以满足的调度需求是：在具体的时间点执行一次，或者在具体的时间点执行，并且以指定的间隔重复执行若干次。比如，你有一个trigger，你可以设置它在2015年1月13日的上午11:23:54准时触发，或者在这个时间点触发，并且每隔2秒触发一次，一共重复5次。

根据描述，你可能已经发现了，SimpleTrigger的属性包括：开始时间、结束时间、重复次数以及重复的间隔。这些属性的含义与你所期望的是一致的，只是关于结束时间有一些地方需要注意。

重复次数，可以是0、正整数，以及常量SimpleTrigger.REPEAT_INDEFINITELY。重复的间隔，必须是0，或者long型的正数，表示毫秒。注意，如果重复间隔为0，trigger将会以重复次数并发执行(或者以scheduler可以处理的*似并发数)。

如果你还不熟悉DateBuilder，了解后你会发现使用它可以非常方便地构造基于开始时间(或终止时间)的调度策略。

endTime属性的值会覆盖设置重复次数的属性值；比如，你可以创建一个trigger，在终止时间之前每隔10秒执行一次，你不需要去计算在开始时间和终止时间之间的重复次数，只需要设置终止时间并将重复次数设置为REPEAT_INDEFINITELY(当然，你也可以将重复次数设置为一个很大的值，并保证该值比trigger在终止时间之前实际触发的次数要大即可)。

SimpleTrigger实例通过TriggerBuilder设置主要的属性，通过SimpleScheduleBuilder设置与SimpleTrigger相关的属性。要使用这些builder的静态方法，需要静态导入：

下面的例子，是基于简单调度(simple schedule)创建的trigger。建议都看一下，因为每个例子都包含一个不同的实现点：

指定时间开始触发，不重复：

SimpleTrigger trigger = (SimpleTrigger) newTrigger() 
.withIdentity("trigger1", "group1") 
.startAt(myStartTime) // some Date 
.forJob("job1", "group1") // identify job with name, group strings
 .build();

指定时间触发，每隔10秒执行一次，重复10次：

trigger = newTrigger() 
.withIdentity("trigger3", "group1") 
.startAt(myTimeToStartFiring) // if a start time is not given (if this line were omitted), "now" is implied 
.withSchedule(simpleSchedule() 
.withIntervalInSeconds(10) 
.withRepeatCount(10)) // note that 10 repeats will give a total of 11 firings 
.forJob(myJob) // identify job with handle to its JobDetail itself 
.build();

5分钟以后开始触发，仅执行一次：

trigger = (SimpleTrigger) newTrigger() 
.withIdentity("trigger5", "group1") 
.startAt(futureDate(5, IntervalUnit.MINUTE)) // use DateBuilder to create a date in the future 
.forJob(myJobKey) // identify job with its JobKey 
.build();

立即触发，每个5分钟执行一次，直到22:00：

trigger = newTrigger() 
.withIdentity("trigger7", "group1") 
.withSchedule(simpleSchedule() 
.withIntervalInMinutes(5) 
.repeatForever()) 
.endAt(dateOf(22, 0, 0)) 
.build();

建立一个触发器，将在下一个小时的整点触发，然后每2小时重复一次：

trigger = newTrigger() 
.withIdentity("trigger8") // because group is not specified, "trigger8" will be in the default group
.startAt(evenHourDate(null)) // get the next even-hour (minutes and seconds zero ("00:00"))
.withSchedule(simpleSchedule() 
.withIntervalInHours(2) 
.repeatForever())
// note that in this example, 'forJob(..)' is not called which is valid 
// if the trigger is passed to the scheduler along with the job
.build();
scheduler.scheduleJob(trigger, job);

请查阅TriggerBuilder和SimpleScheduleBuilder提供的方法，以便对上述示例中未提到的选项有所了解。

TriggerBuilder(以及Quartz的其它builder)会为那些没有被显式设置的属性选择合理的默认值。
比如：如果你没有调用withIdentity(..)方法，TriggerBuilder会为trigger生成一个随机的名称；
如果没有调用startAt(..)方法，则默认使用当前时间，即trigger立即生效。

SimpleTrigger Misfire策略

SimpleTrigger有几个misfire相关的策略，告诉quartz当misfire发生的时候应该如何处理。(Misfire策略参考教程四：Trigger介绍)。这些策略以常量的形式在SimpleTrigger中定义(JavaDoc中介绍了它们的功能)。这些策略包括：

SimpleTrigger的Misfire策略常量：

MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY 
MISFIRE_INSTRUCTION_FIRE_NOW 
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT 
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT 
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT

回顾一下，所有的trigger都有一个Trigger.MISFIRE_INSTRUCTION_SMART_POLICY策略可以使用，该策略也是所有trigger的默认策略。

如果使用smart policy，SimpleTrigger会根据实例的配置及状态，在所有MISFIRE策略中动态选择一种Misfire策略。SimpleTrigger.updateAfterMisfire()的JavaDoc中解释了该动态行为的具体细节。

在使用SimpleTrigger构造trigger时，misfire策略作为基本调度(simple schedule)的一部分进行配置(通过SimpleSchedulerBuilder设置)：

trigger = newTrigger() 
.withIdentity("trigger7", "group1") 
.withSchedule(simpleSchedule() 
.withIntervalInMinutes(5) 
.repeatForever() 
.withMisfireHandlingInstructionNextWithExistingCount()) 
.build();

CronTrigger

CronTrigger通常比Simple Trigger更有用，如果您需要基于日历的概念而不是按照SimpleTrigger的精确指定间隔进行重新启动的作业启动计划。

使用CronTrigger，您可以指定号时间表，例如“每周五中午”或“每个工作日和上午9:30”，甚至“每周一至周五上午9:00至10点之间每5分钟”和1月份的星期五“。

即使如此，和SimpleTrigger一样，CronTrigger有一个startTime，它指定何时生效，以及一个（可选的）endTime，用于指定何时停止计划。

Cron Expressions

Cron-Expressions用于配置CronTrigger的实例。Cron Expressions是由七个子表达式组成的字符串，用于描述日程表的各个细节。这些子表达式用空格分隔，并表示：

1. Seconds
2. Minutes
3. Hours
4. Day-of-Month
5. Month
6. Day-of-Week
7. Year (optional field)

一个完整的Cron-Expressions的例子是字符串“0 0 12？* WED“ - 这意味着”每个星期三下午12:00“。

单个子表达式可以包含范围和/或列表。例如，可以用“MON-FRI”，“MON，WED，FRI”或甚至“MON-WED，SAT”代替前一个（例如“WED”）示例中的星期几字段。

通配符（' '字符）可用于说明该字段的“每个”可能的值。因此，前一个例子的“月”字段中的“”字符仅仅是“每个月”。因此，“星期几”字段中的“*”显然意味着“每周的每一天”。

所有字段都有一组可以指定的有效值。这些值应该是相当明显的 - 例如秒和分钟的数字0到59，数小时的值0到23。日期可以是1-31的任何值，但是您需要注意在给定的月份中有多少天！月份可以指定为0到11之间的值，或者使用字符串JAN，FEB，MAR，APR，MAY，JUN，JUL，AUG，SEP，OCT，NOV和DEC。星期几可以指定为1到7（1 =星期日）之间的值，或者使用字符串SUN，MON，TUE，WED，THU，FRI和SAT。

'/'字符可用于指定值的增量。例如，如果在“分钟”字段中输入“0/15”，则表示“每隔15分钟，从零开始”。如果您在“分钟”字段中使用“3/20”，则意味着“每隔20分钟，从三分钟开始” - 换句话说，它与“分钟”中的“3,243,43”相同领域。请注意“ / 35”的细微之处并不代表“每35分钟” - 这意味着“每隔35分钟，从零开始” - 或者换句话说，与指定“0,35”相同。

'？' 字符是允许的日期和星期几字段。用于指定“无特定值”。当您需要在两个字段中的一个字段中指定某个字符而不是另一个字段时，这很有用。请参阅下面的示例（和CronTrigger JavaDoc）以进行说明。

“L”字符允许用于月日和星期几字段。这个角色对于“最后”来说是短暂的，但是在这两个领域的每一个领域都有不同的含义。例如，“月”字段中的“L”表示“月的最后一天” - 1月31日，非闰年2月28日。如果在本周的某一天使用，它只是意味着“7”或“SAT”。但是如果在星期几的领域中再次使用这个值，就意味着“最后一个月的xxx日”，例如“6L”或“FRIL”都意味着“月的最后一个星期五”。您还可以指定从该月最后一天的偏移量，例如“L-3”，这意味着日历月份的第三个到最后一天。当使用'L'选项时，重要的是不要指定列表或值的范围，因为您会得到混乱/意外的结果。

“W”用于指定最*给定日期的工作日（星期一至星期五）。例如，如果要将“15W”指定为月日期字段的值，则意思是：“最*的*日到当月15日”。

'＃'用于指定本月的“第n个”XXX工作日。例如，“星期几”字段中的“6＃3”或“FRI＃3”的值表示“本月的第三个星期五”。

以下是一些表达式及其含义的更多示例 - 您可以在JavaDoc中找到更多的org.quartz.CronExpression

Cron Expressions示例

CronTrigger示例1 - 创建一个触发器的表达式，每5分钟就会触发一次

“0 0/5 * * *？”

CronTrigger示例2 - 创建触发器的表达式，每5分钟触发一次，分钟后10秒（即上午10时10分，上午10:05:10等）。

“10 0/5 * * *？”

CronTrigger示例3 - 在每个星期三和星期五的10:30，11:30，12:30和13:30创建触发器的表达式。

“0 30 10-13？* WED，FRI“

CronTrigger示例4 - 创建触发器的表达式，每个月5日和20日上午8点至10点之间每半小时触发一次。请注意，触发器将不会在上午10点开始，仅在8:00，8:30，9:00和9:30

“0 0/30 8-9 5,20 *？”

请注意，一些调度要求太复杂，无法用单一触发表示 - 例如“每上午9:00至10:00之间每5分钟，下午1:00至晚上10点之间每20分钟”一次。在这种情况下的解决方案是简单地创建两个触发器，并注册它们来运行相同的作业。

构建CronTriggers

CronTrigger实例使用TriggerBuilder（用于触发器的主要属性）和CronScheduleBuilder（对于CronTrigger特定的属性）构建。要以DSL风格使用这些构建器，请使用静态导入：

import static org.quartz.TriggerBuilder.*; 
import static org.quartz.CronScheduleBuilder.*; 
import static org.quartz.DateBuilder.*:

建立一个触发器，每隔一分钟，每天上午8点至下午5点之间：

trigger = newTrigger() 
.withIdentity("trigger3", "group1") 
.withSchedule(cronSchedule("0 0/2 8-17 * * ?")) 
.forJob("myJob", "group1") 
.build();

建立一个触发器，将在上午10:42每天发射：

trigger = newTrigger() 
.withIdentity("trigger3", "group1") 
.withSchedule(dailyAtHourAndMinute(10, 42)) 
.forJob(myJobKey) 
.build();

或者：

trigger = newTrigger() 
.withIdentity("trigger3", "group1") 
.withSchedule(cronSchedule("0 42 10 * * ?")) 
.forJob(myJobKey) 
.build();

建立一个触发器，将在星期三上午10:42在TimeZone（系统默认值）之外触发：

trigger = newTrigger()
 .withIdentity("trigger3", "group1") 
.withSchedule(weeklyOnDayAndHourAndMinute(DateBuilder.WEDNESDAY, 10, 42)) 
.forJob(myJobKey) 
.inTimeZone(TimeZone.getTimeZone("America/Los_Angeles")) 
.build();

或者：

trigger = newTrigger()
.withIdentity("trigger3", "group1") 
.withSchedule(cronSchedule("0 42 10 ? * WED")) 
.inTimeZone(TimeZone.getTimeZone("America/Los_Angeles")) 
.forJob(myJobKey) 
.build();

CronTrigger Misfire说明

以下说明可以用于通知Quartz当CronTrigger发生失火时应该做什么。（本教程“更多关于触发器”部分引入了失火情况）。这些指令定义为CronTrigger本身的常量（包括描述其行为的JavaDoc）。说明包括：

CronTrigger的Misfire指令常数

MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
MISFIRE_INSTRUCTION_DO_NOTHING 
MISFIRE_INSTRUCTION_FIRE_NOW

所有触发器还具有可用的Trigger.MISFIRE_INSTRUCTION_SMART_POLICY指令，并且该指令也是所有触发器类型的默认值。“智能策略”指令由CronTrigger解释为MISFIRE_INSTRUCTION_FIRE_NOW。CronTrigger.updateAfterMisfire（）方法的JavaDoc解释了此行为的确切细节。

在构建CronTriggers时，您可以将misfire指令指定为简单计划的一部分（通过CronSchedulerBuilder）：

trigger = newTrigger() 
.withIdentity("trigger3", "group1") 
.withSchedule(cronSchedule("0 0/2 8-17 * * ?")
   ..withMisfireHandlingInstructionFireAndProceed()) 
.forJob("myJob", "group1") 
.build();

TriggerListeners和JobListeners

Listeners是您创建的对象，用于根据调度程序中发生的事件执行操作。您可能猜到，TriggerListeners接收到与触发器（trigger）相关的事件，JobListeners 接收与jobs相关的事件。

与触发相关的事件包括：触发器触发，触发失灵（在本文档的“触发器”部分中讨论），并触发完成（触发器关闭的作业完成）。

org.quartz.TriggerListener接口

public interface TriggerListener {
 public String getName(); 
 public void triggerFired(Trigger trigger, JobExecutionContext context); 

 public boolean vetoJobExecution(Trigger trigger, JobExecutionContext context); 
 public void triggerMisfired(Trigger trigger); 
 public void triggerComplete(Trigger trigger, JobExecutionContext context, int triggerInstructionCode); 
}

job相关事件包括：job即将执行的通知，以及job完成执行时的通知。

org.quartz.JobListener接口

public interface JobListener { 
public String getName();
public void jobToBeExecuted(JobExecutionContext context); 
public void jobExecutionVetoed(JobExecutionContext context); 
public void jobWasExecuted(JobExecutionContext context, JobExecutionException jobException); 
}

使用自己的Listeners

要创建一个listener，只需创建一个实现org.quartz.TriggerListener和/或org.quartz.JobListener接口的对象。然后，listener在运行时会向调度程序注册，并且必须给出一个名称（或者，他们必须通过他们的getName（）方法来宣传自己的名字）。

为了方便起见，实现这些接口，您的类也可以扩展JobListenerSupport类或TriggerListenerSupport类，并且只需覆盖您感兴趣的事件。

listener与调度程序的ListenerManager一起注册，并配有描述listener希望接收事件的job/触发器的Matcher。

Listener在运行时间内与调度程序一起注册，并且不与jobs和触发器一起存储在JobStore中。
这是因为听众通常是与应用程序的集成点。因此，每次运行应用程序时，都需要重新注册该调度程序。

添加对特定job感兴趣的JobListener：

scheduler.getListenerManager（）
.addJobListener（myJobListener，KeyMatcher
.jobKeyEquals（new JobKey（“myJobName”，“myJobGroup”）））;

您可能需要为匹配器和关键类使用静态导入，这将使您定义匹配器更简洁：

import static org.quartz.JobKey.*; 
import static org.quartz.impl.matchers.KeyMatcher.*; 
import static org.quartz.impl.matchers.GroupMatcher.*; 
import static org.quartz.impl.matchers.AndMatcher.*; 
import static org.quartz.impl.matchers.OrMatcher.*; 
import static org.quartz.impl.matchers.EverythingMatcher.*; 
...etc.

这将上面的例子变成这样：

scheduler.getListenerManager()
.addJobListener(myJobListener, jobKeyEquals(jobKey("myJobName", "myJobGroup")));

添加对特定组的所有job感兴趣的JobListener：

scheduler.getListenerManager()
.addJobListener(myJobListener, jobGroupEquals("myJobGroup"));

添加对两个特定组的所有job感兴趣的JobListener：

scheduler.getListenerManager()
.addJobListener(myJobListener, or(jobGroupEquals("myJobGroup"), jobGroupEquals("yourGroup")));

添加对所有job感兴趣的JobListener：

scheduler.getListenerManager().addJobListener(myJobListener, allJobs());

注册TriggerListeners的工作原理相同。

Quartz的大多数用户并不使用Listeners，但是当应用程序需求创建需要事件通知时不需要Job本身就必须明确地通知应用程序，这些用户就很方便。

SchedulerListeners

SchedulerListeners非常类似于TriggerListeners和JobListeners，除了它们在Scheduler本身中接收到事件的通知 - 不一定与特定触发器（trigger）或job相关的事件。

与计划程序相关的事件包括：添加job/触发器，删除job/触发器，调度程序中的严重错误，关闭调度程序的通知等。

org.quartz.SchedulerListener接口

public interface SchedulerListener { 
public void jobScheduled(Trigger trigger); 
public void jobUnscheduled(String triggerName, String triggerGroup);
 public void triggerFinalized(Trigger trigger); 
public void triggersPaused(String triggerName, String triggerGroup); 
public void triggersResumed(String triggerName, String triggerGroup); 

public void jobsPaused(String jobName, String jobGroup); 
public void jobsResumed(String jobName, String jobGroup); 
public void schedulerError(String msg, SchedulerException cause);
public void schedulerStarted(); public void schedulerInStandbyMode(); 

public void schedulerShutdown(); public void schedulingDataCleared(); 
}

SchedulerListeners注册到调度程序的ListenerManager。SchedulerListeners几乎可以实现任何实现org.quartz.SchedulerListener接口的对象。

添加SchedulerListener：

scheduler.getListenerManager().addSchedulerListener(mySchedListener);

删除SchedulerListener：

scheduler.getListenerManager().removeSchedulerListener(mySchedListener);

Job Stores

JobStore负责跟踪您提供给调度程序的所有“工作数据”：jobs，triggers，日历等。为您的Quartz调度程序实例选择适当的JobStore是重要的一步。幸运的是，一旦你明白他们之间的差异，那么选择应该是一个非常简单的选择。

您声明您提供给用于生成调度程序实例的SchedulerFactory的属性文件（或对象）中您的调度程序应使用哪个JobStore（以及它的配置设置）。

切勿在代码中直接使用JobStore实例。由于某种原因，许多人试图这样做。
JobStore用于Quartz本身的幕后使用。
你必须告诉Quartz（通过配置）使用哪个JobStore，但是你应该只在代码中使用Scheduler界面。

RAMJobStore

RAMJobStore是使用最简单的JobStore，它也是性能最高的（在CPU时间方面）。RAMJobStore以其明显的方式获取其名称：它将其所有数据保存在RAM中。这就是为什么它是闪电般快的，也是为什么这么简单的配置。缺点是当您的应用程序结束（或崩溃）时，所有调度信息都将丢失 - 这意味着RAMJobStore无法履行作业和triggers上的“非易失性”设置。对于某些应用程序，这是可以接受的 - 甚至是所需的行为，但对于其他应用程序，这可能是灾难性的。

要使用RAMJobStore（并假设您使用的是StdSchedulerFactory），只需将类名称org.quartz.simpl.RAMJobStore指定为用于配置石英的JobStore类属性：

配置Quartz以使用RAMJobStore

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

没有其他需要担心的设置。

JDBC JobStore

JDBCJobStore也被恰当地命名 - 它通过JDBC将其所有数据保存在数据库中。因此，配置比RAMJobStore要复杂一点，而且也不是那么快。但是，性能下降并不是很糟糕，特别是如果您在主键上构建具有索引的数据库表。在相当现代的一套具有体面的LAN（在调度程序和数据库之间）的机器上，检索和更新触发triggers的时间通常将小于10毫秒。

JDBCJobStore几乎与任何数据库一起使用，已被广泛应用于Oracle，PostgreSQL，MySQL，MS SQLServer，HSQLDB和DB2。要使用JDBCJobStore，必须首先创建一组数据库表以供Quartz使用。您可以在Quartz发行版的“docs / dbTables”目录中找到表创建SQL脚本。如果您的数据库类型尚未有脚本，请查看其中一个脚本，然后以数据库所需的任何方式进行修改。需要注意的一点是，在这些脚本中，所有的表都以前缀“QRTZ_”开始（如表“QRTZ_TRIGGERS”和“QRTZ_JOB_DETAIL”）。只要你通知JDBCJobStore前缀是什么（在你的Quartz属性中），这个前缀实际上可以是你想要的。对于多个调度程序实例，使用不同的前缀可能有助于创建多组表，

创建表后，在配置和启动JDBCJobStore之前，您还有一个重要的决定。您需要确定应用程序需要哪种类型的事务。如果您不需要将调度命令（例如添加和删除triggers）绑定到其他事务，那么可以通过使用JobStoreTX作为JobStore 来管理事务（这是最常见的选择）。

如果您需要Quartz与其他事务（即J2EE应用程序服务器）一起工作，那么您应该使用JobStoreCMT - 在这种情况下，Quartz将让应用程序服务器容器管理事务。

最后一个难题是设置一个DataSource，JDBCJobStore可以从中获取与数据库的连接。DataSources在Quartz属性中使用几种不同的方法之一进行定义。一种方法是让Quartz创建和管理DataSource本身 - 通过提供数据库的所有连接信息。另一种方法是让Quartz使用由Quartz正在运行的应用程序服务器管理的DataSource，通过提供JDBCJobStore DataSource的JNDI名称。有关属性的详细信息，请参阅“docs / config”文件夹中的示例配置文件。

要使用JDBCJobStore（并假定您使用的是StdSchedulerFactory），首先需要将Quartz配置的JobStore类属性设置为org.quartz.impl.jdbcjobstore.JobStoreTX或org.quartz.impl.jdbcjobstore.JobStoreCMT - 具体取决于根据上述几段的解释，您所做的选择。

配置Quartz以使用JobStoreTx

org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

接下来，您需要为JobStore选择一个DriverDelegate才能使用。DriverDelegate负责执行特定数据库可能需要的任何JDBC工作。StdJDBCDelegate是一个使用“vanilla”JDBC代码（和SQL语句）来执行其工作的委托。如果没有为您的数据库专门制作另一个代理，请尝试使用此委托 - 我们仅为数据库制作了特定于数据库的代理，我们使用StdJDBCDelegate（似乎最多！）发现了问题。其他代理可以在“org.quartz.impl.jdbcjobstore”包或其子包中找到。其他代理包括DB2v6Delegate（用于DB2版本6及更早版本），HSQLDBDelegate（用于HSQLDB），MSSQLDelegate（用于Microsoft SQLServer），PostgreSQLDelegate（用于PostgreSQL）），WeblogicDelegate（用于使用Weblogic创建的JDBC驱动程序）

选择委托后，将其类名设置为JDBCJobStore的委托使用。

配置JDBCJobStore以使用DriverDelegate

org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

接下来，您需要通知JobStore您正在使用的表前缀（如上所述）。

使用表前缀配置JDBCJobStore

org.quartz.jobStore.tablePrefix = QRTZ_

最后，您需要设置JobStore应该使用哪个DataSource。命名的DataSource也必须在Quartz属性中定义。在这种情况下，我们指定Quartz应该使用DataSource名称“myDS”（在配置属性中的其他位置定义）。

使用要使用的DataSource的名称配置JDBCJobStore

org.quartz.jobStore.dataSource = myDS

如果您的计划程序正忙（即几乎总是执行与线程池大小相同的job数量），那么您应该将DataSource中的连接数设置为线程池+ 2的大小。

可以将“org.quartz.jobStore.useProperties”配置参数设置为“true”（默认为false），以指示JDBCJobStore将JobDataMaps中的所有值都作为字符串，因此可以作为名称 - 值对存储而不是在BLOB列中以其序列化形式存储更多复杂的对象。从长远来看，这是更安全的，因为您避免了将非String类序列化为BLOB的类版本问题。

TerracottaJobStore

TerracottaJobStore提供了一种缩放和鲁棒性的手段，而不使用数据库。这意味着您的数据库可以免受Quartz的负载，可以将其所有资源保存为应用程序的其余部分。

TerracottaJobStore可以运行群集或非群集，并且在任一情况下，为应用程序重新启动之间持续的作业数据提供存储介质，因为数据存储在Terracotta服务器中。它的性能比通过JDBCJobStore使用数据库要好得多（约一个数量级更好），但比RAMJobStore要慢。

要使用TerracottaJobStore（并且假设您使用的是StdSchedulerFactory），只需将类名称org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore指定为用于配置石英的JobStore类属性，并添加一个额外的行配置来指定Terracotta服务器的位置：

配置Quartz以使用TerracottaJobStore

org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore 
org.quartz.jobStore.tcConfigUrl = localhost:9510

配置，资源使用和SchedulerFactory

quartz的架构是模块化的，因此要运行几个组件需要“快速”在一起。幸运的是，有一些帮手出现这种情况。

在Quartz可以完成其工作之前需要配置的主要组件有：

• 线程池
• JobStore
• DataSources（如有必要）
• 计划程序本身

该线程池提供了一组Quartz在执行jobs时使用的线程。池中的线程越多，并发运行的jobs数越多。但是，太多的线程可能会破坏您的系统。大多数Quartz用户发现，5个左右的线程是充足的 - 因为在任何给定时间，它们的jobs数量少于100个，通常不会同时运行这些jobs，而且这些jobs是短暂的（快速完成）。其他用户发现他们需要10个，15个，50个甚至100个线程，因为它们具有数万个具有各种计划的triggers，最终*均在任何给定时刻执行10到100个jobs。为调度程序的池找到正确的大小完全取决于您正在使用的调度程序。没有真正的规则，除了保持线程数量尽可能小（为了您的机器的资源） - 但确保您已足够让您的Jobs按时启动。请注意，如果triggers的触发时间到达，并且没有可用的线程，Quartz将阻止（暂停）直到线程可用，然后jobs将执行 - 比它应有的数毫秒。这甚至可能导致线程失火 - 如果在调度程序配置的“失火阈值”的持续时间内没有可用的线程。那么jobs将执行 - 比它应该有几毫秒。这甚至可能导致线程失火 - 如果在调度程序配置的“失火阈值”的持续时间内没有可用的线程。那么jobs将执行 - 比它应该有几毫秒。这甚至可能导致线程失火 - 如果在调度程序配置的“失火阈值”的持续时间内没有可用的线程。

ThreadPool接口在org.quartz.spi包中定义，您可以以任何您喜欢的方式创建ThreadPool实现。Quartz带有一个名为org.quartz.simpl.SimpleThreadPool的简单（但非常令人满意）的线程池。这个ThreadPool只是在它的池中维护一个固定的线程集 - 永远不会增长，永远不会缩小。但是否则它是非常强大的，并经过很好的测试 - 因为几乎所有使用Quartz的人都使用这个池。

JobStores和 DataSource在本教程的第9课中讨论过。值得注意的是，所有JobStores都实现了org.quartz.spi.JobStore接口 - 如果一个捆绑的JobStores不符合您的需求，那么您可以自己创建。

最后，您需要创建您的Scheduler实例。调度程序本身需要被赋予一个名字，告诉其RMI设置，并递交JobStore和ThreadPool的实例。RMI设置包括调度程序是否应将自身创建为RMI的服务器对象（使其可用于远程连接），要使用的主机和端口等。StdSchedulerFactory（下面将讨论）还可以生成实际代理的Scheduler实例（ RMI存根）到在远程进程中创建的计划程序。

StdSchedulerFactory

StdSchedulerFactory是org.quartz.SchedulerFactory接口的一个实现。它使用一组属性（java.util.Properties）来创建和初始化Quartz Scheduler。属性通常存储在文件中并从文件中加载，但也可以由程序创建并直接传递到工厂。简单地调用工厂中的getScheduler（）将生成调度程序，并初始化它（和它的ThreadPool，JobStore和DataSources）并返回一个句柄到它的公共接口。

在Quartz发行版的“docs / config”目录中有一些示例配置（包括属性的描述）。您可以在Quartz文档的“参考”部分的“配置”手册中找到完整的文档。

DirectSchedulerFactory

DirectSchedulerFactory是另一个SchedulerFactory实现。对于希望以更加程序化的方式创建其Scheduler实例的用户是有用的。通常不鼓励使用它的用法，原因如下：（1）要求用户更好地了解他们正在做什么，（2）它不允许声明性配置 - 换句话说，你最终会硬 - 编辑所有调度程序的设置。

记录

Quartz使用SLF4J框架来满足所有的日志记录需求。为了“调整”日志记录设置（例如输出量以及输出位置），您需要了解SLF4J框架，这超出了本文档的范围。

如果要捕获关于triggers启动和jobs执行的额外信息，可能有兴趣启用org.quartz.plugins.history.LoggingJobHistoryPlugin和/或 org.quartz.plugins.history.LoggingTriggerHistoryPlugin。

Quartz高级（企业）功能

Clustering

Clustering目前与JDBC-Jobstore（JobStoreTX或JobStoreCMT）和TerracottaJobStore一起使用。功能包括负载*衡和 job故障转移（如果JobDetail的“请求恢复”标志设置为true）

####使用JobStoreTX或JobStoreCMT进行聚类通过将“org.quartz.jobStore.isClustered”属性设置为“true”来启用Clustering。Clustering中的每个实例都应该使用相同的quartz.properties文件。这样做的例外是使用相同的属性文件，具有以下允许的异常：不同的线程池大小，以及“org.quartz.scheduler.instanceId”属性的不同值。Clustering中的每个节点必须具有唯一的instanceId，通过将“AUTO”作为此属性的值，可以轻松完成（不需要不同的属性文件）。

不要在单独的机器上运行Clustering，除非它们的时钟使用某种形式的时间同步服务（守护进程）进行同步，
而这些时间同步服务（守护进程）运行非常有限（时钟必须在彼此之间）。 
如果您不熟悉如何执行此操作， 请参阅http://www.boulder.nist.gov/timefreq/service/its.htm。

不要针对任何其他实例运行的相同的一组表来启动非群集实例。您可能会收到严重的数据损坏，一定会遇到不正常的行为。

每次触发只能有一个节点有效。我的意思是，如果job有一个重复的trigger，告诉它每10秒钟发射一次，那么在12:00:00，正好一个节点将运行这个job，在12:00:10，一个节点将运行job等。它不一定是每次相同的节点 - 它或多或少是随机的，哪个节点运行它。负载*衡机制对于繁忙的调度程序（大量的trigger）来说是*乎随机的，但是有利于于non-busy（例如一个或两个trigger）调度程序活动的同一个节点。

####使用TerracottaJobStore进行Clustering简单地将调度程序配置为使用TerracottaJobStore（第9课：JobStores中介绍），并且您的调度程序将全部设置为Clustering。

您可能还需要考虑如何设置Terracotta服务器，特别是打开诸如持久性等功能的配置选项，以及运行一系列用于HA的Terracotta服务器。

TerracottaJobStore的企业版提供了高级的Quartz Where功能，允许将作业的智能定位到适当的Clustering节点。

有关此JobStore和Terracotta的更多信息， 请访问http://www.terracotta.org/quartz

JTA交易

如第9课：JobStores所述，JobStoreCMT允许在较大的JTA事务中执行Quartz调度操作。

通过将“org.quartz.scheduler.wrapJobExecutionInUserTransaction”属性设置为“true”，jobs也可以在JTA事务（UserTransaction）内执行。使用此选项集，aa JTA事务将在Job的execute方法被调用之前开始（），并且在执行调用之后commit（）终止。这适用于所有jobs。

如果您希望指定每个jobs是否JTA事务应该包装其执行，那么您应该在jobs类上使用 @ExecuteInJTATransaction注释。

除了Quartz自动将Job执行包装到JTA事务中，在Scheduler界面上进行的调用也可以在使用JobStoreCMT时参与事务处理。在调用程序调用方法之前，确保已经启动了一个事务。您可以直接通过使用UserTransaction或将使用调度程序的代码放在使用容器管理事务的SessionBean中来执行此操作。

Quartz其他功能

插件

Quartz提供了一个用于插入附加功能的接口（org.quartz.spi.SchedulerPlugin）。

与Quartz一起提供各种实用功能的插件可以在org.quartz.plugins 包中找到。它们提供诸如在调度程序启动时自动调度jobs的功能，记录jobs和触发事件的历史记录，并确保当JVM退出时，调度程序将彻底关闭。

JobFactory

当trigger触发时，通过Scheduler上配置的JobFactory实例化与之关联的jobs。默认的JobFactory只是在jobs类上调用newInstance（）。您可能需要创建自己的JobFactory实现，以完成诸如让应用程序的IoC或DI容器生成/初始化jobs实例之类的操作。

请参阅org.quartz.spi.JobFactory接口以及相关的Scheduler.setJobFactory（fact） 方法。

‘Factory-Shipped’ Jobs

Quartz还提供了许多实用jobs，您可以在应用程序中用于执行诸如发送电子邮件和调用EJB等工作。这些开箱即用的jobs可以在org.quartz.jobs 包中找到

参考网址：https://www.w3cschool.cn/quartz_doc/