這周被Quartz折騰了一番。
我們知道，Quartz采用JobDataMap實(shí)現(xiàn)向Job實(shí)例傳送配置屬性，正如Quartz官方文檔說(shuō)的那樣：
How can I provide properties/configuration for a Job instance? The key is the JobDataMap, which is part of the JobDetail object.
The JobDataMap can be used to hold any number of (serializable) objects
which you wish to have made available to the job instance when it
executes.
JobDataMap map ＝ context.getJobDetail().getJobDataMap();
我們通過(guò)map向Job實(shí)例傳送多個(gè)objects，其中有一個(gè)是個(gè)bean，一個(gè)是基本類型。對(duì)于scheduled triggers，我們要求bean對(duì)于所有的序列都不變，包括其屬性，而基本類型可以在Job運(yùn)行過(guò)程中改變，并影響下一個(gè)序列。實(shí)際情況是，對(duì)于下個(gè)序列，bean的屬性被上次的修改了，而基本類型卻維持第一次put到Map里面的值。正好和我們要求的相反。
受bean的影響，以為map里面包含的都是更新的對(duì)象，即每個(gè)序列里面的JobDetail是同一個(gè)對(duì)象，但是基本類型的結(jié)果否認(rèn)了這一點(diǎn)。回頭重新翻閱了下Quartz的文檔：
Now, some additional notes about a job's state data (aka JobDataMap): A
Job instance can be defined as "stateful" or "non-stateful".
Non-stateful jobs only have their JobDataMap stored at the time they
are added to the scheduler. This means that any changes made to the
contents of the job data map during execution of the job will be lost,
and will not seen by the job the next time it executes.
Job有兩個(gè)子接口：StatefulJob and InterruptableJob，我們繼承的是InterruptableJob，或許Quartz應(yīng)該有個(gè)InterruptableStatefulJob。另外StatefulJob不支持并發(fā)執(zhí)行，和我們的需求不匹配，我們有自己的同步控制，Job必須可以并發(fā)運(yùn)行。
然后查看了Quartz的相關(guān)源碼：
// RAMJobStore.storeJob
public void storeJob(SchedulingContext ctxt, JobDetail newJob,
boolean replaceExisting) throws ObjectAlreadyExistsException {
JobWrapper jw = new JobWrapper((JobDetail)newJob.clone()); // clone a new one
.
jobsByFQN.put(jw.key, jw);
}
也就是說(shuō)，store里面放的是初始JobDetail的克隆，在序列運(yùn)行完時(shí)，只有StatefulJob才會(huì)更新store里面的JobDetail：
// RAMJobStore.triggeredJobComplete
public void triggeredJobComplete(SchedulingContext ctxt, Trigger trigger,
JobDetail jobDetail, int triggerInstCode) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(jobKey);
if (jw != null) {
JobDetail jd = jw.jobDetail;
if (jd.isStateful()) {
JobDataMap newData = jobDetail.getJobDataMap();
if (newData != null) {
newData = (JobDataMap)newData.clone();
newData.clearDirtyFlag();
}
jd.setJobDataMap(newData); // set to new one
}
}
然后，每次序列運(yùn)行時(shí)所用的JobDetail，是存放在Store里面的克隆。
// RAMJobStore.retrieveJob
public JobDetail retrieveJob(SchedulingContext ctxt, String jobName,
String groupName) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(JobWrapper.getJobNameKey(
jobName, groupName));
return (jw != null) ? (JobDetail)jw.jobDetail.clone() : null; // clone a new
}
問(wèn)題很清楚了，存放在Store里面的JobDetail是初始對(duì)象的克隆，然后每個(gè)序列所用的JobDetail， 是Store里面的克隆，只有Stateful job，Store里面的JobDetail才更新。
最有Quartz里面使用的clone():
// Shallow copy the jobDataMap. Note that this means that if a user
// modifies a value object in this map from the cloned Trigger
// they will also be modifying this Trigger.
if (jobDataMap != null) {
copy.jobDataMap = (JobDataMap)jobDataMap.clone();
}
所以對(duì)于前面所講的，修改bean的屬性，會(huì)影響所有clone的對(duì)象，因此，我們可以將基本類型封裝到一個(gè)bean里面，map里面存放的是bean，然后通過(guò)修改bean的屬性，來(lái)達(dá)到影響下一個(gè)序列的目的。