quartz java實現的定時任務框架
概述瞭解Quartz體系結構 Quartz對任務排程的領域問題進行了高度的抽象,提出了排程器、任務和觸發器這3個核心的概念,並在org.quartz通過介面和類對重要的這些核心概念進行描述: ●Job:是一個介面,只有一個方法void execute(JobExecutionContext context),開發者實現該介面定義執行任務,JobExecutionContext類提供了排程上下文的各種資訊。Job執行時的資訊儲存在JobDataMap例項中; ●JobDetail:Quartz在每次執行Job時,都重新建立一個Job例項,所以它不直接接受一個Job的例項,相反它接收一個Job實現類,以便執行時通過newInstance()的反射機制例項化Job。因此需要通過一個類來描述Job的實現類及其它相關的靜態資訊 通過該類的建構函式可以更具體地瞭解它的功用:JobDetail(java.lang.String name, java.lang.String group, java.lang.Class jobClass),該建構函式要求指定Job的實現類,以及任務在Scheduler中的組名和Job名稱; ●Trigger:是一個類,描述觸發Job執行的時間觸發規則。主要有SimpleTrigger和CronTrigger這兩個子類。當僅需觸發一次或者以固定時間間隔週期執行,SimpleTrigger是最適合的選擇;而CronTrigger則可以通過Cron表示式定義出各種複雜時間規則的排程方案:如每早晨9:00執行,週一、週三、週五下午5:00執行等; ●Calendar:org.quartz.Calendar和java.util.Calendar不同,它是一些日曆特定時間點的集合(可以簡單地將org.quartz.Calendar看作java.util.Calendar的集合——java.util.Calendar代表一個日曆時間點,無特殊說明後面的Calendar即指org.quartz.Calendar)。一個Trigger可以和多個Calendar關聯,以便排除或包含某些時間點。 假設,我們安排每週星期一早上10:00執行任務,但是如果碰到法定的節日,任務則不執行,這時就需要在Trigger觸發機制的基礎上使用Calendar進行定點排除。針對不同時間段型別,Quartz在org.quartz.impl.calendar包下提供了若干個Calendar的實現類,如AnnualCalendar、MonthlyCalendar、WeeklyCalendar分別針對每年、每月和每週進行定義; ●Scheduler:代表一個Quartz的獨立執行容器,Trigger和JobDetail可以註冊到Scheduler中,兩者在Scheduler中擁有各自的組及名稱,組及名稱是Scheduler查詢定位容器中某一物件的依據,Trigger的組及名稱必須唯一,JobDetail的組和名稱也必須唯一(但可以和Trigger的組和名稱相同,因為它們是不同型別的)。Scheduler定義了多個介面方法,允許外部通過組及名稱訪問和控制容器中Trigger和JobDetail。 Scheduler可以將Trigger繫結到某一JobDetail中,這樣當Trigger觸發時,對應的Job就被執行。一個Job可以對應多個Trigger,但一個Trigger只能對應一個Job。可以通過SchedulerFactory建立一個Scheduler例項。Scheduler擁有一個SchedulerContext,它類似於ServletContext,儲存著Scheduler上下文資訊,Job和Trigger都可以訪問SchedulerContext內的資訊。SchedulerContext內部通過一個Map,以鍵值對的方式維護這些上下文資料,SchedulerContext為儲存和獲取資料提供了多個put()和getXxx()的方法。可以通過Scheduler# getContext()獲取對應的SchedulerContext例項; ●ThreadPool:Scheduler使用一個執行緒池作為任務執行的基礎設施,任務通過共享執行緒池中的執行緒提高執行效率。 Job有一個StatefulJob子介面,代表有狀態的任務,該介面是一個沒有方法的標籤介面,其目的是讓Quartz知道任務的型別,以便採用不同的執行方案。無狀態任務在執行時擁有自己的JobDataMap拷貝,對JobDataMap的更改不會影響下次的執行。而有狀態任務共享共享同一個JobDataMap例項,每次任務執行對JobDataMap所做的更改會儲存下來,後面的執行可以看到這個更改,也即每次執行任務後都會對後面的執行發生影響。 正因為這個原因,無狀態的Job可以併發執行,而有狀態的StatefulJob不能併發執行,這意味著如果前次的StatefulJob還沒有執行完畢,下一次的任務將阻塞等待,直到前次任務執行完畢。有狀態任務比無狀態任務需要考慮更多的因素,程式往往擁有更高的複雜度,因此除非必要,應該儘量使用無狀態的Job。 如果Quartz使用了資料庫持久化任務排程資訊,無狀態的JobDataMap僅會在Scheduler註冊任務時保持一次,而有狀態任務對應的JobDataMap在每次執行任務後都會進行儲存。 Trigger自身也可以擁有一個JobDataMap,其關聯的Job可以通過JobExecutionContext#getTrigger().getJobDataMap()獲取Trigger中的JobDataMap。不管是有狀態還是無狀態的任務,在任務執行期間對Trigger的JobDataMap所做的更改都不會進行持久,也即不會對下次的執行產生影響。 Quartz擁有完善的事件和監聽體系,大部分元件都擁有事件,如任務執行前事件、任務執行後事件、觸發器觸發前事件、觸發後事件、排程器開始事件、關閉事件等等,可以註冊相應的監聽器處理感興趣的事件。 圖1描述了Scheduler的內部元件結構,SchedulerContext提供Scheduler全域性可見的上下文資訊,每一個任務都對應一個JobDataMap,虛線表達的JobDataMap表示對應有狀態的任務: 圖1 Scheduler結構圖 一個Scheduler可以擁有多個Triger組和多個JobDetail組,註冊Trigger和JobDetail時,如果不顯式指定所屬的組,Scheduler將放入到預設組中,預設組的組名為Scheduler.DEFAULT_GROUP。組名和名稱組成了物件的全名,同一型別物件的全名不能相同。 Scheduler本身就是一個容器,它維護著Quartz的各種元件並實施排程的規則。Scheduler還擁有一個執行緒池,執行緒池為任務提供執行執行緒——這比執行任務時簡單地建立一個新執行緒要擁有更高的效率,同時通過共享節約資源的佔用。通過執行緒池元件的支援,對於繁忙度高、壓力大的任務排程,Quartz將可以提供良好的伸縮性。 提示: Quartz完整下載包examples目錄下擁有10多個例項,它們是快速掌握Quartz應用很好的例項。 使用SimpleTriggerSimpleTrigger擁有多個過載的建構函式,用以在不同場合下構造出對應的例項: ●SimpleTrigger(String name, String group):通過該建構函式指定Trigger所屬組和名稱; ●SimpleTrigger(String name, String group, Date startTime):除指定Trigger所屬組和名稱外,還可以指定觸發的開發時間; ●SimpleTrigger(String name, String group, Date startTime, Date endTime, int repeatCount, long repeatInterval):除指定以上資訊外,還可以指定結束時間、重複執行次數、時間間隔等引數; ●SimpleTrigger(String name, String group, String jobName, String jobGroup, Date startTime, Date endTime, int repeatCount, long repeatInterval):這是最複雜的一個建構函式,在指定觸發引數的同時,還通過jobGroup和jobName,讓該Trigger和Scheduler中的某個任務關聯起來。 通過實現 org.quartz..Job 介面,可以使 Java 類化身為可排程的任務。程式碼清單1提供了 Quartz 任務的一個示例: 程式碼清單1 SimpleJob:簡單的Job實現類
這個類用一條非常簡單的輸出語句實現了Job介面的execute(JobExecutionContext context) 方法,這個方法可以包含想要執行的任何程式碼。下面,我們通過SimpleTrigger對SimpleJob進行排程: 程式碼清單2 SimpleTriggerRunner:使用SimpleTrigger進行排程
首先在①處通過JobDetail封裝SimpleJob,同時指定Job在Scheduler中所屬組及名稱,這裡,組名為jGroup1,而名稱為job1_1。 在②處建立一個SimpleTrigger例項,指定該Trigger在Scheduler中所屬組及名稱。接著設定排程的時間規則。 最後,需要建立Scheduler例項,並將JobDetail和Trigger例項註冊到Scheduler中。這裡,我們通過StdSchedulerFactory獲取一個Scheduler例項,並通過scheduleJob(JobDetail jobDetail, Trigger trigger)完成兩件事: 1)將JobDetail和Trigger註冊到Scheduler中; 2)將Trigger指派給JobDetail,將兩者關聯起來。 當Scheduler啟動後,Trigger將定期觸發並執行SimpleJob的execute(JobExecutionContext jobCtx)方法,然後每 10 秒重複一次,直到任務被執行 100 次後停止。 還可以通過SimpleTrigger的setStartTime(java.util.Date startTime)和setEndTime(java.util.Date endTime)指定執行的時間範圍,當執行次數和時間範圍衝突時,超過時間範圍的任務執行不被執行。如可以通過simpleTrigger.setStartTime(new Date(System.currentTimeMillis() + 60000L))指定60秒鐘以後開始。 除了通過scheduleJob(jobDetail, simpleTrigger)建立Trigger和JobDetail的關聯,還有另外一種關聯Trigger和JobDetail的方式:
在這種方式中,Trigger通過指定Job所屬組及Job名稱,然後使用Scheduler的scheduleJob(Trigger trigger)方法註冊Trigger。有兩個值得注意的地方: 通過這種方式註冊的Trigger例項必須已經指定Job組和Job名稱,否則呼叫註冊Trigger的方法將丟擲異常; 引用的JobDetail物件必須已經存在於Scheduler中。也即,程式碼中①、②和③的先後順序不能互換。 在構造Trigger例項時,可以考慮使用org.quartz.TriggerUtils工具類,該工具類不但提供了眾多獲取特定時間的方法,還擁有眾多獲取常見Trigger的方法,如makeSecondlyTrigger(String trigName)方法將建立一個每秒執行一次的Trigger,而makeWeeklyTrigger(String trigName, int dayOfWeek, int hour, int minute)將建立一個每星期某一特定時間點執行一次的Trigger。而getEvenMinuteDate(Date date)方法將返回某一時間點一分鐘以後的時間。 使用CronTriggerCronTrigger 能夠提供比 SimpleTrigger 更有具體實際意義的排程方案,排程規則基於 Cron 表示式,CronTrigger 支援日曆相關的重複時間間隔(比如每月第一個週一執行),而不是簡單的週期時間間隔。因此,相對於SimpleTrigger而言,CronTrigger在使用上也要複雜一些。 Cron表示式Quartz使用類似於Linux下的Cron表示式定義時間規則,Cron表示式由6或7個由空格分隔的時間欄位組成,如表1所示: 表1 Cron表示式時間欄位
Cron表示式的時間欄位除允許設定數值外,還可使用一些特殊的字元,提供列表、範圍、萬用字元等功能,細說如下: ●星號(*):可用在所有欄位中,表示對應時間域的每一個時刻,例如,*在分鐘欄位時,表示“每分鐘”; ●問號(?):該字元只在日期和星期欄位中使用,它通常指定為“無意義的值”,相當於點位符; ●減號(-):表達一個範圍,如在小時欄位中使用“10-12”,則表示從10到12點,即10,11,12; ●逗號(,):表達一個列表值,如在星期欄位中使用“MON,WED,FRI”,則表示星期一,星期三和星期五; ●斜槓(/):x/y表達一個等步長序列,x為起始值,y為增量步長值。如在分鐘欄位中使用0/15,則表示為0,15,30和45秒,而5/15在分鐘欄位中表示5,20,35,50,你也可以使用*/y,它等同於0/y; ●L:該字元只在日期和星期欄位中使用,代表“Last”的意思,但它在兩個欄位中意思不同。L在日期欄位中,表示這個月份的最後一天,如一月的31號,非閏年二月的28號;如果L用在星期中,則表示星期六,等同於7。但是,如果L出現在星期欄位裡,而且在前面有一個數值X,則表示“這個月的最後X天”,例如,6L表示該月的最後星期五; ●W:該字元只能出現在日期欄位裡,是對前導日期的修飾,表示離該日期最近的工作日。例如15W表示離該月15號最近的工作日,如果該月15號是星期六,則匹配14號星期五;如果15日是星期日,則匹配16號星期一;如果15號是星期二,那結果就是15號星期二。但必須注意關聯的匹配日期不能夠跨月,如你指定1W,如果1號是星期六,結果匹配的是3號星期一,而非上個月最後的那天。W字串只能指定單一日期,而不能指定日期範圍; ●LW組合:在日期欄位可以組合使用LW,它的意思是當月的最後一個工作日; ●井號(#):該字元只能在星期欄位中使用,表示當月某個工作日。如6#3表示當月的第三個星期五(6表示星期五,#3表示當前的第三個),而4#5表示當月的第五個星期三,假設當月沒有第五個星期三,忽略不觸發; ● C:該字元只在日期和星期欄位中使用,代表“Calendar”的意思。它的意思是計劃所關聯的日期,如果日期沒有被關聯,則相當於日曆中所有日期。例如5C在日期欄位中就相當於日曆5日以後的第一天。1C在星期欄位中相當於星期日後的第一天。 Cron表示式對特殊字元的大小寫不敏感,對代表星期的縮寫英文大小寫也不敏感。 表2下面給出一些完整的Cron表示式的例項: 表2 Cron表示式示例
CronTrigger例項下面,我們使用CronTrigger對SimpleJob進行排程,通過Cron表示式制定排程規則,讓它每5秒鐘執行一次: 程式碼清單3 CronTriggerRunner:使用CronTrigger進行排程
執行CronTriggerRunner,每5秒鐘將觸發執行SimpleJob一次。預設情況下Cron表示式對應當前的時區,可以通過CronTriggerRunner的setTimeZone(java.util.TimeZone timeZone)方法顯式指定時區。你還也可以通過setStartTime(java.util.Date startTime)和setEndTime(java.util.Date endTime)指定開始和結束的時間。 在程式碼清單3的②處需要通過Thread.currentThread.sleep()的方式讓主執行緒睡眠,以便排程器可以繼續工作執行任務排程。否則在排程器啟動後,因為主執行緒馬上退出,也將同時引起排程器關閉,排程器中的任務都將相應銷燬,這將導致看不到實際的執行效果。在單元測試的時候,讓主執行緒睡眠經常使用的辦法。對於某些長週期任務排程的測試,你可以簡單地調整作業系統時間進行模擬。 使用Calendar在實際任務排程中,我們不可能一成不變地按照某個週期性的排程規則執行任務,必須考慮到實現生活中日曆上特定日期,就象習慣了大男人作風的人在2月14號也會有不同表現一樣。 下面,我們安排一個任務,每小時執行一次,並將五一節和國際節排除在外,其程式碼如程式碼清單4所示: 程式碼清單4 CalendarExample:使用Calendar
由於節日是每年重複的,所以使用org.quartz.Calendar的AnnualCalendar實現類,通過②、③的程式碼,指定五一和國慶兩個節日並通過AnnualCalendar#setDayExcluded(Calendar day, boolean exclude)方法新增這兩個日期。exclude為true時表示排除指定的日期,如果為false時表示包含指定的日期。 在定製好org.quartz.Calendar後,還需要通過Scheduler#addCalendar(String calName, Calendar calendar, boolean replace, boolean updateTriggers)進行註冊,如果updateTriggers為true,Scheduler中已引用Calendar的Trigger將得到更新,如④所示。 在⑥處,我們讓一個Trigger指定使用Scheduler中代表節日的Calendar,這樣Trigger就會避開五一和國慶這兩個特殊日子了。 任務排程資訊儲存在預設情況下Quartz將任務排程的執行資訊儲存在記憶體中,這種方法提供了最佳的效能,因為記憶體中資料訪問最快。不足之處是缺乏資料的永續性,當程式路途停止或系統崩潰時,所有執行的資訊都會丟失。 比如我們希望安排一個執行100次的任務,如果執行到50次時系統崩潰了,系統重啟時任務的執行計數器將從0開始。在大多數實際的應用中,我們往往並不需要儲存任務排程的現場資料,因為很少需要規劃一個指定執行次數的任務。 對於僅執行一次的任務來說,其執行條件資訊本身應該是已經持久化的業務資料(如鎖定到期解鎖任務,解鎖的時間應該是業務資料),當執行完成後,條件資訊也會相應改變。當然排程現場資訊不僅僅是記錄執行次數,還包括排程規則、JobDataMap中的資料等等。 如果確實需要持久化任務排程資訊,Quartz允許你通過調整其屬性檔案,將這些資訊儲存到資料庫中。使用資料庫儲存任務排程資訊後,即使系統崩潰後重新啟動,任務的排程資訊將得到恢復。如前面所說的例子,執行50次崩潰後重新執行,計數器將從51開始計數。使用了資料庫儲存資訊的任務稱為持久化任務。 通過配置檔案調整任務排程資訊的儲存策略其實Quartz JAR檔案的org.quartz包下就包含了一個quartz.properties屬性配置檔案並提供了預設設定。如果需要調整預設配置,可以在類路徑下建立一個新的quartz.properties,它將自動被Quartz載入並覆蓋預設的設定。 先來了解一下Quartz的預設屬性配置檔案: 程式碼清單5 quartz.properties:預設配置 ①叢集的配置,這裡不使用叢集 org.quartz.scheduler.instanceName = DefaultQuartzScheduler org.quartz.scheduler.rmi.export = false org.quartz.scheduler.rmi.proxy = false org.quartz.scheduler.wrapJobExecutionInUserTransaction = false ②配置排程器的執行緒池 org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 10 org.quartz.threadPool.threadPriority = 5 org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true ③配置任務排程現場資料儲存機制 org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore Quartz的屬性配置檔案主要包括三方面的資訊: 1)叢集資訊; 2)排程器執行緒池; 3)任務排程現場資料的儲存。 如果任務數目很大時,可以通過增大執行緒池的大小得到更好的效能。預設情況下,Quartz採用org.quartz.simpl.RAMJobStore儲存任務的現場資料,顧名思義,資訊儲存在RAM記憶體中,我們可以通過以下設定將任務排程現場資料儲存到資料庫中: 程式碼清單6 quartz.properties:使用資料庫儲存任務排程現場資料 … org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX org.quartz.jobStore.tablePrefix = QRTZ_①資料表字首 org.quartz.jobStore.dataSource = qzDS②資料來源名稱 ③定義資料來源的具體屬性 org.quartz.dataSource.qzDS.driver = oracle.jdbc.driver.OracleDriver org.quartz.dataSource.qzDS.URL = jdbc:oracle:thin:@localhost:1521:ora9i org.quartz.dataSource.qzDS.user = stamen org.quartz.dataSource.qzDS.password = abc org.quartz.dataSource.qzDS.maxConnections = 10 要將任務排程資料儲存到資料庫中,就必須使用org.quartz.impl.jdbcjobstore.JobStoreTX代替原來的org.quartz.simpl.RAMJobStore並提供相應的資料庫配置資訊。首先①處指定了Quartz資料庫表的字首,在②處定義了一個數據源,在③處具體定義這個資料來源的連線資訊。 你必須事先在相應的資料庫中建立Quartz的資料表(共8張),在Quartz的完整發布包的docs/dbTables目錄下擁有對應不同資料庫的SQL指令碼。 查詢資料庫中的執行資訊任務的現場儲存對於上層的Quartz程式來說是完全透明的,我們在src目錄下編寫一個如程式碼清單6所示的quartz.properties檔案後,重新執行程式碼清單2或程式碼清單3的程式,在資料庫表中將可以看到對應的持久化資訊。當排程程式執行過程中途停止後,任務排程的現場資料將記錄在資料表中,在系統重啟時就可以在此基礎上繼續進行任務的排程。 程式碼清單7 JDBCJobStoreRunner:從資料庫中恢復任務的排程
當代碼清單2中的SimpleTriggerRunner執行到一段時間後非正常退出,我們就可以通過這個JDBCJobStoreRunner根據記錄在資料庫中的現場資料恢復任務的排程。Scheduler中的所有Trigger以及JobDetail的執行資訊都會儲存在資料庫中,這裡我們僅恢復tgroup1組中名稱為trigger1_1的觸發器,這可以通過如②-1所示的程式碼進行過濾,觸發器的採用GROUP.TRIGGER_NAME的全名格式。通過Scheduler#rescheduleJob(String triggerName,String groupName,Trigger newTrigger)即可重新排程關聯某個Trigger的任務。 下面我們來觀察一下不同時期qrtz_simple_triggers表的資料: 1.執行程式碼清單2的SimpleTriggerRunner一小段時間後退出: 500){this.resized=true;this.style.width=500;}" align=center resized="true"> REPEAT_COUNT表示需要執行的總次數,而TIMES_TRIGGER表示已經執行的次數。 2.執行程式碼清單7的JDBCJobStoreRunner恢復trigger1_1的觸發器,執行一段時間後退出,這時qrtz_simple_triggers中的資料如下: 500){this.resized=true;this.style.width=500;}" align=center resized="true"> 首先Quartz會將原REPEAT_COUNT-TIMES_TRIGGER得到新的REPEAT_COUNT值,並記錄已經執行的次數(重新從0開始計算)。 3.重新啟動JDBCJobStoreRunner執行後,資料又將發生相應的變化: 500){this.resized=true;this.style.width=500;}" align=center resized="true"> 4.繼續執行直至完成所有剩餘的次數,再次查詢qrtz_simple_triggers表: 500){this.resized=true;this.style.width=500;}" align=center resized="true"> 這時,該表中的記錄已經變空。 值得注意的是,如果你使用JDBC儲存任務排程資料時,當你執行程式碼清單2的SimpleTriggerRunner然後退出,當再次希望執行SimpleTriggerRunner時,系統將丟擲JobDetail重名的異常: Unable to store Job with name: 'job1_1' and group: 'jGroup1', because one already exists with this identification. 因為每次呼叫Scheduler#scheduleJob()時,Quartz都會將JobDetail和Trigger的資訊儲存到資料庫中,如果資料表中已經同名的JobDetail或Trigger,異常就產生了。 本文使用quartz 1.6版本,我們發現當後臺資料庫使用MySql時,資料儲存不成功,該錯誤是Quartz的一個Bug,相信會在高版本中得到修復。因為HSQLDB不支援SELECT * FROM TABLE_NAME FOR UPDATE的語法,所以不能使用HSQLDB資料庫。 小結Quartz提供了最為豐富的任務排程功能,不但可以制定週期性執行的任務排程方案,還可以讓你按照日曆相關的方式進行任務排程。Quartz框架的重要元件包括Job、JobDetail、Trigger、Scheduler以及輔助性的JobDataMap和SchedulerContext。 Quartz擁有一個執行緒池,通過執行緒池為任務提供執行執行緒,你可以通過配置檔案對執行緒池進行引數定製。Quartz的另一個重要功能是可將任務排程資訊持久化到資料庫中,以便系統重啟時能夠恢復已經安排的任務。此外,Quartz還擁有完善的事件體系,允許你註冊各種事件的監聽器。 |