企业官网建设流程全解析

每次聊到定时任务，我都会先反问一句：你真的需要 Quartz 吗？Spring Boot 项目里加一个调度框架，意味着一定有原生的@Scheduled满足不了的地方——要么是运行中要动态调整任务的执行时间，要么任务状态需要挂库保证重启不丢，要么线上部署了多实例需要集群调度。这三样只要占了一样，Spring Boot 集成 Quartz 就是绕不开的必修课。

这篇文章我按自己踩过的路径来写：先讲引入 Quartz 到底要解决什么问题，再讲为什么选它而不是其他的任务框架，然后是完整的集成步骤、动态任务管理、数据库持久化和多实例集群，最后把经典坑挨个拆一遍。并发重叠执行、Cron 时区错乱、Job 里注入 Service 爆空指针，这些都是线上事故级别的细节，新手最容易踩，照着本文的步骤能少走不少弯路。

1. 项目概述与核心需求拆解

1.1 原生定时任务到底差在哪

很多人会问：Spring Boot 自带的@Scheduled注解用起来那么简单，一个注解加一个 Cron 表达式就成了，为什么还要多学一套框架？我用了一段时间之后才体会到这里面的差异不是“功能的多少”，而是“能不能管理”。

@Scheduled的硬伤主要有几个。

Cron 表达式写死在配置里，想改执行频率必须改代码、走发布流程、重启应用。而现实业务中，“每天凌晨跑数据同步”这种需求，很可能运营早上突然告诉你“改成每半小时跑一次”，如果每次都要重启，代价太高。

任务默认是单线程串行执行的。多个@Scheduled方法放在同一个类里，如果某一个方法执行时间特别长，其他定时任务会被阻塞排队，在线上一旦某个接口卡了，整个调度几乎瘫痪。

没有任务补偿机制。应用一重启，所有定时任务从头开始计时，任务状态全部丢失。对于“只允许每天跑一次”的任务，如果服务器凌晨刚好重启了，当天任务就可能漏跑。

多实例部署时问题更明显。两个应用实例同时启动，同一个任务会在两台机器上各执行一遍，重复数据、重复扣款这类问题就出来了。

而 Quartz 就是为解决这些问题而生的：任务和触发器可以被持久化到数据库，支持动态增删改任务，支持集群部署抢占执行，还内置了线程池和错过任务补偿逻辑。

1.2 集成前要拍板的三个关键决策

在动手写代码之前，有三件事必须先想清楚，否则后面配置方向完全不一样。

第一，任务存储介质。用内存还是数据库？如果只是传统单体应用，任务数量稳定，重启后手动触发一次也无所谓，那内存存储就够了，代码几乎不用额外配置。如果任务要长期运行、需要保证重启不丢，或者生产环境是集群，那就必须走 JDBC 存储。这个决定直接影响后面的数据库表初始化和配置项。

第二，是否上集群。单机部署和双实例部署，最大的区别在于是否需要分布式调度锁。Quartz 集群模式下，多个实例共享同一张任务表，谁抢到锁谁执行，这个机制能天然避免重复执行，但也带来了数据库锁竞争的问题。

第三，任务如何生成。任务是在代码里写死，还是通过后台管理界面动态录入？如果只是固定几个任务，直接在启动类里注册就好；如果是那种“用户可以在界面上新建任务、填 Cron 表达式、选执行方法”的场景，就必须封装一套动态注册、暂停、恢复、删除的 Service。这两者代码结构差别很大，提前想好可以避免后面大改。

我自己的经验是：凡是线上系统，默认就按“JDBC 存储 + 集群兼容 + 动态管理”这三条一起做，因为后期加字段、加实例、改任务，都比前期多花几十行配置的代价大得多。

2. 技术选型对比与整体架构设计

2.1 为什么不直接用@Scheduled或者 XXL-Job

有段时间我也纠结过：Quartz 是不是太老了？XXL-Job 有可视化界面、有调度日志、有失败告警，不是更香吗？

这个问题的答案取决于团队规模和系统体量。

如果项目只需要 3～5 个固定的低频定时任务，@Scheduled确实极其合适，零依赖、代码直观、部署简单。但你要的是动态调度、手动触发、集群防重、历史任务记录，@Scheduled就完全不够用了。

XXL-Job 这种分布式任务调度平台虽然功能更全，但它相当于是把调度能力单独抽成了一个中心化服务，需要额外部署一个调度中心，引入一套自己的概念和 UI。如果公司运维能力一般、服务器资源紧张、又不需要太花哨的监控告警，那为几个定时任务再维护一个调度中心其实是过度设计。

Quartz 的定位正好卡在中间。它是嵌入式的调度库，和 Spring Boot 进程跑在一起，不需要独立部署；它支持 Job 和 Trigger 的持久化，有不错的调度灵活性；它还能通过集群配置实现“一人干活、大家待命”的效果。对绝大多数业务系统来说，Quartz 的上手成本和解耦程度是最平衡的。

2.2 Quartz 的核心对象关系图（用大白话讲）

Quartz 虽然概念不少，但核心只需要把握五个对象，我用一个生活例子把它们串起来。

Scheduler 是总调度室，是唯一对外的窗口。我们跟 Quartz 打交道，基本都在调 Scheduler 的方法：注册任务、暂停任务、修改触发器，都是通过它下发指令。

Job 是工人，也就是真正要执行的那段业务逻辑。我们在类里实现的execute()方法，就是工人干活的现场。

JobDetail 是工人的档案。Quartz 不会直接拿着 Job 类去调度，而是通过 JobDetail 来找到对应的工人，档案上还挂了一个叫 JobDataMap 的储物箱，用来传递配置参数。同一个工人可以承载不同的档案，比如同一个清理任务的 Job 类，挂上“订单”和“日志”两份档案，就是两个独立任务。

Trigger 是闹钟。它决定工人什么时候开工，分为 CronTrigger（按日历规则跑）和 SimpleTrigger（按固定间隔跑），还可以通过 JobDataMap 把参数传给 Job。

JobStore 是档案室。任务和触发器被登记到档案室，RAMJobStore 就是把档案放在内存，一关机就没了；JDBCJobStore 就是存数据库，重启后还能恢复。这两类档案室的选择，决定了后续所有配置的走向。

理清这几个对象的关系，再看代码就一点都不乱了。实际使用时，我们通常是Scheduler.scheduleJob(jobDetail, trigger)这样一句话，把工人档案和闹钟一起交到调度室手里，后面一切都由调度室接管。

2.3 集群模式和单机模式的核心差异

单机模式下，调度逻辑很简单，本地线程池定时扫描触发器，到点就丢线程池执行。

集群模式下，多个实例都连接同一个数据库，每个实例的调度器都会去读同一张 QRTZ_TRIGGERS 表。如果不做控制，两个实例会同时发现“这个任务该执行了”，导致重复执行。Quartz 的集群机制通过在数据库表上加分布式锁来规避：每次调度前先抢 QRTZ_LOCKS 表里的锁，抢到锁的实例负责取出触发器、注册到本地线程池，其他实例就等着。

所以集群模式的本质不是任务并行执行，而是“多个候选实例，一个实际执行实例，故障自动切换”。这也是为什么配置集群时必须把org.quartz.jobStore.isClustered设为 true，并且所有实例要配置不同的instanceId，让它们能区分彼此。

分布式调度的代价就是增加了对数据库的依赖。如果数据库突然卡顿，调度也会跟着变慢，所以集群模式下要专门关注 QRTZ_LOCKS 表的锁等待情况。

3. Spring Boot 集成 Quartz 的实操步骤

3.1 引入依赖与最小化配置

Spring Boot 从 2.x 开始就提供了官方 starter，这一步非常简单。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency>

引入依赖后，Spring Boot 会自动配置一个 Scheduler 实例，默认使用内存存储（RAMJobStore），线程池默认 10 个线程。如果你什么都不配，也完全可以先跑起来。

推荐在application.yml里做一次显式配置，方便后续扩展：

spring: quartz: job-store-type: memory auto-startup: true overwrite-existing-jobs: true scheduler-name: BizScheduler properties: org: quartz: threadPool: threadCount: 10 threadPriority: 5

这里scheduler-name建议指定一个有业务含义的名称，后面如果排查多个应用时能快速区分。overwrite-existing-jobs设为 true 可以保证同名任务重复注册时直接覆盖掉，而不是抛异常。

3.2 编写第一个可执行的 Job

Job 类不需要继承 Spring 的什么接口，直接实现 Quartz 的Job接口即可。

public class DataSyncJob implements Job { private static final Logger log = LoggerFactory.getLogger(DataSyncJob.class); @Override public void execute(JobExecutionContext context) throws JobExecutionException { JobDataMap dataMap = context.getMergedJobDataMap(); String bizType = dataMap.getString("bizType"); log.info("业务类型[{}]执行数据同步，触发时间：{}", bizType, LocalDateTime.now()); // 这里写真实业务逻辑 } }

一个容易忽略但有价值的细节：execute方法里拿参数，推荐用getMergedJobDataMap()而不是getJobDetail().getJobDataMap()。因为 Trigger 上也可以挂 JobDataMap，getJobDetail()只能拿到 JobDetail 上挂的数据，而getMergedJobDataMap()会把 JobDetail 和 Trigger 上的数据合并到一起，优先级是 Trigger 覆盖 JobDetail。这个函数处理动态传参时能省很多事。

3.3 写一个能注入 Spring Bean 的 JobFactory

这是几乎所有人第一次都会踩坑的地方：在 Job 实现类里用@Autowired注入 Service，结果运行时报空指针。

根因很简单：Quartz 默认通过Class.newInstance()来创建 Job 对象，这个过程不经过 Spring 容器，所以 Spring 管理的 Bean 根本不会被注入。解决办法是自定义一个 JobFactory，让 Quartz 创建 Job 实例后，交给 Spring 的AutowireCapableBeanFactory帮它完成依赖注入。

@Component public class SpringJobFactory extends SpringBeanJobFactory implements ApplicationContextAware { private ApplicationContext applicationContext; @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } @Override protected Object createJobInstance(TriggerFiredBundle bundle) throws Exception { Object jobInstance = super.createJobInstance(bundle); applicationContext.getAutowireCapableBeanFactory().autowireBean(jobInstance); return jobInstance; } }

接着注册这个 JobFactory：

@Configuration public class QuartzConfig { @Bean public SchedulerFactoryBean schedulerFactoryBean(SpringJobFactory springJobFactory) { SchedulerFactoryBean factory = new SchedulerFactoryBean(); factory.setJobFactory(springJobFactory); return factory; } }

注意SchedulerFactoryBean是 Spring 对 Quartz 的封装，Spring Boot 会把这个工厂生成的 Scheduler 直接暴露为一个 Bean。后面不管在哪个 Service 里通过@Autowired private Scheduler scheduler;拿到的，就是同一个调度器实例。

这样处理之后，Job 里就能正常使用@Autowired了。

3.4 触发器 Trigger 的三种典型用法

Trigger 决定任务什么时候跑。日常开发里，我基本只用下面三种。

CronTrigger，适合 Cron 表达式能表达的复杂规则，比如“每天凌晨 2 点”、“周一到周五的上午 9 点半”。

CronTrigger cronTrigger = TriggerBuilder.newTrigger() .withIdentity("dataSyncTrigger", "syncGroup") .withSchedule(CronScheduleBuilder.cronSchedule("0 0 2 * * ?")) .build();

SimpleTrigger，适合“固定间隔 + 固定重复次数”的场景，比如心跳任务、轮询任务。

SimpleTrigger simpleTrigger = TriggerBuilder.newTrigger() .withIdentity("heartbeatTrigger", "monitorGroup") .startAt(DateBuilder.futureDate(10, DateBuilder.IntervalUnit.SECOND)) .withSchedule(SimpleScheduleBuilder.simpleSchedule() .withIntervalInSeconds(30) .repeatForever()) .build();

一次性延迟任务，适合任务注册后只等几分钟执行一次的场景，比如“10 分钟后发送一个通知”。

Trigger oneTimeTrigger = TriggerBuilder.newTrigger() .withIdentity("oneTimeTrigger", "tempGroup") .startAt(new Date(System.currentTimeMillis() + 10 * 60 * 1000)) .build();

这三种 trigger 构建方式理解了，后面封装动态管理工具类就很顺手。

4. 动态任务管理：在线增删改定时任务

4.1 封装一个 QuartzService 工具类

动态管理是 Quartz 相比@Scheduled最大的优势。把常用的调度操作封装成一个 Service，后面写 Controller 接口就很轻松。

@Service public class QuartzJobService { @Autowired private Scheduler scheduler; /** * 新增一个 Cron 任务 */ public void addCronJob(String jobName, String groupName, Class<? extends Job> jobClass, String cronExpression, JobDataMap jobDataMap) throws Exception { JobDetail jobDetail = JobBuilder.newJob(jobClass) .withIdentity(jobName, groupName) .setJobData(jobDataMap) .storeDurably() .build(); CronTrigger trigger = TriggerBuilder.newTrigger() .withIdentity(jobName + "Trigger", groupName) .withSchedule(CronScheduleBuilder.cronSchedule(cronExpression)) .build(); scheduler.scheduleJob(jobDetail, trigger); } /** * 暂停任务 */ public void pauseJob(String jobName, String groupName) throws Exception { scheduler.pauseJob(JobKey.jobKey(jobName, groupName)); } /** * 恢复任务 */ public void resumeJob(String jobName, String groupName) throws Exception { scheduler.resumeJob(JobKey.jobKey(jobName, groupName)); } /** * 删除任务 */ public void deleteJob(String jobName, String groupName) throws Exception { scheduler.deleteJob(JobKey.jobKey(jobName, groupName)); } /** * 修改触发器的 Cron 表达式 */ public void updateCron(String jobName, String groupName, String cronExpression) throws Exception { TriggerKey triggerKey = TriggerKey.triggerKey(jobName + "Trigger", groupName); CronTrigger newTrigger = TriggerBuilder.newTrigger() .withIdentity(triggerKey) .withSchedule(CronScheduleBuilder.cronSchedule(cronExpression)) .build(); scheduler.rescheduleJob(triggerKey, newTrigger); } /** * 查询任务触发状态 */ public String getJobState(String jobName, String groupName) throws Exception { TriggerKey triggerKey = TriggerKey.triggerKey(jobName + "Trigger", groupName); Trigger.TriggerState state = scheduler.getTriggerState(triggerKey); return state.name(); } }

一个实操细节：新增任务时返回值的判断很重要。scheduleJob返回Date，表示该触发器下一次触发的时间。如果返回 null，说明触发器没有安排未来的执行时间，任务其实不会跑。业务上应该把这种情况当异常抛给前端处理。我自己就遇到过把 Cron 表达式解析错了、写成了“过去的时间”，结果前端界面显示任务创建成功，后台却一直不触发。

4.2 任务管理接口的实际落地

有了 Service，再套一层 Controller 就能在界面上管理任务了。

@RestController @RequestMapping("/api/jobs") public class JobManagerController { @Autowired private QuartzJobService quartzJobService; @PostMapping("/create") public void createJob(@RequestBody JobCreateParam param) throws Exception { quartzJobService.addCronJob( param.getJobName(), param.getGroupName(), Class.forName(param.getJobClassName()), // 实际项目中建议用白名单映射，不要直接 Class.forName param.getCronExpression(), param.getJobDataMap() ); } }

这里必须提醒一个安全细节：千万不要把Class.forName的类途径直接暴露给前端，否则用户传入任意类名可能导致类加载异常。正规做法是维护一个业务类型到 Job 类的映射表，前端传业务类型 code，后端用 switch 或 Map 找到对应的 Job 类。这也算是我踩过的一个不大不小的坑。

4.3 动态修改 Cron 的常见误区

rescheduleJob和replaceTrigger都能达到修改触发器的目的，但有个容易搞错的前提：rescheduleJob要求触发器已经存在，如果之前没有为这个 JobDetail 绑定触发器，直接rescheduleJob会报Unable to Trigger之类的异常。

稳妥的做法是：新增任务时就让 JobDetail 和 Trigger 一起保存；修改时用rescheduleJob。如果 JobDetail 是独立创建存储的（storeDurably(true)），首次绑定触发器应该用scheduleJob(jobDetail, trigger)或者replaceTrigger，而不是rescheduleJob。

还有一个大家很容易忽略的细节：修改了 Job 实现类的代码，即使重启了应用，Quartz 的 JobDetail 和 Trigger 是从数据库恢复的，如果 JobDataMap 里缓存了旧的类路径或者其他参数，改代码并不影响任务数据。这个特性决定了“代码更新后任务配置依然保留”是优势，但也意味着删任务不删表数据，过一段时间可能触发你意想不到的旧任务。

5. 任务持久化与多实例部署

5.1 JDBC 存储任务状态

要从“重启丢任务”变成“重启不丢”，就需要把 JobStore 从内存换成数据库。Spring Boot 做这件事非常简单，改一下配置即可：

spring: quartz: job-store-type: jdbc auto-startup: true scheduler-name: BizScheduler jdbc: initialize-schema: always properties: org: quartz: jobStore: isClustered: false class: org.springframework.scheduling.quartz.LocalDataSourceJobStore

initialize-schema: always表示启动时自动执行 Quartz 自带的建表 SQL。开发环境这么用没问题，生产环境我建议改成never，由 DBA 手动执行建表脚本，避免每次启动都检查一遍数据库元数据，也避免在生产库上执行建表语句的权限问题。

JDBC 存储的核心表主要有以下几张，排查问题时可以直接去查这些表的状态：

改完配置重启，之前任务就会从数据库里加载回来。此时再调用scheduler.getJobKeys(GroupMatcher.anyGroup())，能看到旧任务还在，非常直观地展示了持久化的价值。

5.2 集群模式下的注意事项

多实例部署时，把所有实例的 Quartz 连接同一个数据库，再开启集群配置。

spring: quartz: job-store-type: jdbc jdbc: initialize-schema: never properties: org: quartz: scheduler: instanceId: AUTO instanceName: ClusterScheduler jobStore: class: org.springframework.scheduling.quartz.LocalDataSourceJobStore isClustered: true clusterCheckinInterval: 15000 misfireThreshold: 60000 threadPool: threadCount: 10

这里几个配置项分别起什么作用，我简单说明。

instanceId: AUTO表示每个实例启动时自动生成一个唯一 ID，用于区分集群成员。手写固定 ID 也行，但必须确保每台机器不同，否则集群会以为是同一个实例，锁机制也会错乱。

clusterCheckinInterval是实例向数据库注册自己的心跳间隔，默认 15 秒。这个值不能太小，否则频繁更新数据库会带来额外负载；也不能太大，否则某台机器宕机后，其他实例需要很长时间才能感知并发起故障转移。

Quartz 集群自动故障转移，本质是心跳超时后的锁释放。设置clusterCheckinInterval = 15000时，一个节点一般要 30 秒左右才会被集群判定为失联。对于严格的“秒级转移”需求，Quartz 并不合适，这是架构选型时需要清醒认识的一点。

还有一个高频问题：两台机器的时间必须一致。因为触发器计算下次执行时间时用的是本机时间，如果两台机器时间差了一分钟，可能出现 A 实例已经执行完，B 实例因为时间差又开始执行同一任务。生产环境一定记得配置 NTP 时间同步服务。

5.3 集群锁竞争引发的性能问题

开启集群后，Quartz 每次调度都会操作 QRTZ_LOCKS 表，并且通过SELECT ... FOR UPDATE来获取行锁。在数据库并发压力大时，锁等待会成为性能瓶颈。

我遇到过的一个线上场景就是：数据库慢查询报警，排查半天发现 QRTZ_LOCKS 表的锁等待占了大部分。原因是业务高峰期有很多短周期任务（比如每秒一次），集群节点又不少，锁竞争一下就上来了。

解决办法分几层：一是调大调度周期，短周期任务尽量用 SimpleTrigger 合并成批量任务；二是把数据库和业务库分离，专属实例用来调度；三是如果任务数量很大，评估不会重复执行的任务可以不集群，单独用内存模式承担高频任务。

6. 调试排坑实录：我踩过的几个典型问题

6.1 任务并发重叠执行，数据重复了

现象：一个任务每隔 10 秒拉一次第三方接口，但某次接口响应特别慢，下一次触发时间到了，上一个线程还没跑完，结果两个线程同时跑同一个任务，导致数据重复。

这是因为 Quartz 默认是允许同一个 Job 并发执行的。要禁止并发，只需在 Job 类上加一个注解：

@DisallowConcurrentExecution public class PullOrderJob implements Job { // ... }

加了之后，Quartz 在触发下一次执行时，如果发现上一次还没跑完，会跳过这次触发，而不是开新线程。

但要清楚，这个注解限制的是同一个 JobKey 下的并发，不是不同 Job 之间。如果两个不同的 JobDetail 都指向同一个 Job 类，它们之间依然可以并发执行。这也是很多人的误解点。

6.2 Cron 时区错乱，任务整整晚了一个小时

现象：任务配的是“每天早上 8 点”，可实际执行时间总是 9 点。

排查到最后，发现服务器时区是 UTC，数据库连接串里也没有指定时区，Quartz 构建 CronTrigger 时用的是系统默认时区，导致 Cron 表达式按 UTC 解析，比北京时间晚 8 小时。

解决办法有两个。一个是全局统一服务器时区，这个治本。另一个是在构建 CronTrigger 时显式指定时区：

CronScheduleBuilder builder = CronScheduleBuilder.cronSchedule("0 0 8 * * ?") .inTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));

这种写法能保证调度行为的确定性，不受服务器时区设置影响。如果业务对时间特别敏感，我建议所有 CronTrigger 都显式加上inTimeZone，哪怕服务器时区现在是对的，也不依赖这个“隐式约定”。

6.3 Job 里注入 Service 全是 null

这是新接触 Quartz 的人最高频的报错。原理前面已经说过，默认创建 Job 不经过 Spring 容器。解决方式就是配置自定义 JobFactory，上面给出了完整代码。

补充一个额外细节：如果使用自定义 JobFactory，但 Job 类本身是通过new在代码里实例化的（比如DataSyncJob.class.newInstance()），那就直接绕过了 Spring，注入依然无效。正确做法是保持 Job 类有默认构造方法，让 Quartz 自己实例化，再由 JobFactory 调用autowireBean(jobInstance)完成注入。

6.4 修改 Cron 之后任务还是按旧时间跑

现象：调用updateCron之后，后台数据库里 QRTZ_CRON_TRIGGERS 的 CRON_EXPRESSION 已经更新了，但任务执行时间还是老样子。

最常见的原因是：项目里存在两个 Scheduler 实例。比如自己又 new 了一个SchedulerFactoryBean，或者部分代码通过StdSchedulerFactory.getDefaultScheduler()拿到的调度器和 Spring 容器里被@Autowired拿到的不是同一个对象。修改操作作用于 A 实例，B 实例还在用旧缓存。

排查方法：在所有操作地方打印scheduler.getSchedulerName()和scheduler.hashCode()，确认是不是同一个。这个问题在微服务单测里特别容易踩，很多人直接SchedulerFactory.getDefaultScheduler()去测试，然后发现生产环境不生效。

另外一个坑：如果 JobDetail 是storeDurably(true)且尚未绑定 Trigger，就调用rescheduleJob，Quartz 会直接抛错。总是先确认任务已存在并有关联 Trigger，再执行更新逻辑。

6.5 线程池耗尽导致任务大面积延迟

现象：平时准时的任务突然大面积延迟执行，日志出现类似ThreadPool is not available或者任务排队时间暴涨的记录。

Quartz 默认线程池只有 10 个线程。当任务里出现慢 SQL、远程调用超时、死循环等情况时，线程很快被占满，后续触发器只能等待。如果等待时间超过了misfireThreshold（默认 60 秒），任务就会被标记为 misfire，并按 misfire 策略补偿执行。

处理思路有两个方向。一个是治标的：调大org.quartz.threadPool.threadCount，比如从 10 调成 20 或 50，同时监控任务平均执行时长。另一个是治本的：给 Job 内部加重试超时控制，尤其不要让远程调用长时间阻塞；对耗时任务，考虑拆成多个子任务，或者用线程池隔离。

Quartz 的 misfire 策略也很关键。CronTrigger 的默认策略是MISFIRE_INSTRUCTION_FIRE_ONCE_NOW，也就是错过一次后会立即补偿执行一次。如果你希望任务错过就跳过，不再补偿，需要显式设置：

CronScheduleBuilder schedule = CronScheduleBuilder.cronSchedule("0 0 2 * * ?") .withMisfireHandlingInstructionIgnoreMisfires();

这个设置在“每日跑批”这类任务上非常重要。错过 2 点的调度，如果 3 点才被触发，默认策略会立即跑一次，但对“每天凌晨汇总昨天数据”的业务来说，3 点补跑昨天的任务可能把当天数据也卷进去，反而造成脏数据。显式忽略 misfire 反而更符合预期。

6.6 数据库连接池被 Quartz 撑爆

JDBC 模式下一个容易被忽视的点是：Quartz 需要从数据源获取连接来读写 QRTZ 表，同时业务代码也在用同一个数据源。高并发场景下，Quartz 的调度线程和业务线程会争抢数据库连接。

有一次压测时，业务线程正常，Quartz 集群节点的健康检查接口却大面积报超时，查连接池监控发现QRTZ_LOCKS锁等待把连接占住了。解决办法是给 Quarkz 配置独立数据源，不要让调度连接池和业务连接池混在一起。Spring Boot 里可以单独建一个DataSource，在 Quartz 配置里通过factory.setDataSource(quartzDataSource)指定。

不过大部分中小系统不需要走这一步，项目初期共用一个数据源问题不大，但要在架构设计时留好这个口子，别等出故障了再改配置。

我个人在实际排查这类问题时的体会是：Quartz 本身是一个非常成熟的调度组件，绝大多数线上问题其实出在我们对它的默认行为不够了解。比如默认允许并发、默认补偿 misfire、默认线程数只有 10、默认用系统时区，这些“默认”在和真实业务逻辑碰撞后，才会演变成诡异的生产事故。看日志解决不了问题时，先回去把这几个默认值检查一遍，往往比翻代码更快。最后再提一个小技巧：本地调试时把spring.quartz.job-store-type从jdbc临时改成memory，可以绕开一堆数据库锁问题和表结构干扰；等项目稳定了，再切回 JDBC 做一次全链路验证。这个切换成本很低，却能帮你快速定位问题到底出在调度器本身，还是出在任务持久化的数据环节。