今天在做測試的時候發現了一個比較“怪異”的現象，其實就只是庸人自擾而已，現在將測試之后的理解記錄下來。
一、問題
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秒。