部署 Job

雨点打透心脏的1/2处 2021-09-20 02:50 445阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

## 部署 **Job (**第一部分**)** ##

在上一章中，你首次尝试使用了 Quartz 来部署 Job。无可否认地，那些 Job 都不是很复杂，但这个不是重点。你应该轻松的对如何构造并部署 Job 有了相当的了解，更重要的是，由此热情的希望学得更多的东西。在本章中将会继续给你讲述。第四章将带领你深入到 Quart 框架的核心部分。可证明的是，这一章对于阅读和理解本书是非常之重要的。调度器(Scheduler)是此框架的心脏。本章关注于如何使用 Scheduler 来管理你的 Job；如何创建并关联触发器以使 Job 能被触发执行；以及如可选择 calendar

### 1. Quartz 调度器 ###

Quartz 框架包含许多的类和接口，它们分布在大概 11 个包中。多数你所要使用到的类或接口放置在 org.quartz 包中。这个包含盖了 Quartz 框架的公有 API.我们不打算对这个框架的所有类和接口都面面俱到。而所要介绍的是那些有助于你理解 Quartz 如何做它该做事情的组件的子集。  
图 4.1 展示了一个只留下必要的调度器的精简类图

图 **4.1. Quartz** 类图**(**仅显示主要组件**)**  
![125112\_rRC5\_3101476.png][125112_rRC5_3101476.png]

Scheduler 是 Quartz 的主要 API。对于 Quartz 用户来说，多数时候与框架的交互是发生于 Scheduler 之上的。客服端与Scheduler 交互是通过 org.quartz.Scheduler 接口的。这个 Scheduler 的实现，在这种情况下，是一个代理，对其中方法调用会传递到 QuartzScheduler 实例上。QuartzScheduler 对于客户端是不可见的，并且也不存在与此实例的直接交互

QuartzScheduler 处在框架根的位置，它是一个引擎驱动着整个框架。并非所有的功能都直接内建到 QuartzScheduler，然而，框架为灵活性和可配置性考虑而设计，所以许多重要的功能由分离的组件和子框架实现。这就意味着 Quartz 用户可以用自己某个关键特征实现来替换原有默认实现。即使 QuartzScheduler 代理了它的一些职责，但它仍然掌控着整个作业调度流程。

Quartz Scheduler 类层次  
客户端会同两种类型的 Scheduler 交互，如图 4.2. 它们都实现了 org.quartz.Scheduler 接口。

图 4.2. org.quartz.Scheduler 类层次

![125704\_ZMrn\_3101476.png][125704_ZMrn_3101476.png]

作为一个 Quartz 用户，你要与实现了 org.quartz.Scheduler 接口的类交互。在你调用它的任何 API 之前，你需要知道如何创建一个 Scheduler 的实例。

### 2. Quartz SchedulerFactory ###

尽管你已使用到了 Scheduler 类型了，但你未曾显式的去创建 Scheduler 的实例。取而代之的是用了某个工厂方法来确保了构造出 Sheduler 实例并正确的得到初始化。(工厂设计模式之所以谓之工厂模式是因为它承担了生产对象的职责。在这里是生产了一个 Scheduler 实例) Quartz 框架为这一目的提供了 org.quartz.SchedulerFactory 接口。角色 SchedulerFactory 就是用来产生 Scheduler 实例的。**当 Scheduler 实例被创建之后，就会存到一个仓库中(org.quartz.impl.SchedulerRepository)，**这个仓库还提供了通过一个 class loader 查询实例的机制。要使用 Scheduler 实例，客户端必须从工厂（和随同的仓库中）使用不同方法调用来获取到它们。换句话说，**要通过工厂创建一个 Scheduler 实例并获取到它需要经由两次方法调用。有一些方便的方法封装了那两个方法**，你将很快能看到。

你可使用两种不同类型的 SchedulerFactory 来创建 Scheduler 实例 (看图 4.3)

![130534\_Q8Fn\_3101476.png][130534_Q8Fn_3101476.png]

这两个 Scheduler 工厂分别是 org.quartz.impl.DirectoSchedulerFactory 和 org.quartz.impl.StdSchedulerFactory. 让我们来逐个检视它们。

#### 使用 **DirectSchedulerFactory** ####

DirectSchedulerFactory 是为那些想绝对控制 Scheduler 实例是如何生产出的人所设计的。代码 4.1 显示了最简单的方式去使用 DirectSchedulerFactory 来创建一个 Scheduler 实例

代码 4.1. 使用 DirectSchedulerFactory

public class Listing_4_1 {
        static Logger logger = Logger.getLogger(Listing_4_1.class);
    
        public static void main(String[] args) {
            Listing_4_1 example = new Listing_4_1();
            example.startScheduler();
        }
        public void startScheduler(){
            DirectSchedulerFactory factory = DirectSchedulerFactory.getInstance();
            try{
                factory.createVolatileScheduler(10);
                //factory.createRemoteScheduler();  factory.createScheduler();
                Scheduler scheduler = factory.getScheduler();
                logger.info("Scheduler starting up...");
                scheduler.start();
            }catch (Exception e){
                e.printStackTrace();
            }
        }
    }

当使用 DirectSchedulerFactory 时，**有三个基本的步骤。**首先，你必须用静态方法 getInstance() 获取到工厂的实例。当你持有了工厂的实例之后，你必须调用其中的一个 createXXX 方法去初始化它。如代码 4.1 所示例子中是调用createVolatileScheduler() 方法告诉工厂以十个工作者线程初始化它自己（至于工作者线程的更多内容将在本章的后部分讨论到）。第三步也就是最后一步是通过工厂的 getScheduler() 方法拿到 Scheduler 的实例。

在调用 **getScheduler()** 方法之后调用其中的一个 **createXXX** 方法  
方法 createVolatileScheduler() 方法不会返回 scheduler 的实例。createXXX() 方法是告诉工厂如何配置要创建的 Scheduler 实例。你必须调用方法 getScheduler() 获取到在工厂上执行方法 createXXX() 产生的实例。实际上，在调用 getScheduler() 方法之前，你必须调用其中一个 createXXX() 方法；否则，你将有收到一个 SchedulerException 错误，因为根本没有 Scheduler 实例存在。

你可从数个不同的 createXXX() 方法中选择，依赖于你想要的 Scheduler 类型和你需要怎样的配置。代码 4.1 中用的是createVolatileScheduler() 方法创建 Scheduler 实例的。方法 createVolatileScheduler() 带有单个参数：要创建的线程数量。在图 4.2 中，你已看到还有一个 RemoteScheduler 类。你必须要用一个不同的 createXXX() 方法去创建RemoteScheduler 实例。有两个版本的方法可用

public void createRemoteScheduler(String rmiHost, int rmiPort) throws SchedulerException;
    
    protected void createRemoteScheduler(String schedulerName,String schedulerInstanceId, String rmiHost, int rmiPort)throws SchedulerException;

RemoteScheduler 会在第十章，“J2EE 中使用 Quartz”讨论。假如你就是想要一个标准的 Scheduler, 可以调用以下三个版本 的方法中的一个：

public void createScheduler(ThreadPool threadPool, JobStore jobStore)throws SchedulerException;
    
    public void createScheduler(String schedulerName,String schedulerInstanceId, ThreadPool threadPool, JobStore jobStore)
    throws SchedulerException;
    
    public void createScheduler(String schedulerName,String schedulerInstanceId, ThreadPool threadPool,
     JobStore jobStore, String rmiRegistryHost, int rmiRegistryPort,long idleWaitTime, long dbFailureRetryInterval)
     throws SchedulerException;

在上一章上，我们用了一个属性文件来初始化 Scheduler。要通过 DirectSchedulerFactory 创建一个 Scheduler 实例，你必须传递配置参数给其中的一个 createXXX() 方法。在下一节中，我们讨论 StdSchedulerFactory，一个 SchedulerFactory版本，它依赖于一系列的属性来配置 Scheduler，而不是通过 createXXX() 方法参数来传递配置参数。这样也避免了在代码中对 Scheduler 的配置选项的硬编码。

#### **·**使用 **StdSchedulerFactory** ####

与 DirectSchedulerFactory 形成鲜明对比的是，org.quartz.impl.StdSchedulerFactory 依赖于一系列的属性来决定如何生

产出 Scheduler 实例。你可以通过以下三种途径向工厂提供那些属性：  
·通过 java.util.Properties 实例提供  
·通过外部属性文件提供  
·通过含用属性文件内容的 java.io.InputStream 实例提供

**Java** 属性文件  
我们这里使用述语“属性文件”，对于 Java 传统来说就是：在一个外部文件中指定一系列的 key=value 对，并且每个 key=value 对独占一行。

#### 代码 4.2 演示了第一种途径，通过一个 java.util.Properties 实例来提供属性。 ####

代码 4.2. 使用 java.util.Properties 实例创建 StdSchedulerFactory

public class Listing_4_2 {
        static Logger logger = Logger.getLogger(Listing_4_2.class);
        public static void main(String[] args) {
            Listing_4_2 example = new Listing_4_2();
            example.startScheduler();
        }
        public void startScheduler(){
            StdSchedulerFactory factory = new StdSchedulerFactory();
            /*Properties prop = new Properties();
            prop.put(StdSchedulerFactory.PROP_THREAD_POOL_CLASS,"org.quartz.simpl.SimpleThreadPool");
            prop.put("org.quartz.threadPool.threadCount","5");*/
            try{
                factory.initialize("quertz.properties");
                Scheduler scheduler = factory.getScheduler();
                logger.info("Scheduler starting up...");
                scheduler.start();
    
            }catch (Exception e){
                logger.error(e);
            }
        }
    }

代码 4.2 提供了一个使用 StdSchedulerFactory 创建 Scheduler 实例的很简单的例子。在这个例子中向工厂传递了两个属性，它们分别是实现了 org.quartz.spi.ThreadPool 接口的类名和 Scheduler 用来处理 Job 的线程的数量。这两个属性是必须的，因为它们并没有被指定默认值（我们很快在后面讨论它们）

在代码 4.1 中的 DirectSchedulerFactory，我们调用它其中一个 createXXX() 方法来初始化工厂。而对于

StdSchedulerFactory, 你使用的是一个有效的 initialize() 方法。在工厂初始化之后，你就可以调用它的 getScheduler() 方法获取到 Scheduler 的实例。**使用 java.util.Properties 对象传递属性给工厂是一种配置 SchedulerFactory 的方式之一**。硬编码配置属性的做法基本不推荐，也是可能的时候应尽力避免的做法。假如你需要修改上一例子中的线程数量，你将不得不修改代码然后重新编译。

幸运的是，StdSchedulerFactory 还有其他的方式来提供必须的属性。工厂也能通过传入一个外部文件名而被初始化，在这个外部文件中包含了这些配置项。应使用 initialize() 的替代方法形式如下：

public void initialize(String filename) throws SchedulerException;

要使文件和属性能被成功加载的话，这个文件必须对于 classloader 是可见的。也就是说它必须在你的应用程序的 classpath中。假如你用的是 **java.io.InputStream 去加载文件**，你可以使用另一个 initialize() 的替代方法如下：

public void initialize(InputStream propertiesStream) throws SchedulerException;

在第三章，“Hello, Quartz” 你已看到为 SchedulerFactory 从一个叫做 quartz.properties 的外部文件中加载设置的例子。这个外部属性文件就是要用前面的方法来加载。**假如你没有为 initialize() 方法指定从哪儿读取属性，那么StdSchedulerFactory 会试图从名为 quartz.properties 的文件中加载它们**。这就是你在第三章看到的行为。

#### 使用默认的 **quartz.properties** 文件创建 **Scheduler** ####

假如你使用无参的 initialize() 方法，StdSchedulerFactory 会执行以下几个步骤去尝试为工厂加载属性：  
**1.** 检查 System.getProperty("org.quartz.properties") 中是否设置了别的文件名  
**2.** 否则，使用 quartz.properties 作为要加载的文件名  
**3.** 试图从当前工作目录中加载这个文件  
**4.** 试图从系统 classpath 下加载这个文件

在 Quartz Jar 包中的默认 quartz.properties 文件  
上面第4步总是能成功的，因为在 Quartz Jar 包中有一个默认的 quartz.properties 文件。  
假如你想使用另一个替代文件，你必须自己创建一个并确保它在 classpath 上。

使用 StdSchedulerFactory 来创建 Scheduler 实例的方式很普遍，因此在 StdSchedulerFactory 直接提供了一个方便的静态方法 getDefaultScheduler()，它就是使用前面列出的几个步骤来初始化工厂的。这如代码 4.3 所示

#### 代码 **4.3.** 使用静态的 **getDefaultScheduler()** 方法创建 **Scheduler** ####

public class Listing_4_3 {
        static Logger logger = Logger.getLogger(Listing_4_3.class);
        public static void main(String[] args) {
            Listing_4_3 example = new Listing_4_3();
            example.startScheduler();
        }
        public void startScheduler(){
           try{
               Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
               logger.info("Scheduler starting up...");
               scheduler.start();
           }catch (Exception e){
               logger.error(e);
           }
        }
    }

在静态方法 getDefaultScheduler() 方法中调用了空的构造方法。假如之前未调用过任何一个 initialize() 方法，那么无参的initialize() 方法会被调用。**这会开始去按照前面说的顺序加载文件。默认情况下，quartz.properties 会被定位到，并从中加载属性**。

**Scheduler** 的功能  
本章到此为止大部分笔墨都在着重论述如何获得一个 Scheduler 的实例。那么一旦你拿到 Scheduler 的实例之后，你能能此做些什么呢？好，现在开始，上面的例子中告诉了你可以调用它的 start() 方法。Scheduler 的 API 大概包括了 65 个不同的方法。我们不在此全部枚举出来，但是你需要理解其中的一小部分 API。  
Scheduler 的 API 可以分组成以下三个类别：  
·管理 Scheduler  
·管理 Job  
·管理 Trigger 和 Calendar

## 部署 **Job (**第二部分**)** ##

### 管理 **Scheduler** ###

除了启动 Scheduler, 在应用的生命周期中你也许还要执行 Scheduler 的别的一些操作。这些 Scheduler 操作包括查询、设置Scheduler 为 standby 模式、继续、停止。很多情况下，当一个 Scheduler 启动后，除让它运行之外你不需要对它做任何事情的。在某些情形下，你也可能会要临时的终止 Scheduler 而转入到 standby 模式

#### 启动 Scheduler ####

启动一个 Scheduler 也不总是一目了然的。当你有了 Scheduler 的实例，并得到正确的初始化，你的 Job 和 Triiger 也已注册上去了，你只需要简单的调用 start() 方法：

//Create an instance of the Scheduler
    Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
    //Start the scheduler
    scheduler.start();

一旦 start() 方法被调用，Scheduler 就开始搜寻需要执行的 Job。在你刚得到一个 Scheduler 新的实例时，或者 Scheduler被设置为 **standby**模式后，**你才可以调用 start() 方法**。只要调用了 shutdown() 方法之后，你就不能再调用 Scheduler 实例的 start() 方法了。

别在 **shutdown()** 之后调用 **start()**  
Scheduler 实例被关闭之后你就不能调用它的 start() 方法了。这是因为 shutdown() 方法销毁了为 Scheduler 创建的所有的资源(线程，数据库连接等)。假如你在 shutdown() 之后调用 start()你将收到 SchedulerException 的异常。

#### Standby 模式 ####

设置 **Scheduler 为 standby 模式会导致 Scheduler 暂时停止查找 Job 去执行**。例如，假定你的 Scheduler 是从数据库中获取到的 Job 信息，这时候你需要重启数据库。在数据库恢复之后你也需要重新启动 Scheduler，或者仅仅是设置为 standby 模式就行了。你能通过调用 standby() 方法让 Scheduler 进入到 standby 模式：

public void standby() throws SchedulerException;

在 standby 模式，Scheduler 不再试图去执行 Job，因为那些搜寻要执行的 Job 的线程被暂停了下来。

#### 停止 Scheduler ####

你能使用两个版本的 shutdonw() 方来停止 Scheduler:

public void shutdown(boolean waitForJobsToComplete) throws SchedulerException;
    
    public void shutdown() throws SchedulerException;

上面那两个方法唯一不同之处是其中一个方法可接受一个 boolean 型参数，表示是否让当前正在进行的 Job 正常执行完成才停止 Scheduler。无参的 shutdown() 方法相当于调用 shutdown(false).

#### 管理 Job ####

前面章节我们粗略的看了 Quartz Job，现在来详细正式的讨论 Quartz Job 和怎样使用它们。

什么是 Quartz Job?

很简单，一个 Quart Job 就是一个为你执行一个任务的 Java 类。这个任务是你能用 Java 编码的任何东西。下面就是一些任务的例子：

使用 JavaMail (或别的 Mail 框架、如 Commons Net) 发送 e-mail  
·创建一个远程接口并调用 EJB 上的方法  
·获得 Hibernate 会话，查询、更新关系数据库中的数据  
·使用 OSWorkflow 并在 Job 中调用一个工作流  
上面的例子仅仅是一部份；你一定能列出不少你自己的任务。任何 Java 能做的事情都可以成为一个 Job.

·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。代码 4.4 展示了一个叫做 PrintInfoJob 的 Job 打印出相关的一些信息。

从代码 4.4 中可以看到，Quartz Job 的一个非常基础的代码。PrintInfoJob 获得存储在 JobExecutionContext 中的 JobDetail 对象，进而打印出 Job 相关的基本明细。还JobDetail 类还会被给予更多的一些讨论。

代码 4.4. PrintInfoJob 显示了如何访问 JobExecutionContext

public class PrintInfoJob implements Job{
    
        static org.apache.log4j.Logger logger = org.apache.log4j.Logger.getLogger(PrintInfoJob.class);
        @Override
        public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
            JobDetail jobDetail = jobExecutionContext.getJobDetail();
            JobKey jobKey = jobDetail.getKey();
            String name = jobKey.getName();
            String group = jobKey.getGroup();
            System.out.println(name + " : " + group);
            System.out.println(jobDetail.getJobClass());
            logger.info(name + " fired at " + jobExecutionContext.getFireTime());
    
            logger.info("next fired at " + jobExecutionContext.getNextFireTime());
        }
    }

#### JobDetail ####

你第一次看到 org.quartz.JobDetail 类是在前面的第三章。对于部署在 Scheduler 上的每一个 Job 只创建了一个 JobDetail实例。JobDetail 是作为 Job 实例进行定义的。注意到在代码 4.5 中不是把 Job 对象注册到 Scheduler；实际注册的是一个JobDetail 实例。

代码 **4.5.** 注册到 **Scheduler** 上的是一个 **JobDetail**，而不是 **Job**

public class Listing_4_5 {
        static Logger logger = Logger.getLogger(Listing_4_5.class);
        public static void main(String[] args) {
            Listing_4_5 example = new Listing_4_5();
            example.runScheduler();
        }
        public void runScheduler(){
            try{
                Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();
                logger.info("Scheduler starting up...");
                scheduler.start();
                //create the JobDetail
                JobDetail jobDetail = JobBuilder.newJob(PrintInfoJob.class).withIdentity("PrintInfoJob",Scheduler.DEFAULT_GROUP).build();
                //create a trigger that fires now and repeats forever
                Trigger trigger = TriggerBuilder.newTrigger().withIdentity("trigger",Scheduler.DEFAULT_GROUP).startNow().
                        withSchedule(SimpleScheduleBuilder.simpleSchedule().withIntervalInSeconds(2).repeatForever()).
                        build();
                scheduler.scheduleJob(jobDetail,trigger);
    
            }catch (Exception e){
                logger.error(e);
            }
        }
    }

在代码 4.5 中你可以看到，JobDetail 被加到 Scheduler 中了，而不是 job。Job 类是作为 JobDetail 的一部份，但是它直到Scheduler 准备要执行它的时候才会被实例化的。

直到执行时才会创建 **Job** 实例  
Job 的实例要到该执行它们的时候才会实例化出来。每次 Job 被执行，一个新的 Job 实例会被创建。其中暗含的意思就是你的 Job 不必担心线程安全性，因为同一时刻仅有一个线程去执行给定 Job 类的实例，甚至是并发执行同一 Job 也是如此。

#### 使用 JobDataMap 对象设定 Job 状态 ####

你能使用org.quartz.JobDataMap来定义Job的状态。JobDataMap 通过它的超类org.quartz.util.DirtyFlagMap 实现了java.util.Map 接口，你可以向 JobDataMap 中存入键/值对，那些数据对可在你的 Job 类中传递和进行访问。这是一个向你的Job 传送配置的信息便捷方法。代码 4.6 描述的就是，我们特意创建了一个叫做 PrintJobDataMapJob 的 Job，使用了这种方式。

代码 **4.6.** 使用 **JobDataMap** 向你的 **Job** 传递配置信息

public class Listing_4_6 {
    
        static Logger logger = Logger.getLogger(Listing_4_6.class);
        public static void main(String[] args) {
            Listing_4_6 example = new Listing_4_6();
            example.runScheduler();
        }
        public void runScheduler(){
            Scheduler scheduler = null;
            try{
                //Create a default instance of the Scheduler
                scheduler = StdSchedulerFactory.getDefaultScheduler();
                scheduler.start();
                JobDetail jobDetail = JobBuilder.newJob(PrintJobDataMapJob.class).
                        withIdentity("PrintJobDataMapJob",Scheduler.DEFAULT_GROUP).
                        build();
                jobDetail.getJobDataMap().put("name","John Doe");
                jobDetail.getJobDataMap().put("age",23);
                jobDetail.getJobDataMap().put("balance",new BigDecimal(1234));
    
                Trigger trigger = TriggerBuilder.newTrigger().withIdentity("trigger", Scheduler.DEFAULT_GROUP).
                        withSchedule(SimpleScheduleBuilder.simpleSchedule().withIntervalInSeconds(2).repeatForever()).
                        build();
                scheduler.scheduleJob(jobDetail,trigger);
    
            }catch (Exception e){
                logger.error(e);
            }
        }
    }

在代码 4.6 中，我们想要传递给 PrintJobDataMapJob 的信息存储到了 JobDetail 的 JobDataMap 中。因为 JobDataMap实现了 java.util.Map 接口，所以我们可以以键/值对的形式在其中存储状态。JobDataMap 包含了许多精细的方法使处理起对象来方便简易。一般使用 map 的话，我们不得不要显式把 Object 类型转换成已知类型。JobDataMap 包含的方法能帮你完成这些工作。

当 Scheduler 最后调用了 Job，Job 可以通过 JobDetail 来访问到 JobDataMap 中的键/值对。代码 4.7 就是这个PrintJobDataMapJob.

代码 **4.7. Job** 能通过 **JobExecutionContext** 对象访问 **JobDataMap**

public class PrintJobDataMapJob implements Job{
    
        static org.apache.log4j.Logger logger = org.apache.log4j.Logger.getLogger(PrintJobDataMapJob.class);
        @Override
        public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
            logger.info("in PrintJobDataMapJob");
            //Every job has its own job detail
            JobDataMap jobDataMap = jobExecutionContext.getJobDetail().getJobDataMap();
            Iterator iter = jobDataMap.keySet().iterator();
            while(iter.hasNext()){
                Object key = iter.next();
                Object value = jobDataMap.get(key);
                logger.info("Key : " + key + " - Value" + value);
            }
        }
    }

当你获得了 JobDataMap，你可以当它是任何 map 实例一样调用它的方法。一般的，你会自己选择一个预定义的键值来访问JobDataMap 中的数据。你也可以像代码 4.7 那样遍历其中的所有数据。像 PrintJobDataMapJob 那样的 Job，**JobDataMap 中的属性成为了一个在部署 Job 的客户端与 Job 自身之间的一个非正式的契约。Job 的创建者应该非常仔细的文档化规定哪些属性是必须的**，哪些又是可选的。这样有助于确保 Job 能被团队中的其他成员重用。

自 **Quartz 1.5** 始，**JobDataMap** 对 **Trigger** 也是可用的  
在 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.

同样的方式，J2EE 中有状态的 Session Bean(SFSB) 能在两个调用之间保持状态，Quartz 的 StatefulJob 也能在两次 Job执行间保持它的状态。然而，正如 SFSB 那样，Quartz 的有状态的 Job 与无状态的 Job 比起来也有一些不利的方面。

**·**使用有状态的 **Job**  
当你需要在两次 Job 执行间维护状态的话，Quartz 框架为此提供了 org.quartz.StatefulJob 接口。StatefulJob 接口仅仅是扩展了 Job 接口，未加入新的方法。你只需要通过使用与 Job 接口相同的 execute() 方法简单的实现 StatefulJob 接口即可。假如你有已存在的 Job 类，你所有要做的只是改变 Job 的接口为 org.quartz.StatefulJob。

Job 和 StatefulJob 在框架中使用中存在两个关键差异。首先，JobDataMap 在每次执行之后重新持久化到 JobStore 中。这样就确保你对 Job 数据的改变直到下次执行仍然保持着。

改变有状态 **Job** 的 **JobDataMap**  
你可以在有状态 Job 中简单的通过 map 的 put() 方法来修改 JobDataMap.已存在的任何数据会被新的数据覆盖掉。你也能对无状态的 Job 这么做，但是因为对于无状态 Job 来说，JobDataMap 不会持久化，所以数据不会保存下来。对于 Trigger 和JobExecutionContext 上的 JobDataMap 的数据修改也是没能保存下来的。

转载于:https://my.oschina.net/LucasZhu/blog/1476270

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20210726/8983a598e266424fa8ef6f4210667be1.png
[125112_rRC5_3101476.png]: https://static.oschina.net/uploads/space/2017/0720/125112_rRC5_3101476.png
[125704_ZMrn_3101476.png]: https://static.oschina.net/uploads/space/2017/0720/125704_ZMrn_3101476.png
[130534_Q8Fn_3101476.png]: https://static.oschina.net/uploads/space/2017/0720/130534_Q8Fn_3101476.png