【quartz】 理論知識

屬性的介紹

1.調度器屬性：分別設置調度器的實例名(instanceName) 和實例 ID (instanceId)。屬性 org.quartz.scheduler.instanceName 能夠是你喜歡的任何字符串。默認名字通常都採用QuartzScheduler，第二個屬性org.quartz.scheduler.instanceId和instaneName 屬性同樣，instanceId 屬性也容許任何字符串。這個值必須是在全部調度器實例中是惟一的，尤爲是在一個集羣當中。假如你想 Quartz 幫你生成這個值的話，能夠設置爲 AUTO。

二、線程池屬性：這些線程在 Quartz 中是運行在後臺擔當重任的。threadCount 屬性控制了多少個工做者線程被建立用來處理 Job。原則上是，要處理的 Job 越多，那麼須要的工做者線程也就越多。threadCount 的數值至少爲 1。Quartz 沒有限定你設置工做者線程的最大值，可是在多數機器上設置該值超過100的話就會顯得至關不實用了，特別是在你的 Job 執行時間較長的狀況下。這項沒有默認值，因此你必須爲這個屬性設定一個值。

threadPriority 屬性設置工做者線程的優先級。優先級別高的線程比級別低的線程更優先獲得執行。threadPriority 屬性的最大值是常量 java.lang.Thread.MAX_PRIORITY，等於10。最小值爲常量 java.lang.Thread.MIN_PRIORITY，爲1。這個屬性的正常值是 Thread.NORM_PRIORITY，爲5。大多狀況下，把它設置爲5，這也是沒指定該屬性的默認值。

最後一個要設置的線程池屬性是 org.quartz.threadPool.class。這個值是一個實現了 org.quartz.spi.ThreadPool 接口的類的全限名稱。Quartz 自帶的線程池實現類是 org.quartz.smpl.SimpleThreadPool，它可以知足大多數用戶的需求。這個線程池實現具有簡單的行爲，並經很好的測試過。它在調度器的生命週期中提供固定大小的線程池。你能根據需求建立本身的線程池實現，若是你想要一個隨需可伸縮的線程池時也許須要這麼作。這個屬性沒有默認值，你必須爲其指定值。

三、做業存儲屬性：做業存儲部分的設置描述了在調度器實例的生命週期中，Job 和 Trigger 信息是如何被存儲的。把調度器信息存儲在內存中很是的快也易於配置。當調度器進程一旦被終止，全部的 Job 和 Trigger 的狀態就丟失了。要使 Job 存儲在內存中需經過設置 org.quartz.jobStrore.class 屬性爲 org.quartz.simpl.RAMJobStore，在Cron Trigger 和「做業存儲和持久化」會用到的不一樣類型的做業存儲實現。

四、其餘插件屬性：org.quartz.plugin.jobInitializer.class = org.quartz.plugins.xml.JobInitializationPlugin默認時，JobInitializationPlugin插件會在 classpath 中搜索名爲 quartz_jobs.xml 的文件並從中加載 Job 和 Trigger 信息。其餘插件後敘……

 

org.quartz.Job 接口

 

把 Quartz 做用到 Java 類上惟一要作的就是讓它實現 org.quartz.Job 接口。你的 Job 類能夠實現任何其餘想要的接口或繼承任何須要的基類，可是它本身或是它的超類必須實現這個 Job 接口。這個 Job 接口只定義了單個方法：
public void execute(JobExecutionContext context) throws JobExecutionException;

當 Scheduler 決定了是時候運行 Job 時，方法 execute() 就會被調用，並傳遞一個 JobExecutionContext 對象給這個 Job。Quartz 加給方法 execute() 要承擔的惟一合約責任就是若是在 Job 中出現嚴重問題時，必須拋出一個 org.quartz.JobExecutionException 異常

 

 

JobExecutionContext

當 Scheduler 調用一個 Job，一個 JobexecutionContext 傳遞給 execute() 方法。JobExecutionContext 對象讓 Job 能訪問 Quartz 運行時候環境和 Job 自己的明細數據。這就相似於在 Java Web 應用中的 servlet 訪問 ServletContext 那樣。經過 JobExecutionContext，Job 可訪問到所處環境的全部信息，包括註冊到 Scheduler 上與該 Job 相關聯的 JobDetail 和 Triiger。Quartz Job 的一個很是基礎的代碼。PrintInfoJob 得到存儲在 JobExecutionContext 中的 JobDetail 對象.

public class PrintInfoJob implements Job {
public void execute(JobExecutionContext context) throws JobExecutionException {
JobDetail jobDetail = context.getJobDetail();
}}

 

 

JobDetail

 

從之前的例子能夠看的出JobDetail 被加到 Scheduler 中了，而不是 job。Job 類是做爲 JobDetail 的一部份，可是它直到 Scheduler 準備要執行它的時候纔會被實例化的。

Job 的實例要到該執行它們的時候纔會實例化出來。每次 Job 被執行，一個新的 Job 實例會被建立。其中暗含的意思就是你的 Job 沒必要擔憂線程安全性，由於同一時刻僅有一個線程去執行給定 Job 類的實例，甚至是併發執行同一 Job 也是如此。

 

使用 JobDataMap 對象設定 Job 狀態

 

你能使用 org.quartz.JobDataMap 來定義 Job 的狀態。JobDataMap 經過它的超類 org.quartz.util.DirtyFlagMap 實現了 java.util.Map 接口，你能夠向 JobDataMap 中存入鍵/值對，那些數據對可在你的 Job 類中傳遞和進行訪問。這是一個向你的 Job 傳送配置的信息便捷方法。經過 JobExecutionContext 對象訪問 JobDataMap， JobDataMap jobDataMap =context.getJobDetail().getJobDataMap();當你得到了 JobDataMap，你能夠當它是任何 map 實例同樣調用它的方法。通常的，你會本身選擇一個預約義的鍵值來訪問 JobDataMap 中的數據。在 Quartz 1.5 中，JobDataMap 在 Trigger 級也是可用的。它的用途相似於 Job 級的 JobDataMap，此外它還能支持應用在同一個 JobDetail 上的多個 Trigger 上。伴隨着加入到 Quartz 1.5 中的這一加強特性，可使用 JobExecutionContext 的一個新的更方便的方法獲取到 Job 和 Trigger 級的並集的 map 中的值。這個方法就是 getMergedJobDataMap()，它可以在 Job 中使用。從 Quartz 1.5 以後，使用這個方法被認爲是獲取 JobDataMap 最佳實踐。

 

無狀態的 Job

 

信息可插入到 JobDataMap 中而後被 Job 訪問到。然而，對於每一次的 Job 執行，都會爲特定的 Job 取用存儲在某處(例如，數據庫中)的值建立一個新的 JobDataMap 實例。所以，沒法爲兩次 Job 調用之間持有那些信息，除非你使用有狀態的 Job.

 

使用有狀態的 Job

當你須要在兩次 Job 執行間維護狀態的話，Quartz 框架爲此提供了 org.quartz.StatefulJob 接口。StatefulJob 接口僅僅是擴展了 Job 接口，未加入新的方法。你只須要經過使用與 Job 接口相同的 execute() 方法簡單的實現 StatefulJob 接口便可。假如你有已存在的 Job 類，你全部要作的只是改變 Job 的接口爲 org.quartz.StatefulJob。

Job 和 StatefulJob 在框架中使用中存在兩個關鍵差別。首先，JobDataMap 在每次執行以後從新持久化到 JobStore 中。這樣就確保你對 Job 數據的改變直到下次執行仍然保持着。你能夠在有狀態 Job 中簡單的經過 map 的 put() 方法來修改 JobDataMap.已存在的任何數據會被新的數據覆蓋掉。你也能對無狀態的 Job 這麼作，可是由於對於無狀態 Job 來講，JobDataMap 不會持久化，因此數據不會保存下來。對於 Trigger 和 JobExecutionContext 上的 JobDataMap 的數據修改也是沒能保存下來的。

另外一個無狀態和有狀態

 

Job 重大區別就是：兩個或多個有狀態的 JobDetail 實例不能併發執行。說的是你建立並註冊了一個有狀態 JobDetail 到 Scheduler 上。你還創建了兩個 Trigger 來觸發這個 Job：一個每五分鐘觸發，另外一個也是每五分釧觸發。假如這兩個 Trigger 試圖在同一時刻觸發 Job，框架是不容許這種事情發生的。第二個 Trigger 一直會被阻塞直到第一個結束。

 

 

在你使用 StatefulJob 時可要謹慎了