Quartz,每次执行job,job永远是全新的对象,但是，如果job实现org.quartz.StatefulJob接口,而不是job接口.
此时JobDetail的JobDataMap将会共享一个对象。
注意:
当实现有状态接口,StatefulJob时,只有JobDetail的JobDataMap是共用的,其他的，比如,Job本身,Trigger等,仍然每次执行
的时候是全新的对象。所以,只有JobDetail的JobDataMap是共用的，其他的trigger.getJobDataMap(),context.getMergedJobDataMap(),等这些JobDataMap，任然是全新的
以下引用文档:
使用有状态的 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 的数据修改也是没能保存下来的。 |
另 一个无状态和有状态 Job 重大区别就是：两个或多个有状态的 JobDetail 实例不能并发执行。说的是你创建并注册了一个有状态 JobDetail 到 Scheduler 上。你还建立了两个 Trigger 来触发这个 Job：一个每五分钟触发，另一个也是每五分钏触发。假如这两个 Trigger 试图在同一时刻触发 Job，框架是不允许这种事情发生的。第二个 Trigger 一直会被阻塞直到第一个结束。
这就产生了处理 JobDataMap 存储的需求了。因为 JobDataMap 的存储是伴随着 JobDetail 的，而 JobDetail 定义了 Job 实例，所以线程安全性问题必须纳入到我们考虑的范畴。同一时刻只能由一个线程去运行并更新 JobDataMap 存储。然而，由于在第一个 Trigger 有机会更新存储之前第二个就会试图执行 Job，所以数据有可能会出错。甚至可能的话还会第二个 Trigger 先于第一个执行完成(依赖于你的 Job 所做的事情)，这时就可能会出现奇怪的结果。
因为这些区别，在你使用 StatefulJob 时可要谨慎了。当你需要避免并发执行一个 Job 时，那么有状态 Job 就是你最简单的筹码了。在 J2EE 的世界里，有状态一词已经引起了一些负面影响，但对于 Quartz 却非如此。