SpringBoot下集成Quartz调度任务的一个问题及解决

SpringBoot下集成Quartz调度任务

今天在公司项目里翻代码，发现一个Quartz集成时遇到的小坑——准确地说，是挺反常识的一个配置生效机制。琢磨之后顺手记下来，也许能帮到同样在折腾Quartz的人。

现象是这样的

项目里引入Quartz的时候，并没有用SpringBoot官方提供的spring-boot-starter-quartz，而是直接依赖了Quartz的原生jar包，像下面这样：

     org.quartz-scheduler
     quartz
     2.2.3
 
 
     org.quartz-scheduler
     quartz-jobs
     2.2.3
 

然后YML配置里，顺理成章地写了spring.quartz相关的属性：

spring:
  quartz:
    properties:
      org:
        quartz:
          scheduler:
            instanceName: DefaultQuartzScheduler
            instanceId: AUTO
          jobStore:
            class: org.quartz.impl.jdbcjobstore.JobStoreTX
            driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
            tablePrefix: QRTZ_
            isClustered: true
            clusterCheckinInterval: 10000
            useProperties: false
          threadPool:
            class: org.quartz.simpl.SimpleThreadPool
            threadCount: 10
            threadPriority: 5
            threadsInheritContextClassLoaderOfInitializingThread: true
    job-store-type: jdbc

问题来了：明明没有引入spring-boot-starter-quartz，为什么spring.quartz的配置还能生效？

好奇之下翻了一下SpringBoot的自动配置源码。SpringBoot的自动配置模块org.springframework.boot.autoconfigure.EnableAutoConfiguration里，本来就已经包含了Quartz的自动配置类：

org.springframework.boot.autoconfigure.quartz.QuartzAutoConfiguration

也就是说

不管项目里有没有引入那个starter，只要classpath里存在Scheduler、SchedulerFactoryBean、PlatformTransactionManager这几个类，这个配置类就会被触发加载。看一下它的核心注解就明白了：

@Configuration
@ConditionalOnClass({ Scheduler.class, SchedulerFactoryBean.class,
		PlatformTransactionManager.class })
@EnableConfigurationProperties(QuartzProperties.class)
@AutoConfigureAfter({ DataSourceAutoConfiguration.class,
		HibernateJpaAutoConfiguration.class })
public class QuartzAutoConfiguration {
...省略代码

关键就在@ConditionalOnClass上——它只检查相关的类是否存在于类路径中，跟starter没有直接关系。所以只要依赖了Quartz的原生jar，Scheduler和SchedulerFactoryBean自然就有了，自动配置也就顺理成章地生效了。

说到底，SpringBoot的starter本质上只是一个依赖管理的约定包，本身不包含任何业务代码，它的作用就是帮你把需要的jar以及对版本的管理一起拉进来。而自动配置类则是自带的、全局的。

同样的“套路”在其他starter组件中其实也存在，比如spring-boot-starter-data-redis，如果你直接引了jedis包而没有引starter，只要classpath里有相关类，SpringBoot也会尝试帮你自动配置。但能不能生效，还得看是否存在对应的*AutoConfiguration。

那么，以后是不是可以直接忽略starter、裸依赖jar就行了？

当然不建议这么做。虽然自动配置确实还会工作，但有两个明显的隐患：

• 不直观：配置是否生效、何时生效、额外引入了哪些bean，完全要靠跟源码才能搞清楚，对团队协作和维护都是一种负担。
• 版本管理容易翻车：starter最核心的价值之一就是帮你管理好依赖jar的版本，确保和当前的SpringBoot版本兼容。如果自己手动引入jar，版本号写错了或者没对齐，轻则配置不生效，重则运行时给你抛个类冲突异常。

所以，虽然今天的“反常识”现象从原理上解释得通，但最佳实践还是老老实实用starter。知其所以然就好，生产代码里别图省事绕过去。