SpringBoot @Scheduled 与 Quartz 对比：分布式定时任务选型实战

3.1. 基础用法

场景：每天凌晨 3 点清理临时文件。

首先需要在启动类上添加 @EnableScheduling 注解来开启定时任务支持：

@SpringBootApplication
@EnableScheduling // 关键！开启定时任务支持
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

接着在 Bean 中定义任务方法。这里展示了两种常见的触发方式：

@Component
public class CleanTempFileJob {
    // 最简单的固定间隔执行，每 5 秒执行一次
    @Scheduled(fixedRate = 5000)
    public void cleanCache() {
        System.out.println("正在清理临时文件..." + new Date());
    }

    // Cron 表达式控制复杂时间，每天 3 点执行
    @Scheduled(cron = "0 0 3 * * ?")
    public void dailyClean() {
        // 业务逻辑...
    }
}

优点： ✅ 开发快，几行代码就能跑起来 ✅ 无需引入额外依赖 ✅ 适合快速验证想法

3.2. 致命缺陷

当项目部署到两台服务器时，问题就来了——明明只该执行一次的任务，两个节点同时跑起来了！这就是单机方案的致命缺陷。

主要问题总结：

举个真实案例：统计每日订单量的任务如果耗时较长，会阻塞后续所有 @Scheduled 任务。

// 统计每日订单量的任务
@Scheduled(cron = "0 0 1 * * ?")
public void countDailyOrders() {
    // 执行时间长达 10 分钟
    heavyDatabaseOperation();
}

当这个任务运行时，其他所有 @Scheduled 任务都会被阻塞，直到它完成！

4. Quartz：复杂且强大

解决思路：引入专业框架，实现任务持久化、线程池隔离以及集群协调。

实现步骤：

1. 添加依赖

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

2. 配置数据库（这里用 H2 演示，生产环境建议 MySQL/PostgreSQL）

# application.properties
spring.quartz.job-store-type=jdbc
spring.datasource.url=jdbc:h2:mem:testdb
spring.quartz.properties.org.quartz.jobStore.isClustered=true

3. 定义任务逻辑

public class OrderStatJob extends QuartzJobBean {
    @Override
    protected void executeInternal(JobExecutionContext context) {
        // 从 context 获取参数
        System.out.println("执行订单统计：" + new Date());
    }
}

4. 配置触发器

@Configuration
public class QuartzConfig {
    @Bean
    public JobDetail orderStatJobDetail() {
        return JobBuilder.newJob(OrderStatJob.class)
                .withIdentity("orderStatJob") // 任务唯一标识
                .storeDurably()
                .build();
    }

    @Bean
    public Trigger orderStatTrigger() {
        return TriggerBuilder.newTrigger()
                .forJob(orderStatJobDetail())
                .withIdentity("orderStatTrigger")
                .withSchedule(CronScheduleBuilder.cronSchedule("0 0 2 * * ?")) // 每天 2 点
                .build();
    }
}

关键改进： ✅ 任务信息存数据库，重启后自动恢复 ✅ 默认线程池大小 10，任务并行执行 ✅ 集群部署时通过数据库锁避免重复执行

5. 本质区别

6. Q&A

6.1. 我该什么时候切换用 Quartz？

当遇到以下情况时：

• 需要部署多个服务实例
• 任务执行超过 30 秒可能影响其他任务
• 要求不能因为服务器重启丢任务

6.2. Quartz 配置好麻烦，有简化方案吗？

试试使用相关注解优化：

@PersistJobDataAfterExecution // 自动持久化任务数据
@DisallowConcurrentExecution // 禁止并发执行
public class SafeJob extends QuartzJobBean {
    // ...
}

6.3. 听说还有 XXL-JOB，我需要学吗？

如果你的项目已经分布式部署，且需要：

• 可视化的任务管理界面
• 自动分片处理大数据量任务
• 实时日志查看 那么 XXL-JOB 更适合，但学习曲线更高。

7. 避坑指南：新手常犯的 3 个错误

7.1. Cron 表达式写错格式

Spring 的 @Scheduled 和 Quartz 的 Cron 略有不同：

• Spring：秒 分 时 日 月 周几
• Quartz：支持秒级精度和更多特殊字符

7.2. 忘记线程池配置

在 @Scheduled 中记得自定义线程池以避免阻塞：

@Bean
public TaskScheduler taskScheduler() {
    return new ThreadPoolTaskScheduler();
}

7.3. 在集群环境混用两种方案

千万不要同时用 @Scheduled 和 Quartz 做同一个任务！这会导致不可预知的重复执行。

8. 总结

选择定时任务框架的核心在于权衡复杂度与可靠性。对于单机环境下的简单维护任务，@Scheduled 足够轻便高效；一旦涉及分布式部署、任务持久化或高可用性要求，Quartz 则是更稳妥的生产级选择。根据实际业务规模和技术栈特点进行选型，才能确保系统稳定运行。