連接地址:http://www.cnblogs.com/drift-ice/p/3817269.htmlhtml
之前憑藉年輕,凡事都靠腦記。如今工做幾年後發現,不少之前看過、用過的東西,再次拿起的時候總以爲記不牢靠。"好記性不如爛筆頭"應該是某位上了年紀的大叔的切膚之痛(僅次於上了年紀的難言之癮)。java
我以爲這事得怪怪中國的應試教育,中國的考試方式就是要求把腦殼當數據庫,之前中學那點知識,確實還能裝得下。但如今所需的知識量再一次性裝入大腦,就是內存溢出的節奏。另,再相信什麼人腦只開發5%的蠢話了(「人腦只用了不到 5%」 的說法是否確有科學依據?)。更可行的方式,應該學學數據庫,大腦只記憶知識的索引,而把知識的自己定義在外部的存儲中(好比筆記)。基於這個理念,如今準備學着寫點總結性的筆記。算法
那爲何不能基於google學習呢?由於google的索引不是你本身,不能精確找到你想要的東西。但它的好處是更海量,能給你本來壓根不知道東西。因此,配合使用,療效更好。數據庫
Quartz是一個任務調度框架。好比你遇到這樣的問題api
這些問題總結起來就是:在某一個有規律的時間點幹某件事。而且時間的觸發的條件能夠很是複雜(好比每個月最後一個工做日的17:50),複雜到須要一個專門的框架來幹這個事。 Quartz就是來幹這樣的事,你給它一個觸發條件的定義,它負責到了時間點,觸發相應的Job起來幹活。併發
這裏面的全部例子都是基於Quartz 2.2.1框架
package com.test.quartz; import static org.quartz.DateBuilder.newDate; import static org.quartz.JobBuilder.newJob; import static org.quartz.SimpleScheduleBuilder.simpleSchedule; import static org.quartz.TriggerBuilder.newTrigger; import java.util.GregorianCalendar; import org.quartz.JobDetail; import org.quartz.Scheduler; import org.quartz.Trigger; import org.quartz.impl.StdSchedulerFactory; import org.quartz.impl.calendar.AnnualCalendar; public class QuartzTest { public static void main(String[] args) { try { //建立scheduler Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler(); //定義一個Trigger Trigger trigger = newTrigger().withIdentity("trigger1", "group1") //定義name/group .startNow()//一旦加入scheduler,當即生效 .withSchedule(simpleSchedule() //使用SimpleTrigger .withIntervalInSeconds(1) //每隔一秒執行一次 .repeatForever()) //一直執行,奔騰到老不停歇 .build(); //定義一個JobDetail JobDetail job = newJob(HelloQuartz.class) //定義Job類爲HelloQuartz類,這是真正的執行邏輯所在 .withIdentity("job1", "group1") //定義name/group .usingJobData("name", "quartz") //定義屬性 .build(); //加入這個調度 scheduler.scheduleJob(job, trigger); //啓動之 scheduler.start(); //運行一段時間後關閉 Thread.sleep(10000); scheduler.shutdown(true); } catch (Exception e) { e.printStackTrace(); } } }
package com.test.quartz; import java.util.Date; import org.quartz.DisallowConcurrentExecution; import org.quartz.Job; import org.quartz.JobDetail; import org.quartz.JobExecutionContext; import org.quartz.JobExecutionException; public class HelloQuartz implements Job { public void execute(JobExecutionContext context) throws JobExecutionException { JobDetail detail = context.getJobDetail(); String name = detail.getJobDataMap().getString("name"); System.out.println("say hello to " + name + " at " + new Date()); } }
這個例子很好的覆蓋了Quartz最重要的3個基本要素:less
Quartz的API的風格在2.x之後,採用的是DSL風格(一般意味着fluent interface風格),就是示例中newTrigger()那一段東西。它是經過Builder實現的,就是如下幾個。(** 下面大部分代碼都要引用這些Builder ** )學習
//job相關的builder
import static org.quartz.JobBuilder.*; //trigger相關的builder import static org.quartz.TriggerBuilder.*; import static org.quartz.SimpleScheduleBuilder.*; import static org.quartz.CronScheduleBuilder.*; import static org.quartz.DailyTimeIntervalScheduleBuilder.*; import static org.quartz.CalendarIntervalScheduleBuilder.*; //日期相關的builder import static org.quartz.DateBuilder.*;
DSL風格寫起來會更加連貫,暢快,並且因爲不是使用setter的風格,語義上會更容易理解一些。對比一下:ui
JobDetail jobDetail=new JobDetailImpl("jobDetail1","group1",HelloQuartz.class); jobDetail.getJobDataMap().put("name", "quartz"); SimpleTriggerImpl trigger=new SimpleTriggerImpl("trigger1","group1"); trigger.setStartTime(new Date()); trigger.setRepeatInterval(1); trigger.setRepeatCount(-1);
JobDetail和Trigger都有name和group。
name是它們在這個sheduler裏面的惟一標識。若是咱們要更新一個JobDetail定義,只須要設置一個name相同的JobDetail實例便可。
group是一個組織單元,sheduler會提供一些對整組操做的API,好比 scheduler.resumeJobs()。
在開始詳解每一種Trigger以前,須要先了解一下Trigger的一些共性。
startTime和endTime指定的Trigger會被觸發的時間區間。在這個區間以外,Trigger是不會被觸發的。
** 全部Trigger都會包含這兩個屬性 **
當scheduler比較繁忙的時候,可能在同一個時刻,有多個Trigger被觸發了,但資源不足(好比線程池不足)。那麼這個時候比剪刀石頭布更好的方式,就是設置優先級。優先級高的先執行。
須要注意的是,優先級只有在同一時刻執行的Trigger之間纔會起做用,若是一個Trigger是9:00,另外一個Trigger是9:30。那麼不管後一個優先級多高,前一個都是先執行。
優先級的值默認是5,當爲負數時使用默認值。最大值彷佛沒有指定,但建議遵循Java的標準,使用1-10,否則鬼才知道看到【優先級爲10】是時,上頭還有沒有更大的值。
相似的Scheduler資源不足的時候,或者機器崩潰重啓等,有可能某一些Trigger在應該觸發的時間點沒有被觸發,也就是Miss Fire了。這個時候Trigger須要一個策略來處理這種狀況。每種Trigger可選的策略各不相同。
這裏有兩個點須要重點注意:
全部MisFire的策略實際上都是解答兩個問題:
好比SimpleTrigger的MisFire策略有:
MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY
這個不是忽略已經錯失的觸發的意思,而是說忽略MisFire策略。它會在資源合適的時候,從新觸發全部的MisFire任務,而且不會影響現有的調度時間。
好比,SimpleTrigger每15秒執行一次,而中間有5分鐘時間它都MisFire了,一共錯失了20個,5分鐘後,假設資源充足了,而且任務容許併發,它會被一次性觸發。
這個屬性是全部Trigger都適用。
MISFIRE_INSTRUCTION_FIRE_NOW
忽略已經MisFire的任務,而且當即執行調度。這一般只適用於只執行一次的任務。
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT
將startTime設置當前時間,當即從新調度任務,包括的MisFire的
MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT
相似MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_EXISTING_REPEAT_COUNT,區別在於會忽略已經MisFire的任務
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT
在下一次調度時間點,從新開始調度任務,包括的MisFire的
MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT
相似於MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT,區別在於會忽略已經MisFire的任務。
MISFIRE_INSTRUCTION_SMART_POLICY
全部的Trigger的MisFire默認值都是這個,大體意思是「把處理邏輯交給聰明的Quartz去決定」。基本策略是,
MisFire的東西挺繁雜的,能夠參考這篇
這裏的Calendar不是jdk的java.util.Calendar,不是爲了計算日期的。它的做用是在於補充Trigger的時間。能夠排除或加入某一些特定的時間點。
以」每個月25日零點自動還卡債「爲例,咱們想排除掉每一年的2月25號零點這個時間點(由於有2.14,因此2月必定會破產)。這個時間,就能夠用Calendar來實現。
例子:
AnnualCalendar cal = new AnnualCalendar(); //定義一個每一年執行Calendar,精度爲天,即不能定義到2.25號下午2:00 java.util.Calendar excludeDay = new GregorianCalendar(); excludeDay.setTime(newDate().inMonthOnDay(2, 25).build()); cal.setDayExcluded(excludeDay, true); //設置排除2.25這個日期 scheduler.addCalendar("FebCal", cal, false, false); //scheduler加入這個Calendar //定義一個Trigger Trigger trigger = newTrigger().withIdentity("trigger1", "group1") .startNow()//一旦加入scheduler,當即生效 .modifiedByCalendar("FebCal") //使用Calendar !! .withSchedule(simpleSchedule() .withIntervalInSeconds(1) .repeatForever()) .build();
Quartz體貼地爲咱們提供如下幾種Calendar,注意,全部的Calendar既能夠是排除,也能夠是包含,取決於:
Quartz有如下幾種Trigger實現:
指定從某一個時間開始,以必定的時間間隔(單位是毫秒)執行的任務。
它適合的任務相似於:9:00 開始,每隔1小時,執行一次。
它的屬性有:
例子:
simpleSchedule() .withIntervalInHours(1) //每小時執行一次 .repeatForever() //次數不限 .build(); simpleSchedule() .withIntervalInMinutes(1) //每分鐘執行一次 .withRepeatCount(10) //次數爲10次 .build();
相似於SimpleTrigger,指定從某一個時間開始,以必定的時間間隔執行的任務。 可是不一樣的是SimpleTrigger指定的時間間隔爲毫秒,沒辦法指定每隔一個月執行一次(每個月的時間間隔不是固定值),而CalendarIntervalTrigger支持的間隔單位有秒,分鐘,小時,天,月,年,星期。
相較於SimpleTrigger有兩個優點:一、更方便,好比每隔1小時執行,你不用本身去計算1小時等於多少毫秒。 二、支持不是固定長度的間隔,好比間隔爲月和年。但劣勢是精度只能到秒。
它適合的任務相似於:9:00 開始執行,而且之後每週 9:00 執行一次
它的屬性有:
例子:
calendarIntervalSchedule() .withIntervalInDays(1) //天天執行一次 .build(); calendarIntervalSchedule() .withIntervalInWeeks(1) //每週執行一次 .build();
指定天天的某個時間段內,以必定的時間間隔執行任務。而且它能夠支持指定星期。
它適合的任務相似於:指定天天9:00 至 18:00 ,每隔70秒執行一次,而且只要週一至週五執行。
它的屬性有:
例子:
dailyTimeIntervalSchedule() .startingDailyAt(TimeOfDay.hourAndMinuteOfDay(9, 0)) //第天9:00開始 .endingDailyAt(TimeOfDay.hourAndMinuteOfDay(16, 0)) //16:00 結束 .onDaysOfTheWeek(MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY) //週一至週五執行 .withIntervalInHours(1) //每間隔1小時執行一次 .withRepeatCount(100) //最多重複100次(實際執行100+1次) .build(); dailyTimeIntervalSchedule() .startingDailyAt(TimeOfDay.hourAndMinuteOfDay(9, 0)) //第天9:00開始 .endingDailyAfterCount(10) //天天執行10次,這個方法實際上根據 startTimeOfDay+interval*count 算出 endTimeOfDay .onDaysOfTheWeek(MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY) //週一至週五執行 .withIntervalInHours(1) //每間隔1小時執行一次 .build();
適合於更復雜的任務,它支持類型於Linux Cron的語法(而且更強大)。基本上它覆蓋了以上三個Trigger的絕大部分能力(但不是所有)—— 固然,也更難理解。
它適合的任務相似於:天天0:00,9:00,18:00各執行一次。
它的屬性只有:
例子:
cronSchedule("0 0/2 8-17 * * ?") // 天天8:00-17:00,每隔2分鐘執行一次 .build(); cronSchedule("0 30 9 ? * MON") // 每週一,9:30執行一次 .build(); weeklyOnDayAndHourAndMinute(MONDAY,9, 30) //等同於 0 30 9 ? * MON .build();
位置 | 時間域 | 容許值 | 特殊值 |
---|---|---|---|
1 | 秒 | 0-59 | , - * / |
2 | 分鐘 | 0-59 | , - * / |
3 | 小時 | 0-23 | , - * / |
4 | 日期 | 1-31 | , - * ? / L W C |
5 | 月份 | 1-12 | , - * / |
6 | 星期 | 1-7 | , - * ? / L C # |
7 | 年份(可選) | 1-31 | , - * / |
星號():可用在全部字段中,表示對應時間域的每個時刻,例如, 在分鐘字段時,表示「每分鐘」;
問號(?):該字符只在日期和星期字段中使用,它一般指定爲「無心義的值」,至關於點位符;
減號(-):表達一個範圍,如在小時字段中使用「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表達式對特殊字符的大小寫不敏感,對錶明星期的縮寫英文大小寫也不敏感。
一些例子:
表示式 | 說明 |
---|---|
0 0 12 * * ? | 天天12點運行 |
0 15 10 ? * * | 天天10:15運行 |
0 15 10 * * ? | 天天10:15運行 |
0 15 10 * * ? * | 天天10:15運行 |
0 15 10 * * ? 2008 | 在2008年的天天10:15運行 |
0 * 14 * * ? | 天天14點到15點之間每分鐘運行一次,開始於14:00,結束於14:59。 |
0 0/5 14 * * ? | 天天14點到15點每5分鐘運行一次,開始於14:00,結束於14:55。 |
0 0/5 14,18 * * ? | 天天14點到15點每5分鐘運行一次,此外天天18點到19點每5鍾也運行一次。 |
0 0-5 14 * * ? | 天天14:00點到14:05,每分鐘運行一次。 |
0 10,44 14 ? 3 WED | 3月每週三的14:10分到14:44,每分鐘運行一次。 |
0 15 10 ? * MON-FRI | 每週一,二,三,四,五的10:15分運行。 |
0 15 10 15 * ? | 每個月15日10:15分運行。 |
0 15 10 L * ? | 每個月最後一天10:15分運行。 |
0 15 10 ? * 6L | 每個月最後一個星期五10:15分運行。 |
0 15 10 ? * 6L 2007-2009 | 在2007,2008,2009年每月的最後一個星期五的10:15分運行。 |
0 15 10 ? * 6#3 | 每個月第三個星期五的10:15分運行。 |
JobDetail是任務的定義,而Job是任務的執行邏輯。在JobDetail裏會引用一個Job Class定義。一個最簡單的例子
public class JobTest { public static void main(String[] args) throws SchedulerException, IOException { JobDetail job=newJob() .ofType(DoNothingJob.class) //引用Job Class .withIdentity("job1", "group1") //設置name/group .withDescription("this is a test job") //設置描述 .usingJobData("age", 18) //加入屬性到ageJobDataMap .build(); job.getJobDataMap().put("name", "quertz"); //加入屬性name到JobDataMap //定義一個每秒執行一次的SimpleTrigger Trigger trigger=newTrigger() .startNow() .withIdentity("trigger1") .withSchedule(simpleSchedule() .withIntervalInSeconds(1) .repeatForever()) .build(); Scheduler sche=StdSchedulerFactory.getDefaultScheduler(); sche.scheduleJob(job, trigger); sche.start(); System.in.read(); sche.shutdown(); } } public class DoNothingJob implements Job { public void execute(JobExecutionContext context) throws JobExecutionException { System.out.println("do nothing"); } }
從上例咱們能夠看出,要定義一個任務,須要幹幾件事:
Quartz調度一次任務,會幹以下的事:
也就是說,每次調度都會建立一個新的Job實例,這樣的好處是有些任務併發執行的時候,不存在對臨界資源的訪問問題——固然,若是須要共享JobDataMap的時候,仍是存在臨界資源的併發訪問的問題。
Job都次都是newInstance的實例,那我怎麼傳值給它? 好比我如今有兩個發送郵件的任務,一個是發給"liLei",一個發給"hanmeimei",不能說我要寫兩個Job實現類LiLeiSendEmailJob和HanMeiMeiSendEmailJob。實現的辦法是經過JobDataMap。
每個JobDetail都會有一個JobDataMap。JobDataMap本質就是一個Map的擴展類,只是提供了一些更便捷的方法,好比getString()之類的。
咱們能夠在定義JobDetail,加入屬性值,方式有二:
newJob().usingJobData("age", 18) //加入屬性到ageJobDataMap or job.getJobDataMap().put("name", "quertz"); //加入屬性name到JobDataMap
而後在Job中能夠獲取這個JobDataMap的值,方式一樣有二:
public class HelloQuartz implements Job { private String name; public void execute(JobExecutionContext context) throws JobExecutionException { JobDetail detail = context.getJobDetail(); JobDataMap map = detail.getJobDataMap(); //方法一:得到JobDataMap System.out.println("say hello to " + name + "[" + map.getInt("age") + "]" + " at " + new Date()); } //方法二:屬性的setter方法,會將JobDataMap的屬性自動注入 public void setName(String name) { this.name = name; } }
對於同一個JobDetail實例,執行的多個Job實例,是共享一樣的JobDataMap,也就是說,若是你在任務裏修改了裏面的值,會對其餘Job實例(併發的或者後續的)形成影響。
除了JobDetail,Trigger一樣有一個JobDataMap,共享範圍是全部使用這個Trigger的Job實例。
Job是有可能併發執行的,好比一個任務要執行10秒中,而調度算法是每秒中觸發1次,那麼就有可能多個任務被併發執行。
有時候咱們並不想任務併發執行,好比這個任務要去」得到數據庫中全部未發送郵件的名單「,若是是併發執行,就須要一個數據庫鎖去避免一個數據被屢次處理。這個時候一個@DisallowConcurrentExecution解決這個問題。
就是這樣
public class DoNothingJob implements Job { @DisallowConcurrentExecution public void execute(JobExecutionContext context) throws JobExecutionException { System.out.println("do nothing"); } }
注意,@DisallowConcurrentExecution是對JobDetail實例生效,也就是若是你定義兩個JobDetail,引用同一個Job類,是能夠併發執行的。
Job.execute()方法是不容許拋出除JobExecutionException以外的全部異常的(包括RuntimeException),因此編碼的時候,最好是try-catch住全部的Throwable,當心處理。
Durability(耐久性?)
若是一個任務不是durable,那麼當沒有Trigger關聯它的時候,它就會被自動刪除。
RequestsRecovery
若是一個任務是"requests recovery",那麼當任務運行過程非正常退出時(好比進程崩潰,機器斷電,但不包括拋出異常這種狀況),Quartz再次啓動時,會從新運行一次這個任務實例。
能夠經過JobExecutionContext.isRecovering()查詢任務是不是被恢復的。
Scheduler就是Quartz的大腦,全部任務都是由它來設施。
Schduelr包含一個兩個重要組件: JobStore和ThreadPool。
JobStore是會來存儲運行時信息的,包括Trigger,Schduler,JobDetail,業務鎖等。它有多種實現RAMJob(內存實現),JobStoreTX(JDBC,事務由Quartz管理),JobStoreCMT(JDBC,使用容器事務),ClusteredJobStore(集羣實現)、TerracottaJobStore(什麼是Terractta)。
ThreadPool就是線程池,Quartz有本身的線程池實現。全部任務的都會由線程池執行。
SchdulerFactory,顧名思義就是來用建立Schduler了,有兩個實現:DirectSchedulerFactory和 StdSchdulerFactory。前者能夠用來在代碼裏定製你本身的Schduler參數。後者是直接讀取classpath下的quartz.properties(不存在就都使用默認值)配置來實例化Schduler。一般來說,咱們使用StdSchdulerFactory也就足夠了。
SchdulerFactory自己是支持建立RMI stub的,能夠用來管理遠程的Scheduler,功能與本地同樣,能夠遠程提交個Job什麼的。
DirectSchedulerFactory的建立接口
/**
* Same as * {@link DirectSchedulerFactory#createScheduler(ThreadPool threadPool, JobStore jobStore)}, * with the addition of specifying the scheduler name and instance ID. This * scheduler can only be retrieved via * {@link DirectSchedulerFactory#getScheduler(String)} * * @param schedulerName * The name for the scheduler. * @param schedulerInstanceId * The instance ID for the scheduler. * @param threadPool * The thread pool for executing jobs * @param jobStore * The type of job store * @throws SchedulerException * if initialization failed */ public void createScheduler(String schedulerName, String schedulerInstanceId, ThreadPool threadPool, JobStore jobStore) throws SchedulerException;
StdSchdulerFactory的配置例子, 更多配置,參考Quartz配置指南:
org.quartz.scheduler.instanceName = DefaultQuartzScheduler 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