概述

各種企業應用幾乎都會碰到任務調度的需求，就拿論壇來說：每隔半個小時生成精華文章的RSS文件，每天凌晨統計論壇用戶的積分排名，每隔30分鐘執行鎖定用戶解鎖任務。

對于一個典型的MIS系統來說，在每月1號凌晨統計上個月各部門的業務數據生成月報表，每半個小時查詢用戶是否已經有快到期的待處理業務……，這樣的例子俯拾皆是，不勝枚舉。

任務調度本身涉及到多線程并發、運行時間規則制定和解析、場景保持與恢復、線程池維護等諸多方面的工作。如果直接使用自定義線程這種刀耕火種的原始辦法，開發任務調度程序是一項頗具挑戰性的工作。Java開源的好處就是：領域問題都能找到現成的解決方案。

OpenSymphony所提供的Quartz自2001年發布版本以來已經被眾多項目作為任務調度的解決方案，Quartz在提供巨大靈活性的同時并未犧牲其簡單性，它所提供的強大功能使你可以應付絕大多數的調度需求。

Quartz 在開源任務調度框架中的翹首，它提供了強大任務調度機制，難能可貴的是它同時保持了使用的簡單性。Quartz 允許開發人員靈活地定義觸發器的調度時間表，并可以對觸發器和任務進行關聯映射。

此外，Quartz提供了調度運行環境的持久化機制，可以保存并恢復調度現場，即使系統因故障關閉，任務調度現場數據并不會丟失。此外，Quartz還提供了組件式的偵聽器、各種插件、線程池等功能。

了解Quartz體系結構

?

Quartz對任務調度的領域問題進行了高度的抽象，提出了調度器、任務和觸發器這3個核心的概念，并在org.quartz通過接口和類對重要的這些核心概念進行描述：

●Job：是一個接口，只有一個方法void execute(JobExecutionContext context)，開發者實現該接口定義運行任務，JobExecutionContext類提供了調度上下文的各種信息。Job運行時的信息保存在JobDataMap實例中；

●JobDetail：Quartz在每次執行Job時，都重新創建一個Job實例，所以它不直接接受一個Job的實例，相反它接收一個Job實現類，以便運行時通過newInstance()的反射機制實例化Job。因此需要通過一個類來描述Job的實現類及其它相關的靜態信息，如Job名字、描述、關聯監聽器等信息，JobDetail承擔了這一角色。

通過該類的構造函數可以更具體地了解它的功用：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應用很好的實例。

?

Quartz任務調度快速入門(1)