大多数系统都会遇到关于定时任务相关的功能，例如定时备份数据库，定时修改某些信息，订单30分钟自动消单等，很多功能可以基于linux的定时命令去完成，有一些特殊的与业务系统紧密相关的任务则需要代码来完成，而定时调度这个功能其实有很多种实现方式，如果你的项目是基于spring的，通过配置就可以实现，或者我们可以使用JDK自带的timer，线程池来做。
那首先我们先简单的回顾下如何使用Timer和线程池（ScheduledExecutorService）来实现简单的定时调度任务。Timer和ScheduledExecutorService都可以用来做定时任务，有管理任务延迟执行("如1000ms后执行任务")以及周期性执行("如每500ms执行一次该任务")。但至从JDK1.5之后，建议采用后者，原因如下：
1、Timer对调度的支持是基于绝对时间,而不是相对时间的，由此任务对系统时钟的改变是敏感的;但ScheduledThreadExecutor只支持相对时间。
2、如果TimerTask抛出未检查的异常，Timer将会产生无法预料的行为。Timer线程并不捕获异常，所以 TimerTask抛出的未检查的异常会终止timer线程。此时，已经被安排但尚未执行的TimerTask永远不会再执行了，新的任务也不能被调度了。
3、Timer里面的任务如果执行时间太长，会独占Timer对象，使得后面的任务无法几时的执行 ，ScheduledExecutorService不会出现Timer的问题(除非你只搞一个单线程池的任务区)。
下面我们来看一下使用Timer和ScheduledExecutorService如何完成定时任务的创建：
今天我们的主角是Quartz，但需要声明的是这里并没有讲解关于quartz的基础知识，因为这些知识相对简单，大家可以自行百度了解。这里推荐官方地址：http://www.quartz-scheduler.org/
Quartz是OpenSymphony开源组织在Job scheduling领域又一个开源项目，它可以与J2EE与J2SE应用程序相结合也可以单独使用。Quartz可以用来创建简单或为运行十个，百个，甚至是好几万个Jobs这样复杂的程序。Jobs可以做成标准的Java组件或 EJBs。Quartz的最新版本为Quartz 2.2.3。
虽然我们使用spring可以很简单的通过配置来实现定时调度，但某些情况下我们需要将定时调度这些服务单独独立出来，这样的好处是可以使其单独部署，还可以让调度服务做中间件去完成其他的工作。今天我们就来看一下如果我们不使用spring，仅仅使用quartz如何实现任务的调度。
1、服务架构设计
定时服务作为独立的服务运行，与其他系统属于相辅相成的关系，既可以同步调用也可以异步调用。在设计之初，我是打算把它做一个异步系统来做的，它只负责任务的调度，而具体的执行是通过调用接口完成的。而任务的存储，目前是基于内存的，我试过基于数据库MYSQL的也没有什么大问题，只是配置上有一些不同。
2、需要考虑的问题
（1）接口设计
一般我们需要支持registe，delete，update，query等接口。这里我们作为demo，就定义一个registe接口。
（2）任务参数
其他系统要使用此系统，就要调用registe接口，那我们需要定义一个实体来存储任务信息，有些字段是必须的，例如：任务来自于哪里，任务属于哪个组（比如订单组），任务的类型（是一次性任务还是循环任务），任务开始的时间，任务的结束时间，任务执行的时候需要的数据（例如订单ID），如果任务是循环任务那循环参数是什么（是一天一次还是一周一次）。任务创建后，会产生一个唯一的key，也会有目前的执行状态（未开始，执行中，已结束）等。
对于任务参数我重点说一下关于任务的分类，这里我将任务分为两个类别（1）一次性任务，即执行完后一次后立刻结束不会再循环执行第二次（2）表达式任务，通过quartz支持的conf表达式来完成的任务，时间上比较灵活可以一次性也可以循环等。另外这里你可能有一个疑问为什么我们要开发这样一个接口？有些任务是系统内置的，他们在服务启动的时候就自动注册了，而有些任务是后期产生的，例如订单下单才会注册这个任务。下面我们通过一个实例来学习下具体的代码。
3、实际案例
（1）注册接口定义
（2）容器实例创建
在容器注册这些任务之前，我们需要让我们的服务启动并且创建容器实例。quartz通过SchedulerFactory工厂获取scheduler实例，调用其start方法完成启动。启动后我们可以在上下文对象中放入一些键值，在任务执行的时候来获取使用。
服务在启动时，加载quartz的调度实例后，调用loadSystemTasks方法，来加载系统级别的任务例如定时备份数据库这个任务，然后再调用loadTaskFromDb方法，去加载数据库中未完成的任务（因为服务停止后，任务并没有被执行，所以等服务启动后要先去加载这些未完成的任务）。
（3）任务保存逻辑
1、保存前，根据参数获取任务的key。
2、首先保存到数据库MYSQL中，防止服务宕机，任务丢失找不回。
3、再保存到quartz容器中，启动该任务。
通过scheduler的schedulerJob方法就可以将任务放置在容器中。
（4）任务实例
quartz容器在接受任务时，需要两个核心的参数（1）jobDetail 任务实例（2）trigger 时间配置；前者的意思是指明本次任务的执行信息，后者说明了这个任务的开始结束时间等。
所以我们设计接口的时候，也需要在调用scheduler.scheduleJob(jobDetail, trigger);的时候，需要传递两个参数，一个是jobDetail，一个是trigger。我们看他们是如何通过代码被创建的，我们进行了封装。
创建JobDetail的时候，我们要关联一个执行类，也就是ExecuteJob，并且告诉任务容器，这个任务唯一的key值，防止任务重复。创建trigger的时候，我们分为一次性任务和表达式任务。他们的构建方式是不同的。
ScheduleBuilder<?> scheduleBuilder = simpleSchedule();
ScheduleBuilder<?> scheduleBuilder = cronSchedule(timeJob.getConf());
表达式任务需要客户端传入一串表达式，而表达式如何写要再单独去学习，例如举个简单例子：0 0/2 * * * ? 每两分钟执行一次。
（5）任务执行类
刚才我们设置了我们的任务执行类ExecuteJob，这个类是说当任务到了时间点就会调用executeJob的某个方法来完成一系列的工作。
ExecuteJob实现了Job接口，重写execute方法，在这个方法里，我们来完成我们的任务，但也有可能我们需要调用外部的接口完成，但有一个问题就是这个任务执行是异步的，和spring容器是独立开来的，不能执行使用spring的实例。有这么几种方式来获取spring的容器实例：
（1）使用ApplicationUtil工具类获取。
（2）使用JobDataMap获取。
（3）使用上下文获取。
（6）quartz配置
Quartz支持基于内存和数据库来存储任务示例，配置如下：
当然，如果你选择基于数据库保存任务，还需要执行自带的一段数据库脚本，这个可以去百度找到。而如果你使用的是基于内存来管理任务，那么你就需要自己设计数据库来存储这些任务的信息了。就我的经验来讲，如果你的系统并发较高，任务较多建议使用基于数据库来存储，如果任务相对少，内存是完全够用的。