开源调度框架Quartz最佳实践
Quartz是一个Java调度框架，当前的最新版本为2.2.1。
以Quartz 2.2.1版为例，Quartz最佳实践（用于生产系统）总结如下：
1、跳过更新检查
Quartz内置了一个“更新检查”特性，因此Quartz项目每次启动后都会检查官网，Quartz是否存在新版本。这个检查是异步的，不影响Quartz项目本身的启动和初始化。
可以在Quartz配置文件中，设置org.quartz.scheduler.skipUpdateCheck的属性为true来跳过更新检查。
2、JobDataMap技巧
在JobDataMap应该只存储原始的数据类型（包括字符串），这样可以避免数据序列化的问题以及长期运行的问题。
3、使用合并后的JobDataMap
官方推荐，Job.execute()方法通常应该从JobExecutionContext发现的JobDataMap中取回数据，而不是直接从JobDetail中取数据。
4、使用TriggerUtils
TriggerUtils工具类作用如下：
1）提供了一种更简单的创建触发器的方式；
2）提供了带调度器创建触发器的各种方法来满足特殊需求，与直接初始化特殊类型的触发器（SimpleTrigger、CronTrigger），然后调用各种setter方法进行配置相反。
3）提供了更为简单的创建日期时间的方法；
4）提供了辅助类来分析触发器（比如计算未来的激活次数等）。
5、一定不要直接写数据到Quartz表
通过SQL语句写调度数据到数据库表，而不应该使用调度API来写数据，因为：
1）会导致数据冲突（删除数据、争夺的数据）。
2）会导致当触发器的激活时间到了时，Job会看起来不见了。
3）会导致当触发器的激活时间到了时，Job会不执行，看起来“仅仅坐在那儿”。
4）可能会导致死锁
5）还可能导致其他奇怪的问题和数据崩溃等
6、一定不要把多个非集群的调度器实例指向同一个数据库表
如果把多个调度器实例指向同一个数据库表，而且这些调度器实例没有做集群配置，那么可能会发生：
1）会导致数据冲突（删除数据、争夺的数据）。
2）会导致当触发器的激活时间到了时，Job会看起来不见了。
3）会导致当触发器的激活时间到了时，Job会不执行，看起来“仅仅坐在那儿”。
4）可能会导致死锁
5）还可能导致其他奇怪的问题和数据崩溃等
7、确保适合的数据源连接数
官方推荐数据源的最大连接数应该配置为线程池的最小工作线程数的3倍。如果你还需要额外的连接（比如频繁地调用调度器API），如果还使用了JobStoreCMT，那么非托管的数据源的最大连接数应该是至少4倍以上。
8、避免调度Job的时间安排在夏令时转换的交界处
SimpleTrigger触发器不受此影响。
9、等待条件
如果连接池所有的线程都处于繁忙状态，那么长期运行的Job会阻止其他Job的运行。
如果在工作线程执行Job时调用Thread.sleep()后，Job余下的工作有可能得不到执行，因为会等待一些条件（比如数据记录有效后）为真后再执行。
最佳的解决方案是释放工作线程（退出Job），允许其他Job在线程上得到执行。Job可以重新调度自身，或者等其他Job在退出前调度它。
10、Job抛出异常
Job执行方法应该包含try-catch代码块，以处理各种可能发生的异常。
如果Job抛出异常，Quartz通常会立即重新执行（看起来会再次抛出同样的异常）。最佳的方式是让Job能够捕获它可能会遇到的所有异常，处理这些异常，然后再重调度Job。
11、可恢复性和幂等性
标记为“可恢复的”、在进行中的Job在调度器失效后是可以自动重新执行的。这意味着同样的Job工作可能会执行两次。
12、在监听器中保持代码简洁高效
不鼓励监听器内执行大量的工作，执行Job或完成触发器并激活另一个Job等，都应该绑定到监听器。
13、监听器抛出异常
每个监听器（TriggerListener、JobListener和SchedulerListener）应该包含try-catch代码块，以处理各种可能发生的异常。
如果监听器抛出异常，它或许会导致其他监听器得不到通知或阻止Job的执行等等。
14、注意安全
一些开发者会通过应用程序的用户接口暴露Quartz调度器的功能，这很有用，但也很危险。因为恶意用户可以通过这种方式控制或破坏您的系统。
