Unmi’s blog：http://unmi.cc

Quartz cron 表达式的格式十分类似于 UNIX cron 格式，但还是有少许明显的区别。区别之一就是 Quartz 的格式向下支持到秒级别的计划，而 UNIX cron 计划仅支持至分钟级。许多我们的触发计划要基于秒级递增的(例如，每45秒)，因此这是一个非常好的差异。

在 UNIX cron 里，要执行的作业（或者说命令）是存放在 cron 表达式中的，在第六个域位置上。Quartz 用 cron 表达式存放执行计划。引用了 cron 表达式的 CronTrigger在计划的时间里会与 job 关联上。

另一个与 UNIX cron 表达式的不同点是在表达式中支持域的数目。UNIX 给出五个域(分、时、日、月和周)，Quartz 提供七个域。表 5.1 列出了 Quartz cron 表达式支持的七个域。

名称	是否必须	允许值	特殊字符
秒	是	0-59	, - * /
分	是	0-59	, - * /
时	是	0-23	, - * /
日	是	1-31	, - * ? / L W C
月	是	1-12 或 JAN-DEC	, - * /
周	是	1-7 或 SUN-SAT	, - * ? / L C #
年	否	空 或 1970-2099	, - * /

月份和星期的名称是不区分大小写的。FRI和 fri是一样的。
域之间有空格分隔，这和 UNIX cron 一样。无可争辩的，我们能写的最简单的表达式看起来就是这个了：
* * * ? * *
这个表达会每秒钟(每分种的、每小时的、每天的)激发一个部署的 job。

·理解特殊字符
同 UNIX cron 一样，Quartz cron 表达式支持用特殊字符来创建更为复杂的执行计划。然而，Quartz 在特殊字符的支持上比标准 UNIX cron 表达式更丰富了。

* 星号
使用星号(*) 指示着你想在这个域上包含所有合法的值。例如，在月份域上使用星号意味着每个月都会触发这个 trigger。
表达式样例：0 * 17 * * ?
意义：每天从下午5点到下午5:59中的每分钟激发一次 trigger。它停在下午 5:59 是因为值 17 在小时域上，在下午 6 点时，小时变为 18 了，也就不再理会这个 trigger，直到下一天的下午5点。
在你希望 trigger 在该域的所有有效值上被激发时使用 *字符。

? 问号
? 号只能用在日和周域上，但是不能在这两个域上同时使用。你可以认为 ?字符是 "我并不关心在该域上是什么值。" 这不同于星号，星号是指示着该域上的每一个值。? 是说不为该域指定值。
不能同时这两个域上指定值的理由是难以解释甚至是难以理解的。基本上，假定同时指定值的话，意义就会变得含混不清了：考虑一下，如果一个表达式在日域上有值11，同时在周域上指定了 WED。那么是要 trigger 仅在每个月的11号，且正好又是星期三那天被激发？还是在每个星期三的11号被激发呢？要去除这种不明确性的办法就是不能同时在这两个域上指定值。
只要记住，假如你为这两域的其中一个指定了值，那就必须在另一个字值上放一个 ?。
表达式样例：0 10,44 14 ? 3 WEB
意义：在三月中的每个星期三的下午 2:10 和 下午 2:44 被触发。

, 逗号
逗号 (,) 是用来在给某个域上指定一个值列表的。例如，使用值 0,15,30,45 在秒域上意味着每15秒触发一个 trigger。
表达式样例：0 0,15,30,45 * * * ?
意义：每刻钟触发一次 trigger。

/ 斜杠
斜杠 (/) 是用于时间表的递增的。我们刚刚用了逗号来表示每15分钟的递增，但是我们也能写成这样 0/15。
表达式样例：0/15 0/30 * * * ?
意义：在整点和半点时每15秒触发 trigger。

- 中划线
中划线 (-) 用于指定一个范围。例如，在小时域上的 3-8 意味着 "3,4,5,6,7 和 8 点。"  域的值不允许回卷，所以像 50-10 这样的值是不允许的。
表达式样例：0 45 3-8 ? * *
意义：在上午的3点至上午的8点的45分时触发 trigger。

L 字母
L 说明了某域上允许的最后一个值。它仅被日和周域支持。当用在日域上，表示的是在月域上指定的月份的最后一天。例如，当月域上指定了 JAN时，在日域上的 L会促使 trigger 在1月31号被触发。假如月域上是 SEP，那么 L 会预示着在9月30号触发。换句话说，就是不管指定了哪个月，都是在相应月份的时最后一天触发 trigger。
表达式 0 0 8 L * ?意义是在每个月最后一天的上午 8:00 触发 trigger。在月域上的 * 说明是 "每个月"。
当 L字母用于周域上，指示着周的最后一天，就是星期六 (或者数字7)。所以如果你需要在每个月的最后一个星期六下午的 11:59 触发 trigger，你可以用这样的表达式 0 59 23 ? * L。
当使用于周域上，你可以用一个数字与 L连起来表示月份的最后一个星期 X。例如，表达式 0 0 12 ? * 2L说的是在每个月的最后一个星期一触发 trigger。

W 字母
W 字符代表着平日 (Mon-Fri)，并且仅能用于日域中。它用来指定离指定日的最近的一个平日。大部分的商业处理都是基于工作周的，所以 W 字符可能是非常重要的。例如，日域中的 15W意味着 "离该月15号的最近一个平日。" 假如15号是星期六，那么 trigger 会在14号(星期四)触发，因为距15号最近的是星期一，这个例子中也会是17号（译者Unmi注：不会在17号触发的，如果是15W，可能会是在14号(15号是星期六)或者15号(15号是星期天)触发，也就是只能出现在邻近的一天，如果15号当天为平日直接就会当日执行）。W只能用在指定的日域为单天，不能是范围或列表值。

# 井号
# 字符仅能用于周域中。它用于指定月份中的第几周的哪一天。例如，如果你指定周域的值为 6#3，它意思是某月的第三个周五 (6=星期五，#3意味着月份中的第三周)。另一个例子 2#1意思是某月的第一个星期一 (2=星期一，#1意味着月份中的第一周)。注意，假如你指定 #5，然而月份中没有第 5 周，那么该月不会触发。

在默认情况下Quartz将任务调度的运行信息保存在内存中，这种方法提供了最佳的性能，因为内存中数据访问最快。不足之处是缺乏数据的持久性，当程序路途停止或系统崩溃时，所有运行的信息都会丢失。

比如我们希望安排一个执行100次的任务，如果执行到50次时系统崩溃了，系统重启时任务的执行计数器将从0开始。在大多数实际的应用中，我们往往并不需要保存任务调度的现场数据，因为很少需要规划一个指定执行次数的任务。

对于仅执行一次的任务来说，其执行条件信息本身应该是已经持久化的业务数据（如锁定到期解锁任务，解锁的时间应该是业务数据），当执行完成后，条件信息也会相应改变。当然调度现场信息不仅仅是记录运行次数，还包括调度规则、JobDataMap中的数据等等。

如果确实需要持久化任务调度信息，Quartz允许你通过调整其属性文件，将这些信息保存到数据库中。使用数据库保存任务调度信息后，即使系统崩溃后重新启动，任务的调度信息将得到恢复。如前面所说的例子，执行50次崩溃后重新运行，计数器将从51开始计数。使用了数据库保存信息的任务称为持久化任务。

通过配置文件调整任务调度信息的保存策略

其实Quartz JAR文件的org.quartz包下就包含了一个quartz.properties属性配置文件并提供了默认设置。如果需要调整默认配置，可以在类路径下建立一个新的quartz.properties，它将自动被Quartz加载并覆盖默认的设置。

先来了解一下Quartz的默认属性配置文件：

代码清单5 quartz.properties：默认配置

①集群的配置，这里不使用集群

org.quartz.scheduler.instanceName = DefaultQuartzScheduler

org.quartz.scheduler.rmi.export = false

org.quartz.scheduler.rmi.proxy = false

org.quartz.scheduler.wrapJobExecutionInUserTransaction = false

②配置调度器的线程池

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool

org.quartz.threadPool.threadCount = 10

org.quartz.threadPool.threadPriority = 5

org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

③配置任务调度现场数据保存机制

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

Quartz的属性配置文件主要包括三方面的信息：

1)集群信息；

2)调度器线程池；

3)任务调度现场数据的保存。

如果任务数目很大时，可以通过增大线程池的大小得到更好的性能。默认情况下，Quartz采用org.quartz.simpl.RAMJobStore保存任务的现场数据，顾名思义，信息保存在RAM内存中，我们可以通过以下设置将任务调度现场数据保存到数据库中：

代码清单6 quartz.properties：使用数据库保存任务调度现场数据

…

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

org.quartz.jobStore.tablePrefix = QRTZ_①数据表前缀

org.quartz.jobStore.dataSource = qzDS②数据源名称

③定义数据源的具体属性

org.quartz.dataSource.qzDS.driver = oracle.jdbc.driver.OracleDriver

org.quartz.dataSource.qzDS.URL = jdbc:oracle:thin:@localhost:1521:ora9i

org.quartz.dataSource.qzDS.user = stamen

org.quartz.dataSource.qzDS.password = abc

org.quartz.dataSource.qzDS.maxConnections = 10

要将任务调度数据保存到数据库中，就必须使用org.quartz.impl.jdbcjobstore.JobStoreTX代替原来的org.quartz.simpl.RAMJobStore并提供相应的数据库配置信息。首先①处指定了Quartz数据库表的前缀，在②处定义了一个数据源，在③处具体定义这个数据源的连接信息。

你必须事先在相应的数据库中创建Quartz的数据表（共8张），在Quartz的完整发布包的docs/dbTables目录下拥有对应不同数据库的SQL脚本。

查询数据库中的运行信息

任务的现场保存对于上层的Quartz程序来说是完全透明的，我们在src目录下编写一个如代码清单6所示的quartz.properties文件后，重新运行代码清单2或代码清单3的程序，在数据库表中将可以看到对应的持久化信息。当调度程序运行过程中途停止后，任务调度的现场数据将记录在数据表中，在系统重启时就可以在此基础上继续进行任务的调度。

代码清单7 JDBCJobStoreRunner：从数据库中恢复任务的调度

package com.baobaotao.basic.quartz;

import org.quartz.Scheduler;

import org.quartz.SchedulerFactory;

import org.quartz.SimpleTrigger;

import org.quartz.Trigger;

import org.quartz.impl.StdSchedulerFactory;

public class JDBCJobStoreRunner {

    public static void main(String args[]) {

       try {

           SchedulerFactory schedulerFactory = new StdSchedulerFactory();

           Scheduler scheduler = schedulerFactory.getScheduler();

           // ①获取调度器中所有的触发器组

           String[] triggerGroups = scheduler.getTriggerGroupNames();

           // ②重新恢复在tgroup1组中，名为trigger1_1触发器的运行

           for (int i = 0; i < triggerGroups.length; i++) {

              String[] triggers = scheduler.getTriggerNames(triggerGroups[i]);

              for (int j = 0; j < triggers.length; j++) {

                  Trigger tg = scheduler.getTrigger(triggers[j],   triggerGroups[i]);

                  // ②-1:根据名称判断

                  if (tg instanceof SimpleTrigger&& tg.getFullName().equals("tgroup1.trigger1_1")) {

                     // ②-1:恢复运行

                     scheduler.rescheduleJob(triggers[j], triggerGroups[i], tg);

                  }

              }

           }

           scheduler.start();

       } catch (Exception e) {

           e.printStackTrace();

       }

    }

}

当代码清单2中的SimpleTriggerRunner执行到一段时间后非正常退出，我们就可以通过这个JDBCJobStoreRunner根据记录在数据库中的现场数据恢复任务的调度。Scheduler中的所有Trigger以及JobDetail的运行信息都会保存在数据库中，这里我们仅恢复tgroup1组中名称为trigger1_1的触发器，这可以通过如②-1所示的代码进行过滤，触发器的采用GROUP.TRIGGER_NAME的全名格式。通过Scheduler#rescheduleJob(String triggerName,String groupName,Trigger newTrigger)即可重新调度关联某个Trigger的任务。

下面我们来观察一下不同时期qrtz_simple_triggers表的数据：

1．运行代码清单2的SimpleTriggerRunner一小段时间后退出：

REPEAT_COUNT表示需要运行的总次数，而TIMES_TRIGGER表示已经运行的次数。

2．运行代码清单7的JDBCJobStoreRunner恢复trigger1_1的触发器，运行一段时间后退出，这时qrtz_simple_triggers中的数据如下：

首先Quartz会将原REPEAT_COUNT-TIMES_TRIGGER得到新的REPEAT_COUNT值，并记录已经运行的次数（重新从0开始计算）。

3．重新启动JDBCJobStoreRunner运行后，数据又将发生相应的变化：

4．继续运行直至完成所有剩余的次数，再次查询qrtz_simple_triggers表：

这时，该表中的记录已经变空。

值得注意的是，如果你使用JDBC保存任务调度数据时，当你运行代码清单2的SimpleTriggerRunner然后退出，当再次希望运行SimpleTriggerRunner时，系统将抛出JobDetail重名的异常：

Unable to store Job with name: 'job1_1' and group: 'jGroup1', because one already exists with this identification.

因为每次调用Scheduler#scheduleJob()时，Quartz都会将JobDetail和Trigger的信息保存到数据库中，如果数据表中已经同名的JobDetail或Trigger，异常就产生了。

本文使用quartz 1.6版本，我们发现当后台数据库使用MySql时，数据保存不成功，该错误是Quartz的一个Bug，相信会在高版本中得到修复。因为HSQLDB不支持SELECT * FROM TABLE_NAME FOR UPDATE的语法，所以不能使用HSQLDB数据库。

小结

Quartz提供了最为丰富的任务调度功能，不但可以制定周期性运行的任务调度方案，还可以让你按照日历相关的方式进行任务调度。Quartz框架的重要组件包括Job、JobDetail、Trigger、Scheduler以及辅助性的JobDataMap和SchedulerContext。

Quartz拥有一个线程池，通过线程池为任务提供执行线程，你可以通过配置文件对线程池进行参数定制。Quartz的另一个重要功能是可将任务调度信息持久化到数据库中，以便系统重启时能够恢复已经安排的任务。此外，Quartz还拥有完善的事件体系，允许你注册各种事件的监听器。

各种企业应用几乎都会碰到任务调度的需求，就拿论坛来说：每隔半个小时生成精华文章的RSS文件，每天凌晨统计论坛用户的积分排名，每隔30分钟执行锁定用户解锁任务。

对于一个典型的MIS系统来说，在每月1号凌晨统计上个月各部门的业务数据生成月报表，每半个小时查询用户是否已经有快到期的待处理业务……，这样的例子俯拾皆是，不胜枚举。

任务调度本身涉及到多线程并发、运行时间规则制定和解析、场景保持与恢复、线程池维护等诸多方面的工作。如果直接使用自定义线程这种刀耕火种的原始办法，开发任务调度程序是一项颇具挑战性的工作。Java开源的好处就是：领域问题都能找到现成的解决方案。

OpenSymphony所提供的Quartz自2001年发布版本以来已经被众多项目作为任务调度的解决方案，Quartz在提供巨大灵活性的同时并未牺牲其简单性，它所提供的强大功能使你可以应付绝大多数的调度需求。

Quartz 在开源任务调度框架中的翘首，它提供了强大任务调度机制，难能可贵的是它同时保持了使用的简单性。Quartz 允许开发人员灵活地定义触发器的调度时间表，并可以对触发器和任务进行关联映射。

此外，Quartz提供了调度运行环境的持久化机制，可以保存并恢复调度现场，即使系统因故障关闭，任务调度现场数据并不会丢失。此外，Quartz还提供了组件式的侦听器、各种插件、线程池等功能。

了解Quartz体系结构

Quartz对任务调度的领域问题进行了高度的抽象，提出了调度器、任务和触发器这3个核心的概念，并在org.quartz通过接口和类对重要的这些核心概念进行描述：

●Job：是一个接口，只有一个方法void execute(JobExecutionContext context)，开发者实现该接口定义运行任务，JobExecutionContext类提供了调度上下文的各种信息。Job运行时的信息保存在JobDataMap实例中；

●JobDetail：Quartz在每次执行Job时，都重新创建一个Job实例，所以它不直接接受一个Job的实例，相反它接收一个Job实现类，以便运行时通过newInstance()的反射机制实例化Job。因此需要通过一个类来描述Job的实现类及其它相关的静态信息，如Job名字、描述、关联监听器等信息，JobDetail承担了这一角色。

通过该类的构造函数可以更具体地了解它的功用：JobDetail(java.lang.String name, java.lang.String group, java.lang.Class jobClass)，该构造函数要求指定Job的实现类，以及任务在Scheduler中的组名和Job名称；

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

●Calendar：org.quartz.Calendar和java.util.Calendar不同，它是一些日历特定时间点的集合（可以简单地将org.quartz.Calendar看作java.util.Calendar的集合——java.util.Calendar代表一个日历时间点，无特殊说明后面的Calendar即指org.quartz.Calendar）。一个Trigger可以和多个Calendar关联，以便排除或包含某些时间点。

假设，我们安排每周星期一早上10:00执行任务，但是如果碰到法定的节日，任务则不执行，这时就需要在Trigger触发机制的基础上使用Calendar进行定点排除。针对不同时间段类型，Quartz在org.quartz.impl.calendar包下提供了若干个Calendar的实现类，如AnnualCalendar、MonthlyCalendar、WeeklyCalendar分别针对每年、每月和每周进行定义；

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

Scheduler可以将Trigger绑定到某一JobDetail中，这样当Trigger触发时，对应的Job就被执行。一个Job可以对应多个Trigger，但一个Trigger只能对应一个Job。可以通过SchedulerFactory创建一个Scheduler实例。Scheduler拥有一个SchedulerContext，它类似于ServletContext，保存着Scheduler上下文信息，Job和Trigger都可以访问SchedulerContext内的信息。SchedulerContext内部通过一个Map，以键值对的方式维护这些上下文数据，SchedulerContext为保存和获取数据提供了多个put()和getXxx()的方法。可以通过Scheduler# getContext()获取对应的SchedulerContext实例；

●ThreadPool：Scheduler使用一个线程池作为任务运行的基础设施，任务通过共享线程池中的线程提高运行效率。

Job有一个StatefulJob子接口，代表有状态的任务，该接口是一个没有方法的标签接口，其目的是让Quartz知道任务的类型，以便采用不同的执行方案。无状态任务在执行时拥有自己的JobDataMap拷贝，对JobDataMap的更改不会影响下次的执行。而有状态任务共享共享同一个JobDataMap实例，每次任务执行对JobDataMap所做的更改会保存下来，后面的执行可以看到这个更改，也即每次执行任务后都会对后面的执行发生影响。

正因为这个原因，无状态的Job可以并发执行，而有状态的StatefulJob不能并发执行，这意味着如果前次的StatefulJob还没有执行完毕，下一次的任务将阻塞等待，直到前次任务执行完毕。有状态任务比无状态任务需要考虑更多的因素，程序往往拥有更高的复杂度，因此除非必要，应该尽量使用无状态的Job。

如果Quartz使用了数据库持久化任务调度信息，无状态的JobDataMap仅会在Scheduler注册任务时保持一次，而有状态任务对应的JobDataMap在每次执行任务后都会进行保存。

Trigger自身也可以拥有一个JobDataMap，其关联的Job可以通过JobExecutionContext#getTrigger().getJobDataMap()获取Trigger中的JobDataMap。不管是有状态还是无状态的任务，在任务执行期间对Trigger的JobDataMap所做的更改都不会进行持久，也即不会对下次的执行产生影响。

Quartz拥有完善的事件和监听体系，大部分组件都拥有事件，如任务执行前事件、任务执行后事件、触发器触发前事件、触发后事件、调度器开始事件、关闭事件等等，可以注册相应的监听器处理感兴趣的事件。

图1描述了Scheduler的内部组件结构，SchedulerContext提供Scheduler全局可见的上下文信息，每一个任务都对应一个JobDataMap，虚线表达的JobDataMap表示对应有状态的任务：

图1 Scheduler结构图

一个Scheduler可以拥有多个Triger组和多个JobDetail组，注册Trigger和JobDetail时，如果不显式指定所属的组，Scheduler将放入到默认组中，默认组的组名为Scheduler.DEFAULT_GROUP。组名和名称组成了对象的全名，同一类型对象的全名不能相同。

Scheduler本身就是一个容器，它维护着Quartz的各种组件并实施调度的规则。Scheduler还拥有一个线程池，线程池为任务提供执行线程——这比执行任务时简单地创建一个新线程要拥有更高的效率，同时通过共享节约资源的占用。通过线程池组件的支持，对于繁忙度高、压力大的任务调度，Quartz将可以提供良好的伸缩性。

提示： Quartz完整下载包examples目录下拥有10多个实例，它们是快速掌握Quartz应用很好的实例。

package yixun.wap.tools;

import java.util.Timer;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class MyListener implements ServletContextListener {
    private Timer timer = null;
    public void contextInitialized(ServletContextEvent event) {
        timer = new Timer(true);//true 指定为后台线程
        // 设置任务计划，启动和间隔时间
        timer.schedule(new MyTask(), 0, 86400000);
//可写多个定时任务
    }

    public void contextDestroyed(ServletContextEvent event) {
        timer.cancel();
    }

}

第二步：创建一个时间任务类 MyTask.java

package yixun.wap.tools;

import java.util.TimerTask;

public class MyTask extends TimerTask {

  public void run() {
    // System.out.println("call at " + (new Date()));
    // TODO 此处添加具体任务代码
  }

}

第三步：在web.xml中添加一个监听器

<listener>

    <listener-class>
        yixun.wap.tools.MyListener
    </listener-class>
    <description>要定期执行的任务</description>
</listener> 

通过配置监听器，那么在web服务器启动的时候,任务也被启动,并且会周期性的执行
参考文章：http://www.blogjava.net/fastunit/archive/2008/02/15/180116.html