quartz - misfire错过触发时机的处理

1. 引言

要弄清楚作业的misfire，首先需要了解几个重要的概念：

** 触发器超时 **：

举个例子说明这个概念。比如调度引擎中有5个线程，然后在某天的下午2点 有6个任务需要执行，那么由于调度引擎中只有5个线程，所以在2点的时候会有5个任务会按照之前设定的时间正常执行，有1个任务因为没有线程资源而被延迟执行，这个就叫触发器超时。下面这些情况会造成触发器超时：

1）系统因为某些原因被重启。在系统关闭到重新启动之间的一段时间里，可能有些任务会 被 misfire；

2）Trigger 被暂停（suspend）的一段时间里，有些任务可能会被 misfire；

3）线程池中所有线程都被占用，导致任务无法被触发执行，造成 misfire；

4）有状态任务在下次触发时间到达时，上次执行还没有结束；

** misfireThreshold **：

misfireThreshold 即触发器超时的临界值，它可以在quartz.properties文件中配置。misfireThreshold是用来设置调度引擎对触发器超时的忍耐时间。假设misfireThreshold设置为6000(单位毫秒)，那么它的意思说当一个触发器超时时间大于misfireThreshold时，调度器引擎就认为这个触发器真正的超时(即Misfires)。换言之，如果一个触发器超时时间小于设定的misfireThreshold， 那么调度引擎则不认为触发器超时。也就是说这个job并没发生misfire。

quartz.properties中的配置

#判定job为misfire的阈值，这里设置为4S
org.quartz.jobStore.misfireThreshold = 4000

那么，调度器对于触发器超时但是超时时间小于misfireThreshold 或者 触发器已经misfire 的两种情况是怎么处理的呢？

2. 调度器怎么处理超时

2.1 timeout < misfireThreshold

为了制造超时的现象，实验时把线程池的大小设定为1，misfireThreshold设定为5S。实验中定义了两个job，一个是busy job，它在运行期休眠了3S（<misfireThreshold ），另一个是TimeoutJob。我们为TimeoutJob定义了一个timeoutTrigger触发器，触发器每隔1S会运行一次TimeoutJob，总共运行7次。通过这样的设定，在busy job占用了线程后，timeout job的触发器已经超时，在3秒的运行期中timeout job触发器错过了3次作业运行时机。OK，下面运行代码看看调度器怎么处理这个问题。

//BusyJob.java
public class BusyJob implements Job {
	private final Logger logger = LoggerFactory.getLogger(BusyJob.class);

	@Override
	public void execute(JobExecutionContext context) throws JobExecutionException {

		SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
		String jobName = context.getJobDetail().getKey().getName();

		logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 开始执行");

		try {
			Thread.sleep(3000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

		logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 执行完毕");
	}

}

//TimeoutJob.java
public class TimeoutJob implements Job {
	private final Logger logger = LoggerFactory.getLogger(TimeoutJob.class);

	@Override
	public void execute(JobExecutionContext context) throws JobExecutionException {

		SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

		String jobName = context.getJobDetail().getKey().getName();

		logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 开始执行");

		logger.info("[" + jobName + "]" + " 在  : [" + dateFormat.format(new Date()) + "] 执行完毕");
	}

}

//TimeoutButNotMisfireTest.java
/**
 * 触发器超时，但没有misfire
 */
public class TimeoutButNotMisfireTest {

	public static void main(String[] args) throws SchedulerException, InterruptedException {

		Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();

		// busy job
		JobDetail busyJob = JobBuilder //
				.newJob(BusyJob.class)//
				.withIdentity("busy job", "group1")//
				.build();

		SimpleTrigger busyTrigger = TriggerBuilder //
				.newTrigger() //
				.withIdentity("busy job trigger", "group1")//
				.startNow() //
				.withPriority(5) // 高优先级
				.withSchedule(SimpleScheduleBuilder.simpleSchedule() //
						.withRepeatCount(0) //
				).build();
		scheduler.scheduleJob(busyJob, busyTrigger);

		// timeout job
		JobDetail timeoutJob = JobBuilder //
				.newJob(TimeoutJob.class)//
				.withIdentity("timeout job", "group2")//
				.build();

		SimpleTrigger timeoutTrigger = TriggerBuilder //
				.newTrigger() //
				.withIdentity("timeout job trigger", "group2")//
				.startNow() //立即触发
				.withPriority(1) // 低优先级
				.withSchedule(SimpleScheduleBuilder.simpleSchedule() //
						.withIntervalInSeconds(1) //每隔1S触发一次
						.withRepeatCount(7) // 循环7次
				).build();
		scheduler.scheduleJob(timeoutJob, timeoutTrigger);

		scheduler.start();

		Thread.sleep(20 * 1000);

		scheduler.shutdown(true);

	}
}

运行结果：

INFO  11:31:11,420 com.github.thinwonton.quartz.sample.misfire.BusyJob: [busy job] 在  : [ 11:31:11] 开始执行
 INFO  11:31:14,420 com.github.thinwonton.quartz.sample.misfire.BusyJob: [busy job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,422 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,423 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,423 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:14,426 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 开始执行
 INFO  11:31:14,426 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:14] 执行完毕
 INFO  11:31:15,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:15] 开始执行
 INFO  11:31:15,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:15] 执行完毕
 INFO  11:31:16,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:16] 开始执行
 INFO  11:31:16,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:16] 执行完毕
 INFO  11:31:17,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:17] 开始执行
 INFO  11:31:17,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:17] 执行完毕
 INFO  11:31:18,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:18] 开始执行
 INFO  11:31:18,405 com.github.thinwonton.quartz.sample.misfire.TimeoutJob: [timeout job] 在  : [ 11:31:18] 执行完毕

通过观察运行结果，我们可以得到结论：

超时的触发器（超时时间小于misfireThreshold）在获取到运行线程后，将会立即运行前面错过的作业job，然后按照前面制定的周期性任务正常运行。

2.2 timeout >= misfireThreshold

对于触发器超时，并且超时时间大于设定的misfireThreshold 这种情况，调度器引擎为简单触发器SimpleTrigger和表达式CronTrigger提供了多种处理策略，我们可以在定义触发器时指定需要的策略。

2.2.1 对于SimpleTrigger的处理策略

• MISFIRE_INSTRUCTION_FIRE_NOW ： 调度引擎在MisFire的情况下，将任务(JOB)马上执行一次。需要注意的是 这个指令通常被用做只执行一次的Triggers，也就是没有重复的情况（non-repeating），如果这个Triggers的被安排的执行次数大于0。那么这个执行与 ** MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT ** 相同。

• MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT： 调度引擎重新调度该任务，repeat count 保持不变，按照原有制定的执行方案执行repeat count次，但是，如果当前时间，已经晚于 end-time，那么这个触发器将不会再被触发。举个例子：比如一个触发器设置的时间是 10:00 执行时间间隔10秒 重复10次。那么当10：07秒的时候调度引擎可以执行这个触发器的任务，然后按照原有制定的时间间隔执行10次。但是如果触发器设置的执行时间是10：00，结束时间为10：10，由于种种原因导致该触发器在10：11分才能被调度引擎触发，这时，触发器将不会被触发了。

• MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT： 这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 策略类似，唯一的区别就是调度器触发触发器的时间不是“现在” 而是下一个 scheduled time。

• MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT： 这个策略跟上面的策略 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 比较类似，调度引擎重新调度该任务，repeat count 是剩余应该执行的次数，也就是说本来这个任务应该执行10次，但是已经错过了3次，那么这个任务就还会执行7次。

• MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT： 这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT 策略类似，区别就是repeat count 是剩余应该执行的次数而不是全部的执行次数。比如一个任务应该在2:00执行，repeat count=5，时间间隔5秒， 但是在2:07才获得执行的机会，那任务不会立即执行，而是按照机会在2点10秒执行。

• MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY： 这个策略跟上面的 MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT 策略类似，但这个策略是忽略所有的超时状态，快速执行之前错过的次数，然后再按照之前制定的周期触发触发器。举个例子，一个SimpleTrigger 每个15秒钟触发, 但是超时了5分钟才获得执行的机会，那么这个触发器会被快速连续调用20次， 追上前面落下的执行次数。

2.2.2 对于CronTrigger的处理策略

• MISFIRE_INSTRUCTION_FIRE_ONCE_NOW： 指示触发器超时后会被立即安排执行。

• MISFIRE_INSTRUCTION_DO_NOTHING： 这个策略与策略 MISFIRE_INSTRUCTION_FIRE_ONCE_NOW 正好相反，它不会被立即触发，而是获取下一个被触发的时间，并且如果下一个被触发的时间超出了end-time 那么触发器就不会被执行。

3. 相关资料

代码：https://git.oschina.net/thinwonton/QuartzDemo

参考博文：http://www.faceye.net/search/110706.html

概念理解

misfire顾名思义, 就是quartz在应该触发trigger的时候未能及时将其触发( 原因可能是线程池没有线程可用 ), 这将导致trigger的下次触发时间落在在当前时间之前, 那么按照正常的quartz调度流程, 该trigger就再没有机会被调度了. 由于一个调度器实例在每次调度过程中都会有一定的睡眠时间, 所以存在一段时间内所有调度器实例都在睡眠, 这也会使trigger不能被及时触发. 因此调度器需要每隔一段时间( 15s ~ 60s )查看一次各个trigger的nextfiretime( 即下次触发的时间 ), 检查出是否有trigger的下次触发时间落在当前时间之前足够长的时间, 在这里系统设定了一个60s的域( misfireThreshold ), 当一个trigger下一次触发时间早于当前时间60s之外, 调度器判定该触发器misfire. 为了在发现触发器misfire之后启动相应的流程恢复trigger至正常的状态, quartz在trigger中可设置相应的策略. 

misfire策略

CronTrigger

• withMisfireHandlingInstructionDoNothing 

  不触发立即执行 
  等待下次Cron触发频率到达时刻开始按照Cron频率依次执行 

  • withMisfireHandlingInstructionIgnoreMisfires 

  以错过的第一个频率时间立刻开始执行 
  重做错过的所有频率周期后 
  当下一次触发频率发生时间大于当前时间后，再按照正常的Cron频率依次执行 

  • withMisfireHandlingInstructionFireAndProceed 

  以当前时间为触发频率立刻触发一次执行 
  然后按照Cron频率依次执行 

SimpleTrigger

• withMisfireHandlingInstructionFireNow 

  以当前时间为触发频率立即触发执行 
  执行至FinalTIme的剩余周期次数 
  以调度或恢复调度的时刻为基准的周期频率，FinalTime根据剩余次数和当前时间计算得到 
  调整后的FinalTime会略大于根据starttime计算的到的FinalTime值

• withMisfireHandlingInstructionIgnoreMisfires 

  以错过的第一个频率时间立刻开始执行 
  重做错过的所有频率周期 
  当下一次触发频率发生时间大于当前时间以后，按照Interval的依次执行剩下的频率 
  共执行RepeatCount+1次 

• withMisfireHandlingInstructionNextWithExistingCount 

  不触发立即执行 
  等待下次触发频率周期时刻，执行至FinalTime的剩余周期次数 
  以startTime为基准计算周期频率，并得到FinalTime 
  即使中间出现pause，resume以后保持FinalTime时间不变 

• withMisfireHandlingInstructionNowWithExistingCount 

  以当前时间为触发频率立即触发执行 
  执行至FinalTIme的剩余周期次数 
  以调度或恢复调度的时刻为基准的周期频率，FinalTime根据剩余次数和当前时间计算得到 
  调整后的FinalTime会略大于根据starttime计算的到的FinalTime值 

• withMisfireHandlingInstructionNextWithRemainingCount 

  不触发立即执行 
  等待下次触发频率周期时刻，执行至FinalTime的剩余周期次数 
  以startTime为基准计算周期频率，并得到FinalTime 
  即使中间出现pause，resume以后保持FinalTime时间不变

• withMisfireHandlingInstructionNowWithRemainingCount 

  以当前时间为触发频率立即触发执行 
  执行至FinalTIme的剩余周期次数 
  以调度或恢复调度的时刻为基准的周期频率，FinalTime根据剩余次数和当前时间计算得到 
  调整后的FinalTime会略大于根据starttime计算的到的FinalTime值

• MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT 

  此指令导致trigger忘记原始设置的starttime和repeat-count 
  触发器的repeat-count将被设置为剩余的次数 
  这样会导致后面无法获得原始设定的starttime和repeat-count值