Quartz框架（一）—Quartz的基本配置
Quartz框架（二）—jobstore数据库表字段详解
Quartz框架（三）—任务的并行/串行执行
Quartz框架（四）—misfire处理机制
Quartz框架（五）— 有状态的job和无状态job
Quartz框架（六）— Trigger状态转换
Quartz框架（七）— Quartz集群原理
Quartz框架（八）— Quartz实现异步通知
Quartz框架（九）— 动态操作Quartz定时任务
Quartz框架（十）监听
Quartz是启动定时任务的框架。
1. Quartz的核心元素
Quartz调度依靠的三大核心元素就是：Scheduler、Trigger、Job。
1. Job（任务）
作用：具体要执行的业务逻辑，比如：发送短信、发送邮件、访问数据库、同步数据等。
2. Trigger（触发器）
作用：用来定义Job（任务）触发条件、触发时间，触发间隔，终止时间等。
四大类型：SimpleTrigger、CornTrigger、DateIntervalTrigger、NthIncludedDayTrigger。
3. scheduler（调度器）
作用：Scheduler启动Trigger去执行Job。
类型：Scheduler由scheduler工厂创建：DirectSchedulerFactory 或者 StdSchedulerFactory。
第二种工厂StdSchedulerFactory使用较多，因为 DirectSchedulerFactory 使用起来不够方便，需要作许多详细的手工编码设置。
Scheduler 主要有三种：RemoteMBeanScheduler， RemoteScheduler 和 StdScheduler。
2. Quartz的准备工作
2.1. maven依赖
<!--quartz相关依赖-->
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz-jobs</artifactId>
<version>2.2.1</version>
</dependency>
>>>>SpringBoot替换为：>>>>
<!--quartz依赖-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-quartz</artifactId>
</dependency>
2.2. Quartz的配置文件
在Quartz JAR文件的org.quartz包下就包含一个quartz.properties属性配置文件并提供了默认属性。如果需要调整默认配置，可以在类路径下建立一个新的quartz.properties，它将自动被Quartz加载并覆盖默认的设置。
2.2.1 文件的加载位置
需要注意的是：配置文件一般为quartz.properties文件，但是如果使用yml文件格式的配置，则quartz.properties里面的配置会失效；
【配置文件】默认：优先顺序Classpath:quartz.properties-->org/quartz/quartz.properties
【程序内指定】在StdSchedulerFactory.getScheduler()之前使用StdSchedulerFactory.initialize(xx)
2.2.2Quartz的配置信息
注：QuartzProperties类读取的就是我们yml文件中的配置。
1. 基础配置
#可以为任意字符串，对于scheduler来说此值没有意义，但是可以区分同一系统中多个不同的实例，
#如果使用了集群的功能，就必须对每一个实例使用相同的名称，这样使这些实例“逻辑上”是同一个scheduler。
org.quartz.scheduler.instanceName = JobScheduler
#可以是任意字符串，但如果是集群，scheduler实例的值必须唯一，可以使用AUTO自动生成。
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
# 默认false，若是在执行Job之前Quartz开启UserTransaction，此属性应该为true。
#Job执行完毕，JobDataMap更新完（如果是StatefulJob）事务就会提交。默认值是false，可以在job类上使用@ExecuteInJTATransaction 注解，以便在各自的job上决定是否开启JTA事务。
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
#一个scheduler节点允许接收的trigger的最大数，默认是1，这个值越大，定时任务执行的越多，但代价是集群节点之间的不均衡。
org.quartz.scheduler.batchTriggerAcquisitionMaxCount=1
2. 调度器线程池配置
#线程池的实例类，（一般使用SimpleThreadPool即可满足几乎所有用户的需求）
org.quartz.threadPool.class= org.quartz.simpl.SimpleThreadPool
#线程数量，不会动态增加
org.quartz.threadPool.threadCount= 10
#线程优先级
org.quartz.threadPool.threadPriority= 5
#加载任务代码的ClassLoader是否从外部继承
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread= true
#是否设置调度器线程为守护线程
org.quartz.scheduler.makeSchedulerThreadDaemon: true
3. Configure JobStore 作业存储配置
3.1. RAMJobStore
将schedule相关信息保存在RAM中，轻量级，速度快，遗憾的是应用重启时相关信息都将丢失。
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
#最大能忍受的触发超时时间，如果超时则认为“失误”
org.quartz.jobStore.misfireThreshold = 60000
3.2. JDBC-JobStore
将schedule相关信息保存在RDB中，有两种实现：JobStoreTX和JobStoreCMT
前者为application自己管理事务；
后者为application server管理事务，即全局JTA；
JDBCJobStore终于把数据持久化起来了，这个也是使用最广泛的数据存储方式。在于Spring集成后都不需要自己配置一遍数据库连接了。
配置方式以及默认值：
#选择JDBC的存储方式
org.quartz.jobStore.class= org.quartz.impl.jdbcjobstore.JobStoreTX
#类似于Hibernate的dialect，用于处理DB之间的差异，StdJDBCDelegate能满足大部分的DB（授权）
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
#存储相关信息表的前缀
org.quartz.jobStore.tablePrefix = QRTZ_
#这个值必须datasource的配置信息
org.quartz.jobStore.dataSource = myDS
#JobDataMaps是否都为String类型
#（若是true的话，便可不用让更复杂的对象以序列化的形式保存到BLOB列中。以防序列化可能导致的版本号问题）
org.quartz.jobStore.useProperties = false
#最大能忍受的触发超时时间，如果超时则认为“失误”
org.quartz.jobStore.misfireThreshold = 60000
#是否是应用在集群中，当应用在集群中时必须设置为TRUE，否则会出错。
#如果有多个Quartz实例在用同一套数据库时，必须设置为true。
org.quartz.jobStore.isClustered=False
#只用于设置了isClustered为true的时候，设置一个频度（毫秒），用于实例报告给集群中的其他实例。
#这会影响到侦测失败实例的敏捷度。
org.quartz.jobStore.clusterCheckinInterval =15000
#这是JobStore能处理的错过触发的Trigger的最大数量。处理太多（2打）很快就会导致数据库表被锁定够长的时间，
#这样会妨碍别的（还未错过触发）trigger执行的性能。
org.quartz.jobStore.maxMisfiresToHandleAtATime=20
#设置这个参数为true会告诉Quartz从数据源获取连接后不要调用它的setAutoCommit(false)方法。
#在少数情况下是有用的，比如有一个驱动本来是关闭的，但是又调用这个关闭的方法。但是大部分情况下驱动都要求调用setAutoCommit(false)
org.quartz.jobStore.dontSetAutoCommitFalse=false
#这必须是一个从LOCKS表查询一行并对这行记录加锁的SQL。假设没有设置，默认值如下。
#{0}会在运行期间被前面配置的TABLE_PREFIX所代替
org.quartz.jobStore.selectWithLockSQL=SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE
#值为true时告知Quartz（当使用JobStoreTX或CMT）调用JDBC连接的setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) 方法。这有助于某些数据库在高负载和长时间事务时锁的超时。
org.quartz.jobStore.txIsolationLevelSerializable=false
4. 数据库配置
datasource的相关信息全部定义与quartz.properties中，quartz自己创建datasource。
org.quartz.dataSource.NAME.driver
org.quartz.dataSource.NAME.URL
org.quartz.dataSource.NAME.user
org.quartz.dataSource.NAME.password
org.quartz.dataSource.NAME.maxConnections
需要注意的是，#NAME字段必须与$@org.quartz.jobStore.dataSource保持一致
但是一般我们的数据库连接池一般使用第三方连接池，那么就会导致org.quartz.jobStore.dataSource=#NAME无法配置！！可以使用quartz.job-store-type=jdbc替代。
2.2.3 SpringBoot2.x整合Quartz的配置文件
自动加载的源码：org.springframework.boot.autoconfigure.quartz.QuartzAutoConfiguration
spring:
datasource:
name: mysql_test
type: com.alibaba.druid.pool.DruidDataSource
#druid相关配置
druid:
#监控统计拦截的filters
filter: stat,config
# driver-class-name: com.mysql.cj.jdbc.Driver
#基本属性
url: jdbc:mysql://localhost:3306/mydb
username: root
password: 123456
#初始化连接数
initial-size: 10
#最小活跃连接数
min-size: 5
#最大活跃连接数
max-active: 20
#获取连接的等待时间
max-wait: 60000
#间隔多久进行一次检查，检查需要关闭的空闲连接
time-between-eviction-runs-millis: 60000
#一个连接在池中最小的生存时间(5分钟)
min-evictable-idle-time-millis: 300000
validation-query: SELECT 'X'
# 验证空闲的连接，若无法验证，则删除连接
test-while-idle: true
# 不检测池中连接的可用性（默认false）
# 导致的问题是，若项目作为服务端，数据库连接被关闭时，客户端调用就会出现大量的timeout
test-on-borrow: false
#在返回连接池之前是否验证对象
test-on-return: false
#打开PSCache，并指定每个连接上PSCache的大小。oracle设为true，mysql设为false。分库分表较多推荐设置为false
#第三发连接池在使用的时候，获取到Connection后，使用完毕，调用关闭方法，并没有将Connection关闭，只是放回到连接池中
#如果调用这个方法，而没有手动关闭PreparedStatement，就可能造成内存溢出，但是JDK1.7实现了AutoCloseable接口，就不需要关闭了
pool-prepared-statements: false
max-pool-prepared-statement-per-connection-size: 20
# connection-properties:
use-unfair-lock: true
quartz:
#相关属性配置
properties:
org:
quartz:
scheduler:
# 集群名，区分同一系统的不同实例，若使用集群功能，则每一个实例都要使用相同的名字
instanceName: clusteredScheduler
# 若是集群下，每个instanceId必须唯一
instanceId: AUTO
threadPool:
#一般使用这个便可
class: org.quartz.simpl.SimpleThreadPool
#线程数量，不会动态增加
threadCount: 10
threadPriority: 5
threadsInheritContextClassLoaderOfInitializingThread: true
jobStore:
#选择JDBC的存储方式
class: org.quartz.impl.jdbcjobstore.JobStoreTX
driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
tablePrefix: QRTZ_
useProperties: false
isClustered: true
clusterCheckinInterval: 15000
job-store-type: jdbc
#是否等待任务执行完毕后，容器才会关闭
wait-for-jobs-to-complete-on-shutdown=false
#配置的job是否覆盖已经存在的JOB信息
overwrite-existing-jobs: false
1. 讲一下最后两个配置
-
wait-for-jobs-to-complete-on-shutdown：Quartz默认false，是否等待任务运行完毕后关闭Spring容器，若是为false的情况下，可能出现
java.lang.IllegalStateException: JobStore is shutdown - aborting retry异常，推荐开启。 -
overwrite-existing-jobs：这个是配置文件的job是否会覆盖数据库正在运行的job。quartz启动之后，会以数据库的为准，若该属性为false，则配置文件修改后不会起作用。
2. 线程池配置不生效问题及原因
配置线程池参数，无论怎样都不生效。经过debug得知。源码：org.quartz.impl.StdSchedulerFactory#instantiate()，由于线程池的参数有误，导致配置的是默认值。
image.png
相关参考：
在spring quartz中，造成 misfired job 的原因有哪些
Quartz-job的quartz.properties配置文件说明
网友评论