今天在做测试的时候发现了一个比较“怪异”的现象，其实就只是庸人自扰而已，现在将测试之后的理解记录下来。
一、问题
org.quartz.jobStore.misfireThreshold这个属性主要是作为判定misfire的条件之一(本篇不讲missfire各种策略)。现在的问题主要是本来要写个每个小时定时获取一张图片的任务，没有做本地任务存储，每次启动的时候将任务的启动时间设置为当前时间的整点
misfire的策略是do nothing
做测试的时候为了能过快速获取结果将cron写为
0 0/15 * * * ?
每15分钟获取一条，然后misfire的阈值设定为15分钟
org.quartz.jobStore.misfireThreshold=900000
在9:40分运行的时候，没有任何执行迹象；到9:45的时候，控制台打印过程执行
二、问题解释及验证
按我后来测试验证的结果，其实org.quartz.jobStore.misfireThreshold主要是用来判定第一个任务开始时间和当前时间之间比较是否超出misfire阈值，如果超出则判定missfire，中间所有任务不执行；如果不超出，则将所有任务重新执行。即调度器启动的初次启动时候会判断当前时间和任务执行历史第一次触发时间相比较是否超出missfir。
e阈值，即比较最大时间差判定历史任务走missfire策略。
验证的话：开始时间还是为当前时间的整点时刻，如上截图，但是cron改为
0 0/1 * * * ?
每一分钟执行一次，根据当前时间设定阈值，比如当前时间是10:34，阈值设定为35*60*1000，则控制台可以看到任务执行了36次，如果设定为33*60*1000，则控制台无报告任务执行
三、关于missfire的参考
这篇博客讲的挺详细的
https://blog.csdn.net/chen888999/article/details/78575492
然后重点关注，这个吧：
二、misfire产生的原因
我总结的产生misfire的原因有以下4点：
1、当job达到触发时间时，所有线程都被其他job占用，没有可用线程。
2、在job需要触发的时间点，scheduler停止了（可能是意外停止的）。
3、job使用了@DisallowConcurrentExecution注解，job不能并发执行，当达到下一个job执行点的时候，上一个任务还没有完成。
4、job指定了过去的开始执行时间，例如当前时间是8点00分00秒，指定开始时间为7点00分00秒。