有時，Quartz無法在您需要的時間運行您的工作。 這有三個原因：

• 所有工作線程都忙于運行其他作業（可能具有更高的優先級）
• 調度程序本身已關閉
• 該作業是在過去的開始時間安排的（可能是編碼錯誤）

您可以通過簡單地在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和社區博客中解釋。