Java Library on boboboker~

Quartz Tutorial 10 - Advanced (Enterprise) Features

Thu, 14 Sep 2017 00:00:00 +0800

Quartz Tutorial 10 - Advanced (Enterprise) Features

集群

目前JDBC-JobStore（JobStoreTX/JobStoreCMT）和TerracottaJobStore可以集群式工作。高级功能包括负载均衡和作业的fail-over（这个需要JobDetail的request recovery标志设置为true）。

通过设置org.quartz.jobStore.isClustered属性为true，JobStoreTX或JobStoreCMT就能集群式运行了。对于集群的每个实例，它们应该使用quartz.properties配置文件的同一份拷贝，这是为了保证一致性，当然有些配置项可以是机器独立的。线程池大小和org.quartz.scheduler.instanceId属性可以不同。集群的每个节点必须是独立的实例ID，这其实很简单，只需要在这个属性上填写AUTO即可。

集群内节点的时间必须是同步的（从同一个时间同步服务获取时间），此外还应当常规运行同步来保证节点间时间误差不超过1秒

不要针对任何其他实例运行的相同的一组表来启动非群集实例。不然数据会被严重损坏，而且会出现不正常的行为。

对于每次触发，只有一个节点会执行作业。例如：假定一个触发器设置的是每10秒触发一次，12:00:00的时刻确实有个节点执行作业了，那么12:00:10的时候也确实会有一个节点会执行作业。而且每次也不一定是同一个节点，会随机选择节点来执行作业的。

使用TerracottaJobStore的集群只需要简单配置一下调度器去使用它即可，然后你的调度器将使用集群全部机器。

您可能还需要考虑如何设置Terracotta服务器，特别是启用一些特别的配置选项，例如在磁盘上存储数据，使用fsync以及运行Terracotta服务器阵列。

关于JobStore和Terracotta的更多信息请查看Quartz Scheduler | Terracotta

JTA Transactions

之前在JobStore一节介绍过，JobStoreCMT允许Quartz调度操作放在一个大的JTA事务中。

只要设置了org.quartz.scheduler.wrapJobExecutionInUserTransaction属性为true，作业也可以在一个JTA事务(UserTransaction)中执行。这种情况下，一个JTA事务将会在作业的execute方法调用之前begin()，在方法执行完毕之后commit()。

除了Quartz自动将作业的执行包装到JTA事务中，在使用JobStoreCMT时也可以使用Scheduler接口参与事务处理。只要保证了你在调度器上调用一个方法前启动了一个事务。还可以更直接点，可以使用UserTransaction，或将使用调度器的代码放在使用容器管理事务的SessionBean中。

Quartz Tutorial 11 - Miscellaneous Features of Quartz

Thu, 14 Sep 2017 00:00:00 +0800

Quartz Tutorial 11 - Miscellaneous Features of Quartz

Plug-Ins

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

与Quartz一同发布的，提供了各种实用功能的插件可以在org.quartz.plugins包中找到。他们提供的功能有：在调度器启动时自动调度作业，记录作业和触发事件的日志，并确保当JVM退出时完全关闭调度器。

`JobFactory`

当触发器触发时，将使用调度器配置的JobFactory实例化与之关联的作业。默认的JobFactory只是在作业类上调用newInstance()方法。你也可能需要提供自己的JobFactory实现，让应用程序的IoC或DI容器来做生成/初始化作业实例之类的操作。

查看org.quartz.spi.JobFactory接口，以及与之有关的Scheduler.setJobFactory(factory)方法。

‘Factory-Shipped’ Jobs

Quartz也提供了一些很实用的作业类，例如发送邮件、调用EJB等等。这些开箱即用的作业类可以在org.quartz.jobs包中找到。

Quartz Tutorial 8 - Job Stores

Thu, 14 Sep 2017 00:00:00 +0800

Quartz Tutorial 8 - Job Stores

JobStore用于保持对你交给调度器的“工作数据”的持续跟踪，这些数据包括：作业、触发器、日历等等。选择合适的JobStore对你的Quartz调度器实例来说，是相当重要的一步。当然，你了解了他们之间的差异之后做出选择还是很简单的。你需要通过属性文件（或对象）告知SchedulerFactory你需要用到的JobStore（及对它的相关配置），然后SchedulerFactory生成一个调度器实例。

绝不要在代码中直接使用JobStore实例，虽然很多人出于各种各样的原因已经尝试过了。JobStore是Quartz在后台自己使用的。你只需要告知Quartz（通过配置信息）你要用到哪个JobStore，然后你只需要在代码中使用Scheduler接口就好。

`RAMJobStore`

RAMJobStore是最简单的JobStore了，它也是性能最好的了（在CPU时间方面）。RAMJobStore将它所有的数据都放在内存里，也因此而得名。这也是为何它为何如此轻量快速，也最容易配置。但缺点是，一旦你的应用结束（或者崩溃），所有调度相关信息都没了，这也意味着RAMJobStore不能赋予它的作业和触发器“非易失性”。对有些程序来说这不是什么问题，甚至是期望行为，但对有些程序来说，这完全不可接受。

要使用RAMJobStore（假定你正在用StdSchedulerFactory），你只需要将你用于配置Quartz处将JobStore类属性设置为org.quartz.simpl.RAMJobStore，如下所示

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

好了，除此之外没有任何需要配置的地方了。

`JDBCJobStore`

顾名思义，JDBCJobStore将它所有的数据存储到了数据库里，然后通过JDBC访问。因此相对于RAMJobStore，对它的配置就有些麻烦，当然也没有那么快了。然而它的性能倒也没有特别坏，尤其是你在数据库表中在主键上建立了索引。在正常的现代集群中，调度器和数据库之间链接正常，那么获取和更新一个正在触发的触发器状态的时间一般小于10毫秒。

JDBCJobStore几乎可以和所有数据库一起使用，例如Oracle、PostgreSQL、MySQL、MS SQL Server、 HSQLDB和DB2。要使用JDBCJobStore，你首先要在数据库中创建Quartz要用的那些表。在Quartz分支的docs/dbTables文件夹下你能找到建表的SQL脚本。如果里面没有用于你的数据库类型的脚本，你只需要打开任何一个，然后改改。有一点要特别提出来，所有以QRTZ_开头的表名（例如QRTZ_TRIGGERS QRTZ_JOB_DETAIL），这些前缀实际上可以是任意的。只要你在Quartz的配置文件里告知了JDBCJobStore你用了啥前缀就好。当你想在一个数据库中为不同的调度器实例创建不同的表的时候，这个特性还是很有用的。

表建完了之后，在配置和启动JDBCJobStore之前你还有个“重大决定”需要做出：你需要使用哪种事务。如果你不需要将调度命令（例如添加、移除触发器）束缚于于其它事务，那么你可以让Quartz用JobStoreTX作为你的JobStore来管理事务，这也是大部分人的选择。

如果你需要让Quartz与其他事务一起工作（例如在一个J2EE应用服务器内部），那你应该用JobStoreCMT，这样Quartz将会让应用服务器容器来管理事务。

最后一部分就是设置数据源，这样JDBCJobStore就能获取与数据库的连接了。数据源是在Quartz的配置文件里定义的。定义方式有多种，一种是让Quartz自己创建和管理-直接提供所有的连接信息。另一种是让Quartz使用它所在的应用服务器提供的数据源来干活-告知JDBCJobStore数据源的JDNI名字。要想知道配置文件的更多细节，去看看配置文件的例子，它在docs/config文件夹下。

假定你在使用StdSchedulerFactory，首先要在配置文件里将JobStore类属性写成org.quartz.impl.jdbcjobstore.JobStoreTX或者org.quartz.impl.jdbcjobstore.JobStoreCMT，这取决于你之前怎样决定的事务处理方式。

`1`	`org.quartz.jobStore.class = org.quartz.impl.jbdcjobstore.JobStoreTX`

接下来，你要选择一个驱动委托(DriverDelegate)给JobStore用。驱动委托是负责处理所有JDBC相关的工作，而且这也取决于你用什么数据库了。StdJDBCDelegate是使用“vanilla”JDBC代码（和SQL语句）来干活的委托。如果你没有配置这一项，那么Quartz就会使用这个。我们只为使用StdJDBCDelegate会出问题的数据库提供了专用委托（还真不少）。那些委托能够在org.quartz.imple.jdbcjobstore包或者它的子包发现。这些专用委托包括DB2v6Delegate(DB2 version6 及之前版本)、HSQLDBDelegate(用于 HSQLDB), MSSQLDelegate (用于 Microsoft SQLServer), PostgreSQLDelegate (用于 PostgreSQL), WeblogicDelegate (用于Weblogic提供的JDBC驱动), OracleDelegate (用于Oracle), 以及其他。

选定了你的委托之后，将它的类名配置给JDBCJobStore使用

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

接下来告知JobStore你使用的表名前缀

`1`	`org.quartz.jobStore.tablePrefix = QRTZ_`

最后你需要告知JobStore你要是用的数据源。命名的数据源必须也在Quartz配置文件里定义过了，在这个例子中，我们只写了个数据源的名字，但是对这个名字的定义也在配置文件里的某处。

`1`	`org.quartz.jobStore.dataSource = myDS`

如果你的调度器总是很忙（例如：总是有线程池线程数量个的作业在执行），那么此时你就应该考虑将线程池线程数+2，让它有余力保持对数据源的链接

org.quartz.jobStore.useProperties配置参数可以设置成true（默认是false）来告知JobStore在JobDataMap中的所有的值都是String类型，这样就能存成简单的名字-值对，而不是从反序列化来的更复杂的对象。当数据很长的时候，这样子也很安全，此外还避免了在序列化非字符串类的时候可能存在的版本问题。

TerracottaJobStore

TerracottaJobStore是Quartz 1.7新出的。它提供了不使用数据库但依然保持伸缩性和鲁棒性的手段。这意味着你可以将这些数据存储到应用的其他部分而不是放到数据库里。

TerracottaJobStore可以集群式运行也可以单独运行。它可以持久保存你的作业数据不管应用是不是发生了重启、崩溃等，因为数据存储在了Terracotta服务器上。它的性能比通过JDBCJobStore访问数据库好多了（好一个数量级），但也比RAMJobStore慢多了。

要使用TerracottaJobStore(假定你在使用StdSchedulerFactory)，你只需要在配置文件中写明类型，然后给出Terracotta服务器的地址就好了

1
2

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

关于JobStore和Terracotta的更多信息可以查看 Quartz Scheduler | Terracotta

Quartz Tutorial 9 - Configuration, Resource Usage and SchedulerFactory

Thu, 14 Sep 2017 00:00:00 +0800

Quartz Tutorial 9 - Configuration, Resource Usage and SchedulerFactory

Quartz是模块化的架构，因此它运行的时候必定是多个组件互相协作运行的。在Quartz能干活之前主要有如下几个组件需要配置：

ThreadPool
JobStore
DataSources（如果有必要）
Scheduler

ThreadPool为Quartz提供了一些可用于执行作业的线程。线程池里的线程数越多，能同时执行的作业也就越多。不过，过多的线程可能会拖累你的系统。大部分Quartz的用户发现5个左右的线程就很充足-因为在任何给定时间，程序的作业都远小于100个，而且也一般不会同时运行，此外作业也一般是短暂存在的（因为完成的很快）。有些用户就发觉他们需要10个、20个、50个甚至100个线程-因为有成百上千个触发器需要调取，而且在任意时刻平均有10到100个作业需要执行。因此可见，你的调度器到底需要多大的线程池完全取决于你要什么。这里没有确定的数字，当然要让这个数字尽可能小（为了尽可能少占用你机器的资源）-但是你也要保证这个数目是够用的。要注意：如果一个触发器到了触发时间了，但是没有闲置线程让它干活，Quartz将会暂停它直到有了可用的县城资源，然后作业才能执行-可能会晚个多少毫秒吧。如果在调度器配置的“misfire阈值”内一直没有可用线程，那么就会引发misfire。

ThreadPool接口定义在org.quartz.spi包中，你可以通过任何方式提供该接口的一个实现。Quartz提供了一个简单（但是非常靠谱）的线程池实现，org.quartz.simpl.SimpleThreadPool。这个线程池内部维护了一个定长线程池-不会扩展也不会收缩-但是相当健壮经过了相当严密的测试，几乎每个用户都在用Quartz提供的这个线程池。

JobStore和DataSource刚刚讨论过了。这里值得注意的是，所有的JobStore都实现了org.quartz.spi.JobStore接口，那么如果现有的实现满足不了你的需求，自己实现一个。

最后，你需要创建一个调度器实例。调度器自身需要一个名字，告知它的RMI设置，然后给一个JobStore和ThreadPool的实例。RMI设置包括调度器是否将自己创建成一个用于RMI的服务对象（可以被远程连接），用什么主机名和端口等等。

StdSchedulerFactory也可以生成实际上是远程进程创建的调度器实例代理的调度器实例。

`StdSchedulerFactory`

StdSchedulerFactory是org.quartz.SchedulerFactory接口的一个实现。它使用了一系列属性(java.util.Properties)来创建和初始化Quartz调度器。这些属性一般存储在文件中，但是你也可以直接在程序中创建然后交给工厂类。简单调用一下getScheduler()方法，工厂类就会实例化一个对象，然后将之初始化（包括线程池、JobStore和数据源），然后将它的公共接口返回给外界。

在Quartz分支的docs/config目录下有些简单的配置（包括对属性的描述）。在Quartz文档的Reference目录下，手册里的Configuration小节有完整的文档。

`DirectSchedulerFactory`

DirectorySchedulerFactory是SchedulerFactory接口的另一个实现。当你想用编程风格创建一个调度器实例的时候，这就很有用了。但这个一般不鼓励使用，出于以下两个原因：

它需要用户对于正在做什么有非常深的理解
它不支持声明式的配置-换句话说，你必须完全动手用编码的方式写出调度器的所有设置

Logging

对于所有的日志需求，Quartz使用SLF4J框架。如果你需要调整日志设置（例如调整日志的输出以及它们输出的位置），你需要了解这个框架，但是这个不在本文档的范围内了。

如果你需要捕获更多关于触发器触发和作业执行的信息，你可能需要去了解一下org.quartz.plugins.history.LoggingJobHistoryPlugin和/或org.quartz.plugins.history.LoggingTriggerHistoryPlugin。

Quartz Tutorial Cron Expression

Thu, 14 Sep 2017 00:00:00 +0800

Quartz Tutorial Cron Expression

这里的东西已经在 CronTrigger 一节介绍过了，这里没有照常翻译原文，只记录一下概要。

格式

子表达式名	是否必需	定义域	可用的特殊符号
Seconds	YES	0-59	, - * /
Minutes	YES	0-59	, - * /
Hours	YES	0-23	, - * /
Day of month	YES	1-31	, - * ? / L W
Month	YES	1-12 or JAN-DEC	, - * /
Day of week	YES	1-7 or SUN-SAT	, - * ? / L #
Year	NO	empt, 1970-2099	, - * /

特殊符号

* 所有值
? 不确定的值
- 用于划定一个范围
/ 用于声明增量
, 分割多个值
L 月份的最后一天或者周六，此时的L-2表示倒数第二
W 给定日期最近的工作日周一到周五 LW表示月份中最后的工作日
# 月份中的第几个周几例如6#3 第三个周五(6=FRI)

例子

表达式	意义
`0 0 12 * * ?`	每天中午12点
`0 15 10 ? * *`	每天上午10:15
`0 15 10 * * ?`	每天上午10：15
`0 15 10 * * ? *`	每天上午10：15
`0 15 10 * * ? 2005`	2005年的每天上午10：15
`0 * 14 * * ?`	每天下午14:00到14:59
`0 0/5 14 * * ?`	每天下午14:00到14:55之间，每5分钟一次
`0 0/5 14,18 * * ?`	每天下午14:00到14:55、18:00到18:55之间，每5分钟一次
`0 0-5 14 * * ?`	每天下午14:00到14:05之间，每分钟一次
`0 10,44 14 ? 3 WED`	三月份每个周三的14:10和14:44
`0 15 10 ? * MON-FRI`	周一到星期五的的上午10:15
`0 15 10 15 * ?`	每月15日的上午10:15
`0 15 10 L * ?`	每月最后一天的上午10:15
`0 15 10 L-2 * ?`	每月倒数第二天的上午10:15
`0 15 10 ? * 6L`	每月最后一个星期五的上午10:15
`0 15 10 ? * 6L 2002-2005`	2002到2005年，每个月的最后一个星期五的上午10:15
`0 15 10 ? * 6#3`	每个月的第三个星期五的15:10
`0 0 12 1/5 * ?`	每月1日开始，每隔五天的中午12:00:00
`0 11 11 11 11 ?`	每年11月11日11:11

Quartz Tutorial 5 - Cron Trigger

Wed, 13 Sep 2017 00:00:00 +0800

Quartz Tutorial 5 - Cron Trigger

当你要求作业的调度方式是“日历式”而不是“给定时间间隔式”的时候，CronTrigger比SimpleTrigger好用多了。

用CronTrigger的话，很容易就能声明类似“每周五下午”或者“每周工作日上午9:30”，甚至“一月份的每个周一周三周五的上午九点到十点之间，每五分钟”这种奇奇怪怪的触发时间。

此外，CronTrigger也有个startTime属性用于声明何时强制调度，也有一个（可选的）endTime属性用于声明何时结束调度。

Cron Expressions

Cron表达式是用于配置CronTrigger实例的。Cron表达式是由六个子表达式组成的字符串，它们互相独立地描述调度的各个细节。这些子表达式是由空格分割，它们表示：

秒(Seconds)
分钟(Minutes)
小时(Hours)
月份中的天(Day-of-Month)
月份(Month)
一周中的天(Day-of-Week)
年（可选）(Year)

举个例子，假定有字符串"0 0 12 ? * WED"，它表示“每周三的中午12点”

这些互相独立的子表达式可以包含范围和/或列表。举个例子，上面例子中的“一周中的天”字段可以替换成MON-FRI，MON,WED,FRI甚至可以是MON-WED,SAT

Cron表达式支持使用通配符。上例中，“月份中的天”表达式处的?表示每个“可能”的值，换言之，这个值是不确定的（但不是全部）。而对于*，就表示了所有值都是。

每个子表达式都有其自己的定义域。这也很显而易见了-对于秒和分钟，肯定是0到59；对于小时也必然是0到23；对于月份中的天，定义域是1到31，但是你自己应当注意这个月实际的天数；月份可以是数字0到11，也可以是字符串“JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC”；一周中的天可以是数字1到7(1=Sunday)，也可以是字符串“SUN MON TUE WED THU FRI SAT”

/ 用于声明值的增量。例如，分钟子表达式是0/15，它的意思是“在小时内，0分钟之后的每个第15分钟触发一次”；如果是3/20，意味着“小时内，3分钟之后的每个第20分钟触发一次”，换一个写法，分钟处的表达式就是3 23 43。要注意到一个细微的区别：/35不是说“每个35分”，而是说“从0分钟开始后的每个第35分钟”，换个写法就是0 35。

? 可以用在月份中的天和一周中的天子表达式中。这个符号表示“非确定的值”。当你需要明确声明其中一个值，但是另一个无法明确指定的时候，这很有用。比如你想在每个星期四触发作业的执行，但是周四具体是几号其实是不确定的，那么此时在月份中的天子表达式处就可以写这个通配符了。

L 可以用在月份中的天和一周中的天子表达式处。这是”last”的简写，但它在两个子表达式中具有不同的意义。例如，在月份中的天子表达式处填写L，意味着“月份中的最后一天”，例如一月份的31号，平年2月的28号等等；如果单独的L放在一周中的天子表达式处，意味着7或者SAT（周六）；但是在一周中的天子表达式中，如果L放在了其他值的后面，例如6L或FRIL，那就意味着“该月的最后一个周五”。你也可以声明相对于每月最后一天的偏移，例如L-3意味着该月的倒数第三天。当你使用L时，不要再声明列表式、范围式的值了，不然你将得到奇怪的结果

W 用于声明距离给定日子最近的工作日（周一至周五）。例如你在月份中的天子表达式中声明了15W，那意味着该月“距离15号最近的工作日”

# 用于声明“月份中第X个周X”。例如在一周中的天子表达式处给出6#3或者FRI#3，意思是“该月第三个周五”

下面是一些Cron表达式及其含义的具体举例，当然你可以在org.quartz.CronExpression的JavaDoc中找到更多。

Example Cron Expressions

每五分钟触发一次
1

0 0/5 * * * ?
每五分钟的第十秒触发，例如“10:00:10, 10:05:10”
1

10 0/5 * * * ?
每周三、周五的10:30, 11:30, 12:30, 13:30触发

`1`	`0 30 10-13 * * WED,FRI`

每月5号和20号的上午8点到10之间，每半小时触发一次。要注意10点并不会触发，只是八点、八点半、九点、九点半
1

0 0/30 8-9 5,20 * ?

有时有些调度的要求特别复杂，如果放在一个表达式中表示会过于复杂，例如“上午九点到十点之间每五分钟，下午一点到十点之间每二十分钟”。这种情况的话，可以创建两个触发器，然后将他俩都关联到同一个作业就好。

Building CronTriggers

CronTrigger的实例构造是通过TriggerBuilder类（设置触发器的主要共有属性）和CronScheduleBuilder类（设置CronTrigger类型触发器特有的属性）。首先静态导入如下内容，就能用DSL风格构造触发器实例了。

1
2
3

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

每天上午的八点到下午五点，每两分钟触发一次

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

每天上午10点42分触发

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

在周三上午10点42触发，此外，时区与系统默认时区不同

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

CronTrigger Misfire Instruction

当发生了misfire（“哑火”？），CronTrigger提供了一些指令用于告知Quartz该如何处理。这些指令是作为CronTrigger自身的常量来定义的（JavaDoc介绍了它们的行为），这些常量包括：

1
2
3

MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
MISFIRE_INSTRUCTION_DO_NOTHING
MISFIRE_INSTRUCTION_FIRE_NOW

所有类型的触发器都有Trigger.MISFIRE_INSTRUCTION_SMART_POLICY指令可用，这也是所有触发器默认的选择。在CronTrigger中，该“smart policy”会使用MISFIRE_INSTRUCTION_FIRE_NOW。CronTrigger.updateAfterMisfire()的JavaDoc介绍了具体的行为细节。

当构造CronTrigger的实例时，你也可以声明该属性（通过CronScheduleBuilder）

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

Quartz Tutorial 6 - TriggerListeners and JobListeners

Wed, 13 Sep 2017 00:00:00 +0800

Quartz Tutorial 6 - TriggerListeners and JobListeners

监听器是在调度器内部基于事件执行动作的对象。顾名思义，TriggerListeners监听与触发器相关的事件，JobListeners监听与作业有关的事件。

触发器相关的时间包括：触发、未触发（misfire）、触发结束（触发的作业执行完成）

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);
}

作业相关的事件包括：作业将要执行的通知，作业完成的通知

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);
}

Using Your Own Listeners

要创建一个监听器，需要创建一个实现了org.quartz.TriggerListener或者org.quartz.JobListener接口的类对象。然后在运行时向调度器注册，而且必须要给它一个名字（或者必须能通过getName()方法得知它们的名字）

为了用着方便，除了动手实现接口之外，你也可以通过扩展JobListenerSupport或TriggerListenerSupport类，然后只需要重写你用得上的事件处理方法即可。

监听器使用调度器的ListenerManager方法向调度器注册，此外还用到了一个匹配器用于描述该监听器需要监听的作业或触发器。

监听器是运行时向调度器注册的，而且不随着作业或触发器一起存储在JobStore中。这是因为监听器一般作为与应用的集成点。因此，每次程序运行，监听器都要向调度器注册

添加对特定作业监听的JobListener

`1`	`scheduler.getListenerManager().addJobListener(myJobListener, KeyMatcher.keyEquals(new JobKey("myJobName", "myJobGroup")));`

加入关于匹配器等其他类的静态导入，能把代码写得更清晰点：

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

上例就可以写成

`1`	`scheduler.getListenerManager().addJobListener(myJobListener, keyEquals(jobKey("myJobName", "myJobGroup")));`

添加对特定组内所有任务进行监听的监听器

`1`	`scheduler.getListenerManager().addJobListener(myJobListener, groupEquals("myJobGroup"));`

添加对两个特定组内所有任务进行监听的监听器

`1`	`scheduler.getListenerManager().addJobListener(myJobListener, or(groupEquals("myJobGroup1"), groupEquals("myJobGroup2")));`

添加对所有任务进行监听的监听器

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

同样的，注册触发器监听器也是这样子。

大部分Quartz的用户都不会用到监听器，但它还是很有用的，它可以让你的程序监听事件通知而作业本身又不需要显式通知。

Quartz Tutorial 7 - SchedulerListeners

Wed, 13 Sep 2017 00:00:00 +0800

Quartz Tutorial 7 - SchedulerListeners

SchedulerListener跟TriggerListener和JobListener很类似。当然，它接收来自调度器自身的事件通知，而不是某个特定的作业或者触发器。

调度器相关的事件包括：作业/触发器的添加，作业/触发器的移除，一系列调度器内部的错误，调度器被关闭及其它事件。

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 triggerPaused(String triggerName, String triggerGroup);
    public void triggerResumed(String triggerName, String triggerGroup);
    public void jobPaused(String jobName, String jobGroup);
    public void jobResumed(String jobName, String jobGroup);
    public void schedulerError(String msg, SchedulerException cause);
    public void schedulerStarted();
    public void schedulerInStandbyMode();
    public void schedulerShutdown();
    public void schedulingDataCleared();
}

调度器监听器是使用调度器的ListenerManager来注册的。调度器监听器实际上可以是任何实现了org.quartz.SchedulerListener接口的对象。

注册调度器监听器

`1`	`scheduler.getListenerManager().addSchedulerListener(mySchedulerListener);`

移除调度器监听器

`1`	`scheduler.getListenerManager().removeSchedulerListener(mySchedulerListener);`

Quartz Tutorial 4 - Simple Trigger

Sat, 09 Sep 2017 00:00:00 +0800

Quartz Tutorial 4 - Simple Trigger

当你的某个任务仅需要在某个特定时间执行一次，或者在某个特定时间之后以固定间隔重复特定的次数，此时就用到了SimpleTrigger了。例如，你需要在某年月日某时分秒触发作业的执行，或者在那个时间后再触发5次，间隔10秒钟。

通过这些，很容易就能想到SimpleTrigger所包含的属性：开始时间，结束时间，重复次数，还有重复间隔。所有这些属性都确实存在，跟你想的确实一样。只是对于结束时间属性，有一些特殊的地方。

重复的次数可以为0、正整数或者是一个常量SimpleTrigger.REPEAT_INDEFINITELY。重复间隔属性必须是0或者一个正的long类型数字，它表示毫秒数。要注意，当重复间隔设为0的时候，触发器将会被同步地触发（或者是调度器所能做到的尽可能靠近的触发）

如果你熟悉Quartz的DateBuilder类，当你想通过你要创建的开始时间startTime(或结束时间endTime)来计算触发的次数，你就知道这个类特别有用。

如果特别声明了结束时间endTime属性，，那么它将覆盖掉重复次数这一属性。比如你可以创建一个每十秒重复一次直到某个特定时间停止的触发器-你不需要计算在起止时间内到底重复了多少次，甚至你可以将重复次数属性赋值为REPEAT_INDEFINITELY（你也可以降之设定为一个足够大的值，保证该值大于它将要实际重复的次数）

SimpleTrigger的实例构造是通过TriggerBuilder类（设置触发器的主要共有属性）和SimpleScheduleBuilder类（设置SimpleTrigger类型触发器特有的属性）。首先静态导入如下类型，就能用DSL风格构造触发器实例了。

1
2
3

import static org.quartz.TriggerBuilder.*;
import static org.quartz.SimpleScheduleBuilder.*;
import static org.quartz.DateBuilder.*;

下面是定义触发器的多个例子，各自存在不同要点：

特定时刻触发，无重复

SimpleTrigger trigger = (SimpleTrigger) newTrigger()
    .withIdentity("trigger1", "group1")
    .startAt(startTime)     // 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 we omitted), "now" is implied
    .withSchedule(simpleSchedule()
        .withIntervalInSeconds(10)
        .withRepeatCount(10))   // note that 10 repeats will given a total of 11 firings
    .forJob(myJob)  // identify job with handle to its JobDetail itself
    .build();

仅五分钟后触发一次

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

立即触发，然后每5分钟触发一次，直到22:00

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

下一小时一到立即触发，然后每两小时触发一次，永久重复

trigger = newTrigger()
    .withIdentity("trigger8")   // because group isn't specificated, "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将会生成一个随机的名字，如果你没有调用startAt(...)，它将会假定你要使用当前时间（立即触发）

SimpleTrigger MisFire Instructions

当发生了misfire（“哑火”？），SimpleTrigger提供了一些指令用于告知Quartz该如何处理。这些指令是作为SimpleTrigger自身的常量来定义的（JavaDoc介绍了它们的行为），这些常量包括：

// Misfire Instruction Constants of Simple Trigger

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.MISFIRE_INSTRUCTION_SMART_POLICY指令可用，这也是所有触发器默认的选择。

如果使用了“smart policy”，SimpleTrigger在它多种选项内动态选择，具体取决于该触发器实例的配置和状态。SimpleTrigger.updateAfterMisfire()方法的JavaDoc解释了动态行为的更多细节。

当然，你也可以在构建SimpleTrigger实例的时候设置上这一属性（通过SimpleScheduleBuilder）

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

Quartz Tutorial 3 - More About Triggers

Mon, 04 Sep 2017 00:00:00 +0800

Quartz Tutorial 3 - More About Triggers

类似作业，触发器也是一样易于使用，只是它还包含了一些可自定义的选项。如果想要用Quartz用得飞起，那你需要了解它们。当然首先应该说明，Quartz提供了多种类型的触发器供你使用。

在后面两节，你能了解两个主流使用的触发器SimpleTrigger和CronTrigger。

Common Trigger Attributes

先不提所有的触发器都会有的用于标识自己的TriggerKey属性，还有很多其它共有的属性，这些共有的属性可以在你构建一个触发器定义的时候使用TriggerBuilder进行设置。

这些属性如下所示：

jobKey属性表示该触发器被触发时，应该执行的作业的标识符
startTime属性表示该触发器的调度器开始干活的时间。这个值是java.util.Data对象，定义了一个时刻。对于某些类型的触发器，它们确实是在开始时间触发的，而另一些就是简单标记了一个时间，其余的触发都是在这个时间之后的。比如你定义了一个触发器并告知调度器“一月份每隔五天”触发一次，然后你设置开始时间是四月一号，那么要过好几个月，该触发器才会被首次触发。
endTime属性表示该触发器的调度器停止干活的时间。

其他属性在接下来几个小节讨论

Priority

有些时候会出现这样的情况，某个时刻有很多个触发器需要被触发，但是Quartz并没有足够的工作线程/资源让这些触发器通通立即触发。那么这个时候，你可能想要给他们指定一个优先级，来告知Quartz应该先触发哪个后触发哪个。这个时候就需要用到priority属性了。如果某个时刻有N个触发器需要被触发，但是只有Z个工作线程可用，那么前Z个优先级最高的触发器将会被首先触发。如果你没有显式指定优先级，那么触发器使用默认值5。任何整数值都可以用来指定优先级，包括负数。

注意：优先级只是在多触发器在同一时刻触发的时候才会用于比较。一个应该在10:59的触发器毕竟早于11:00的触发器。

注意：如果一个触发器的作业被检测到需要恢复，它的恢复调度与它原来的触发优先级相同

Misfire Instructions

触发器的另一个重要属性是它的“哑火指令”。多种情况会导致一个触发错过了它的触发，比如调度器被关闭，比如Quartz的线程池没有可用线程去执行作业等。不同类型的触发器有不同的“哑火指令”。它们默认使用“智能策略”的指令，它对于不同类型的触发器及配置有着不同行为。当调度器启动，它搜索所有出现哑火的持续的触发器，然后按照它们各自的哑火指令更新它们的状态。你开始用Quartz，就应该去熟悉各个触发器的呀或执行，它们在JavaDoc中有着详细的解释。在之后对于某些触发器类型的讲解中，将会详细介绍各自的该属性。

`Calendars`

Quartz的Calendar对象(不是java.util.Calendar对象)能够在触发器被定义的时候与之关联并存到调度器中。当需要排除某些触发时间的时候，它很有用。举个例子，你可以在周工作日(周一到周五)上午九点半执行某个作业，然后可以添加一个Calendar排除那些法定假日。

Calendar可以是任何实现了Calendar接口的可序列化对象。定义如下

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

注意这些方法的参数都是long类型的。你可能觉得有些不好，因为时间戳都精确到毫秒了，这是因为Quartz想要尽可能精确的去掉某些时间。但有些时候你可能需要去掉全天的，那么你可以使用org.quartz.impl.HolidayCalendar类，它就是做这个的。

Calendar实例化后必须使用调度器的addCalendar()注册给调度器。如果你使用的是HolidayCalendar，实例化完成之后，你要使用addExcludedData(Date date)方法告知调度器你要排除的日子。同一个Calendar实例可以被多个触发器使用。

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

触发器的实例化/构建的细节将会在后面机型讨论。上面的代码只是创建两个触发器，它们都是每日触发的，但都会跳过那些已排除的日期。

如果有更多需要，请查看org.quartz.impl.calendar包，里面有Calendar的多种实现方式。

Quartz Tutorial 2 - More About Jobs and Job Details

Sun, 03 Sep 2017 00:00:00 +0800

Quartz Tutorial 2 - More About Jobs and Job Details

就像是在上一节看到的，Job相当容易去实现，毕竟接口中只有一个execute方法。这里只需要再了解一些别的事情你就能理解作业的本质，关于Job接口中的execute方法，关于JobDetail类。

当一个实现了Job接口的类定义完成，它要实际进行的工作也就很清晰了，但Quartz还需要知道你希望一个作业实例所具有的其它属性。那些属性是通过JobDetail类来告知Quartz的，前面已经简单介绍过。

JobDetail实例是用JobBuilder类来构建的，可以使用静态导入该类中所有的静态方法，使代码具有DSL风格。

`1`	`import static org.quartz.JobBuilder.*;`

首先花点时间讨论一下Job的本质和一个Job实例在Quartz内的生命周期。首先回顾一下第一节中的代码

SchedulerFactory schedFact = new org.quartz.impl.StdSchedulerFactory();

Scheduler sched = schedFact.getScheduler();

sched.start();

// define the job and tie it to our HelloJob class
JobDetail job = JobBuilder.newJob(HelloJob.class)
    .withIdentity("myJob", "group1")
    .build();

// Trigger the job to run now, and then every 40 seconds
Trigger trigger = TriggerBuilder
    .newTrigger()
    .withIdentity("myTrigger", "group1")
    .startNow()
    .withSchedule(SimpleScheduleBuilder
        .simpleSchedule()
        .withIntervalInSeconds(40)
        .repeatForever())
    .build();

// Tell quartz to schedule the job using our trigger
sched.scheduleJob(job, trigger);

作业的实体类HelloJob是这样定义的

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

注意到，我们给调度器传递了一个JobDetail实例，它知道我们要执行的作业的实际类型，因为我们构造它的时候传递进去了。每次调度器执行这个作业之前，它都会先创建一个新的HelloJob实例，然后调用execute方法。作业一旦执行完毕，调度器对这个对象实例的引用便会丢弃，这个实例就会被垃圾回收。能这样做的一个条件是，Job的实现类必须有一个公共的无参构造器(当然，此时使用的是默认的JobFactory)；另一个就是这个实现类不需要有什么表示状态的数据成员，这没什么意义，一旦作业执行完毕，这些数据成员也就不再保留了。

那么我们如何为作业实例提供属性或者配置？或者怎样在执行过程中继续跟踪它的状态呢？这里提供了JobDataMap，它也是JobDetail对象的一部分。

`JobDataMap`

JobDataMap可以持有你想让作业执行期间能访问到的（可序列化的）数据对象，它是Map接口的一种实现，此外还添加了一些方法使之能方便存取基本类型的数据。

如下一段代码就是在定义/构建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();

如下代码就是在作业执行期间，去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（将会在本系列的JobStore一节讨论），你应当慎重决定将什么放入到JobDataMap，因为该对象将会被序列化，因此同意出现类版本问题。当然标准的Java类型应该很安全，但如果有人修改了类型定义而你又序列化了实例，要小心，免得破坏了兼容性。你也可以考虑将JDBC-JobStore和JobDataMap置于只能放基本类型和字符串的模式，这样就能消除未来可能的序列化问题。

如果在你的作业类中添加了set访问器，而且它的名字与JobDataMap中某个键的名字是符合的（例如setJobSays(String val)与jobSays），那么Quartz的默认JobFactory类会在实例化这个作业的时候自动调用这些方法，这样就不用在代码中显式获取了。

触发器也可以拥有与之关联的JobDataMap。当你有个储存在调度器中的作业要被多个触发器常规/重复使用的时候，它就非常有用了。对于每次互相独立的触发，你可以给作业提供不同的输入数据。

在作业执行期间可以在JobExecutionContext找到一个JobDataMap，它合并了在JobDetail和Trigger中的JobDataMap，而且，对于相同名字的值，后者将会覆盖掉前者。

下面是一个从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()方法也确实清晰了。而且像是set构造器可以用IDE自动生成。

Job “Instance”

有很多用户对于一个“作业实例”的确切形式感到疑惑，我们在这一节和后面两小节将之解释清楚。

你可以创建一个单独的作业类，然后通过在调度器内创建多个JobDetail实例来保存它的“实例定义”，每个JobDetail都有他自己的属性集合及JobDataMap，然后将它们都放到调度器中。

例如，你可以创建一个实现了Job接口的类，叫做SalesReportJob。这个作业类需要接受一个参数，来得知消费者的名字然后生成针对他的消费报告。因此可能需要创建多个作业的定义，例如“SalesReportForJoe”或“SalesReportForMike”。

当一个触发器被触发，其关联的JobDetail实例将会被加载，然后它用到的作业类将会通过调度器配置的JobFactory来实例化。默认的JobFactory只是简单的调用newInstance()，然后尝试调用名字和JobDataMap中名字匹配的set访问器来赋值。或许你会需要构造你自己的JobFactory的实现来做一些事，例如你自己的控制反转或依赖注入容器来生成/初始化作业实例。

我们将每个JobDetail称为一个“作业定义”或者“作业明细的实例”；我们还将每个正在执行的作业称为一个“作业实例”或“作业定义的一个实例”。通常，如果我们只是简单用到了“作业”一词，这指的是一个命名好的定义，或者作业明细。如果我们要说Job接口的实现类，我们会使用“作业类”这个词语。

Job State and Concurrency

现在我们将解释一些关于作业的状态数据(JobDataMap)和并发性。它们是能加到你的作业类定义上的注解，它们将会影响Quartz的行为。

@DisallowConcurrentExecution注解是加到作业类上的，它告知Quartz不要并发执行给定作业的多个实例。注意这里的措辞，这是反复推敲过的。在上一节的例子中，如果“SalesReportJob”有这个注解，在给定时刻，只能有一个“SalesReportForJoe”运行，但是它可以和一个“SalesReportForMike”同时运行。这个限制是基于JobDetail，而不是基于作业类的实例。

@PersistJobDataAfterExecution也是给作业类加的注解。它告知Quartz，只有execute方法完全成功执行完毕之后才更新存储JobDetail的JobDataMap，因为同一个作业的下一次执行将会使用更新后的值，而不是原来的值。就像上面介绍的@DisallowConcurrentExecution注解，它也是限制作业定义实例而不是作业类实例的。

如果你使用了@PersistJobDataAfterExecution注解，那你也应当认真考虑是否也使用@DisallowConcurrentExecution注解，这是为了避免同一作业的两个实例同时执行时出现可能的竞态条件。

Other Attributes Of Jobs

这里是其它能通过JobDetail对象对作业进行定义的属性：

Durability - 如果一个作业是非耐用的，那么一旦调度器中没有活动触发器与之关联，他将会被自动删除。换句话说，非持久作业的生命周期受到与它关联的触发器限制。
RequestsRecovery - 如果一个作业“请求恢复”，而且在它执行期间被调度器“强制关闭”（例如进程运行中崩溃，或者电脑关机），那么当调度器再次启动时，这个作业也将再次执行。这种情况下，JobExecutionContext.isRecovering()将返回true。

JobExecutionException

最后，我们需要介绍Job.execute方法的一些其它细节。在该方法中，唯一能丢出的异常（包括运行时异常）类型是JobExecutionException。因此你应该使用try-catch语句块包裹execute方法的全部内容。你也应当花时间看看这个异常的文档，因为你的作业能够适应该异常来告知调度器具体使用哪种方式来处理这个出现异常的作业。

Quartz Tutorial 1 - Using Quartz & The Quartz API, Jobs and Trigger

Mon, 28 Aug 2017 00:00:00 +0800

Quartz Tutorial 1 - Using Quartz & The Quartz API, Jobs and Trigger

建议从Getting started with Quartz开始，先写一个非常简单的demo，基于这个demo，去理解后面的内容。

Using Quartz

在使用调度器之前，应当先实例化一个，这便用到了SchedulerFactory。也有人将factory的一个实例保存在了JDNI(Java Naming and Directory Interface)存储，因此实例化一个调度器也就更容易了。

调度器一旦被实例化完成，它可以被启动，可以处于等待模式，也可以被关闭。注意，一旦一个调度器关闭了，如果不重新实例化，它就不能重新启动。如果调度器并未被启动，或者整出一暂停状态，触发器也不会被触发（作业并不会执行）。

以下代码片段实例化并启动了一个调度器，并调度执行了一个作业

SchedulerFactory schedFact = new org.quartz.impl.StdSchedulerFactory();

Scheduler sched = schedFact.getScheduler();

sched.start();

// define the job and tie it to our HelloJob class
JobDetail job = JobBuilder.newJob(HelloJob.class)
    .withIdentity("myJob", "group1")
    .build();

// Trigger the job to run now, and then every 40 seconds
Trigger trigger = TriggerBuilder
    .newTrigger()
    .withIdentity("myTrigger", "group1")
    .startNow()
    .withSchedule(SimpleScheduleBuilder
        .simpleSchedule()
        .withIntervalInSeconds(40)
        .repeatForever())
    .build();

// Tell quartz to schedule the job using our trigger
sched.scheduleJob(job, trigger);

如上所示，用Quartz干活就是这么简单。

The Quartz API, Jobs and Trigger

Quratz API 的核心接口如下

Scheduler - 和调度器进行交互的核心API
Job - 你需要去实现的接口，里面放着你想让调度器执行的
JobDetail - 用于定义Job的实例
Trigger - 一个用于告知调度器去执行哪个作业的组件
JobBuilder - 用于定义/构建JobDetail的实例
TriggerBuilder - 用于定义/构建Trigger的实例

一个调度器(Scheduler)的生命周期以SchedulerFactory对它的创建为起始，到调用它的shutdown()为终止。创建了调度器实例后，就能添加、移除或者列出触发器及作业，或者执行其它调度相关的操作（例如暂停一个触发器）。但是，在调度器启动起来之前，它不会对任何触发器或作业执行任何实际操作。

Quartz提供了一系列定义了领域专用语言(DSL)的builder类，上一节已经见到过了，此处我们再贴出来

// define the job and tie it to our HelloJob class
JobDetail job = newJob(HelloJob.class)
    .withIdentity("myJob", "group1") // name "myJob", group "group1"
    .build();

// Trigger the job to run now, and then every 40 seconds
Trigger trigger = newTrigger()
    .withIdentity("myTrigger", "group1")
    .startNow()
    .withSchedule(simpleSchedule()
        .withIntervalInSeconds(40)
        .repeatForever())
    .build();

// Tell quartz to schedule the job using our trigger
sched.scheduleJob(job, trigger);

构建一个Job使用的方法是我们从JobBuilder类中静态导入的；同样的，构建一个触发器的方法也是从TriggerBuilder类中静态导入的，也有来自SimpleScheduleBuilder类中的。

DSL的静态导入可以通过以下这些import语句做到：

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.*;

这些ScheduleBuilder类有创建不同类型调度器的方法。其中DateBuilder类包含的一系列方法，能很容易创建各种“奇怪”时间点的java.util.Date的实例。

Jobs and Triggers

一个作业(Job)指的是一个实现了Job接口的类，该接口只有一个简单的方法

package org.quartz;

// the Job interface
public interface Job {
    public void execute(JobExecutionContext context) throws JobExecutionException;
}

当该作业的触发器被触发，它的execute方法就会被调度器的一个工作线程激活。传给这个方法的JobExecutionContext对象给这个作业对象传递了它“运行时刻”的环境信息-调度执行它的调度器的句柄，被触发从而引发该方法执行的那个个触发器的句柄，这个作业的JobDetail对象，还有一些其它的东西。

当作业被加入到调度器的时候，Quartz客户端(就是你的程序)就创建了一个JobDetail对象。它包含了各种用于设置这个作业的属性，包括一个JobDataMap，它可用于保存给定的作业类实例的状态信息。它是作业实例的本质定义，我们将会在下一节讨论它。

Trigger对象用于触发作业的执行。当你希望调度一个作业时，实例化一个触发器然后调整它的属性，使之调度安排符合预期。触发器也有与之关联的JobDataMap-当需要给作业传递特定参数的时候，它就非常有用了。Quartz提供了多种类型的触发器，但大家大多使用SimpleTrigger和CronTrigger。

当你需要“单触发”的运行（就是在某个给定时刻，某个作业只有单个的执行），或者你需要在给定的时刻触发作业，重复多次，在多次执行之间需要延迟，SimpleTrigger是非常好用的。如果你需要“类日历式”调度作业，例如“每周五下午”或者“每月10日的上午10:15”，CronTrigger是非常好用的。

为何Job和Trigger要组合存在呢？很多调度器并不刻意区分作业和触发器的概念。有些定义一个作业只是简单定义了一个执行时间（或调度）和一些小的作业标识符，有的就比较像是组合了Quartz的作业和触发器对象。开发Quartz的时候，我们决定分离调度和调度要执行的作业，是因为（我们认为）这有很多益处。

例如，作业可以被创建然后存储在调度器中，它跟触发器互相独立，多个触发器可以关联一个作业。另一个解耦的优势在于，当与某个作业关联的触发器被销毁之后，调度器依然能持有这个作业，使之能被重新调度，而不需要在定义一个该作业。这种做法也允许你修改或者替换触发器，而不用重新定义它关联的作业。

Identities

作业和触发器在被注册到Quartz调度器时，都给定了一个特征码。作业和调度器的特征码的存在，允许它们可以被放置在“group”中，这样就能更方便地管理作业和触发器了。在组内部，触发器或作业地名称必须是唯一的，作业或触发器的特征码是自身名和组名组合起来的。