- 所有工作线程都忙于运行其他作业（可能具有更高的优先级）
- 调度程序本身已关闭
- 该作业是在过去的开始时间安排的（可能是编码错误）
您可以通过简单地在quartz.properties自定义org.quartz.threadPool.threadCount （默认值为10）来增加工作线程的数量。 但是当整个应用程序/服务器/调度程序停机时，您实际上无法执行任何操作。 当Quartz无法触发给定的触发器时，这种情况称为不点火 。 您知道Quartz在发生时在做什么吗？ 事实证明，Quartz可以采用多种策略（称为失火指令 ），并且如果您没有考虑的话，还有一些默认设置。 但是，为了使您的应用程序健壮和可预测（尤其是在高负载或维护情况下），您应该真正确保触发器和作业的配置合理。
根据选择的触发器，有不同的配置选项（可用的失火说明 ）。 Quartz的行为也取决于触发器设置（所谓的智能策略 ）。 尽管失火说明已在文档中进行了描述，但我发现很难理解它们的真正含义。 因此，我创建了这篇小总结文章。
在深入探讨细节之前，应该先介绍另一个配置选项。 它是org.quartz.jobStore.misfireThreshold （以毫秒为单位），默认为60000（一分钟）。 它定义了触发器应该多长时间才被认为触发失败 。 在默认设置下，如果触发器是在30秒前触发的，那么Quartz会很高兴地运行它。 这种延迟不被认为是错误触发。 但是，如果在计划的时间之后61秒发现触发器，则特殊的失火处理程序线程会按照失火指令来处理它。 出于测试目的，我们将此参数设置为1000（1秒），以便我们可以快速测试错火。
简单触发，无需重复
在我们的第一个示例中，我们将看到计划仅运行一次的简单触发器如何处理错火：
val trigger = newTrigger().startAt(DateUtils.addSeconds(new Date(), -10)).build()相同的触发器，但显式设置了失火指令处理程序：
val trigger = newTrigger().startAt(DateUtils.addSeconds(new Date(), -10)).withSchedule(simpleSchedule().withMisfireHandlingInstructionFireNow() //MISFIRE_INSTRUCTION_FIRE_NOW).build()为了进行测试，我只是将触发器安排在10秒钟前运行（因此，它在创建之时要晚10秒钟！）在现实世界中，您通常不会安排这样的触发器。 而是假设触发器已正确设置，但是在安排好调度程序时，调度程序已关闭或没有任何可用的辅助线程。 然而，石英将如何处理这种特殊情况？ 在上面的第一个代码段中，未设置失火处理指令（在这种情况下，使用了智能策略 ）。 第二个代码段明确定义了发生错火时我们期望什么样的行为。 见表：
简单触发重复固定次数
这种情况要复杂得多。 想象一下，我们已经安排了一些工作来重复固定的次数：
val trigger = newTrigger().startAt(dateOf(9, 0, 0)).withSchedule(simpleSchedule().withRepeatCount(7).withIntervalInHours(1).WithMisfireHandlingInstructionFireNow() //or other).build() 在此示例中，假设触发器每小时触发8次（首次执行+ 7次重复），从今天上午9点开始（ startAt(dateOf(9, 0, 0)) 。因此，最后一次执行应在下午4点进行。假设由于某种原因，调度程序无法在上午9点和10点运行作业，并且在10:15 AM发现了这一事实，即2次点火失败，调度程序在这种情况下将如何表现？
简单触发无限重复
在这种情况下，触发器以给定的间隔重复无数次：
val trigger = newTrigger().startAt(dateOf(9, 0, 0)).withSchedule(simpleSchedule().withRepeatCount(SimpleTrigger.REPEAT_INDEFINITELY).withIntervalInHours(1).WithMisfireHandlingInstructionFireNow() //or other).build()
再次应该从今天的上午9点开始每小时触发一次（ startAt(dateOf(9, 0, 0)) （ startAt(dateOf(9, 0, 0)) 。然而，调度程序无法在上午9点和10点运行作业，并且它在10:15发现了这一事实AM，即2次点火失败，与简单触发器固定运行次数相比，这是更普遍的情况。
CRON触发器
CRON触发器是Quartz用户中最受欢迎的触发器。 但是，还有两个其他可用的触发器： DailyTimeIntervalTrigger （例如， 每25分钟触发一次 ）和CalendarIntervalTrigger （例如， 每5个月触发一次 ）。 它们支持在CRON和简单触发器中均不可能的触发策略。 但是，他们了解与CRON触发器相同的失火处理说明。
val trigger = newTrigger().withSchedule(cronSchedule("0 0 9-17 ? * MON-FRI").withMisfireHandlingInstructionFireAndProceed() //or other).build()在此示例中，触发器应在周一至周五的上午9点至下午5点之间每小时触发一次。 但是再次错过了前两次调用（因此触发器未触发），这种情况在上午10:15被发现。 请注意，可用的失火指令与简单触发器相比有所不同：
QTZ-283 注 ： QTZ-283：MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY不JDBCJobStore工作 -显然存在一个bug，当JDBCJobStore时，留意这个问题。
如您所见，各种触发器的行为基于实际设置而有所不同。 而且，即使提供了所谓的智能策略 ，该决定通常还是基于业务需求。 从本质上讲，有三种主要策略： 忽略 ， 立即运行，继续并丢弃并等待下一个 。 它们都有不同的用例：
当您要确保触发了所有计划执行时，请使用忽略策略，即使这意味着将触发多个未触发的触发器。 考虑一下一个工作，该工作根据最后一个小时的订单每小时生成一次报告。 如果服务器停机了8个小时，您仍然希望尽快生成报告。 在这种情况下， 忽略策略将简单地以计划程序的速度运行在该8个小时内计划的所有触发器。 他们将迟到几个小时，但最终将被执行。
当有定期执行的作业以及失火情况下，应立即使用*策略，但应尽快运行，但只能运行一次。 想一想每分钟都会清理/tmp目录的作业。 如果调度程序忙了20分钟并且最终可以运行此作业，则您不想运行20次！ 一个就足够了，但要确保它能尽快运行。 然后回到正常的一分钟间隔。
最后，当您要确保作业在特定的时间点运行时， next *策略很好。 例如，您需要每小时获取一个季度的股票价格。 它们会Swift变化，因此，如果您的工作失败了，并且已经整整20分钟了，那就不要打扰了。 您错过了5分钟的正确时间，现在您不在乎。 最好有一个差距而不是一个不正确的值。 在这种情况下，Quartz将跳过所有未执行的执行，而仅等待下一个执行。
参考： Quartz调度程序失火指令，由我们的JCG合作伙伴 Tomasz Nurkiewicz在Java和社区博客中解释。
翻译自: https://www.javacodegeeks.com/2012/04/quartz-scheduler-misfire-instructions.html
)
