就像我们在上面一节介绍的,Job非常容易实现,只要实现一个execute方法就可以了。对于Job相关的内容,你只需要了解下execute方法、Job接口和JobDetail类就够了。
当一个Job在执行你希望它执行的任务的时候,Quartz需要将一些参数传递给Job。这个事情是由JobDetail完成的,这个在上面一节中已经提到了。
通过JobBuilder可以得到JobDetail。导入下面的代码,你可以使用静态导入功能,很方便地创建JobDetail
import static org.quartz.JobBuilder.*;
下面我们花一点时间来讨论下Job的本质以及一个Job的生命周期。首先我们看下下面的代码
// define the job and tie it to our HelloJob class
JobDetail job = newJob(HelloJob.class)
.withIdentity("myJob", "group1") // name "myJob", group "group1"
.build();
// Trigger the job to run now, and then every 40 seconds
Trigger trigger = newTrigger()
.withIdentity("myTrigger", "group1")
.startNow()
.withSchedule(simpleSchedule()
.withIntervalInSeconds(40)
.repeatForever())
.build();
// Tell quartz to schedule the job using our trigger
sched.scheduleJob(job, trigger);
现在假设我们已经定义了下面的Job类--“HelloWord”
public class HelloJob implements Job {
public HelloJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException
{
System.err.println("Hello! HelloJob is executing.");
}
}
上面的列子中,我们在scheduler上注册了一个JobDetail实例。 每次scheduler执行Job任务的时候,都会新建一个Job实例(实现Job接口的类)然后再去执行execute方法。当这个方法执行完成以后,对这个类的引用会被撤销,然后这个类会被垃圾回收。这种行为带来的后果就是Job类(实现Job接口的类)必须有一个无参数的构造函数。另外一个影响就是在Job类中定义成员属性没有什么意义。因为这属性不会在两次Job执行间传递。
你现在可能会问,我怎么给一个Job实例提供属性或者配置,怎么能记录Job的 执行状态。用JobDataMap可以解决这个问题。JobDataMap是JobDetail的一部分。
JobDataMap
在JobDataMap中可以保存任意数量的可序列化对象。JobDataMap是Map接口的实现类,并且添加了一些方法方便存取数据。
下面是一个使用JobDataMap的简单列子
JobDetail job = newJob(DumbJob.class)
.withIdentity("myJob", "group1") // name "myJob", group "group1"
.usingJobData("jobSays", "Hello World!")
.usingJobData("myFloatValue", 3.141f)
.build();
下面的代码给出了再Job执行的时候怎么从JobDataMap中拿数据
public class DumbJob implements Job {
public DumbJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException
{
JobKey key = context.getJobDetail().getKey();
JobDataMap dataMap = context.getJobDetail().getJobDataMap();
String jobSays = dataMap.getString("jobSays");
float myFloatValue = dataMap.getFloat("myFloatValue");
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);
}
}
如果你使用了持久化的方式来存储Job,那你在将数据放入DataMap的时候需要更加小心,因为存放在map中的数据会被序列化,因此可能会出现版本不一致问题。但是Java提供的一些原始数据类型是非常安全的。因此建立只将原始数据类型和String类型存放在dataMap中以避免不必要的序列化问题。
如果你在Job类(实现Job接口的类)中定义了存入datamap属性的相应的setter方法,那么在初始化Job实例的时候,quartz会自动将调用setter方法。
触发器也能绑定相应的DataMap,当你想要将多个不同的触发器绑定到一个Job,又想让这些触发器传不同的值给Job时,这会非常有用。值得注意的是Trigger中的数据会覆盖掉JobDetail中存放的同名的数据。下面给出一个列子
public class DumbJob implements Job {
public DumbJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException
{
JobKey key = context.getJobDetail().getKey();
JobDataMap dataMap = context.getMergedJobDataMap(); // Note the difference from the previous example
String jobSays = dataMap.getString("jobSays");
float myFloatValue = dataMap.getFloat("myFloatValue");
ArrayList state = (ArrayList)dataMap.get("myStateData");
state.add(new Date());
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);
}
}
下面给出自动注入属性值得列子
public class DumbJob implements Job {
String jobSays;
float myFloatValue;
ArrayList state;
public DumbJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException
{
JobKey key = context.getJobDetail().getKey();
JobDataMap dataMap = context.getMergedJobDataMap(); // Note the difference from the previous example
state.add(new Date());
System.err.println("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue);
}
public void setJobSays(String jobSays) {
this.jobSays = jobSays;
}
public void setMyFloatValue(float myFloatValue) {
myFloatValue = myFloatValue;
}
public void setState(ArrayList state) {
state = state;
}
}
Job实例相关内容
很多用户对Job的构成很困惑,这里我们将介绍这点,在下面的小节中会介绍Job的状态和并发相关的内容。
“Job instance”指代实现Job接口的类 “job definition”指代JobDetail。
Job并发访问相关
对于Job并发相关的内容,有两个注解需要我们注意。
@DisallowConcurrentExecution :禁止Job并发执行
//scheduler.scheduleJob(job1, trigger1);
//scheduler.scheduleJob(job1, trigger2);
@PersistJobDataAfterExecution: 将这一次Job执行的结果保存在JobDetail中,下一次Job执行的时候可以访问。
Job其他相关特性
1)Durability -- 如果一个Job是非持久化,那么这个Job会自动被删除当没有处于激活状态的促发器和他绑定。也就是说非持久化的Job的生命周期和相关的触发器的生命周期一样。
2)RequestsRecovery -- 如果一个Job是RequestsRecovery的,那么当机器被意外关闭 或者scheduler被意外关闭重启之后,Job会自动重新执行(问题:Job执行了一半)