今天為大家帶來的是@Scheduled和Quartz對比分析：
新手常見困惑：
剛學SpringBoot時，我發現用@Scheduled寫定時任務特別簡單。但當我看到同事在項目裏用Quartz時，代碼突然變得複雜起來——為什麼要用這些複雜的配置？難道註解不香嗎？
今天，我們就用最直白的方式，手把手對比這兩種方案。
1. 定位與設計目標
1.1. @Scheduled註解
- 輕量級單機調度：Spring框架原生支持的簡單定時任務工具，無需引入額外依賴。
- 場景適用：適用於單應用實例、無需複雜調度邏輯的定時任務（如數據清理、緩存刷新）。
- 設計核心：基於內存的任務調度，依賴Spring容器生命週期管理。
1.2. 定時任務框架（如Quartz、XXL-JOB）
- 企業級調度平台：面向分佈式、高可用、複雜調度需求的場景（如任務分片、失敗重試、依賴管理）。
- 核心能力：支持任務持久化、集羣部署、動態配置、監控報警等生產級功能。
- 擴展性：提供插件機制、任務管理界面（如XXL-JOB的Admin控制枱）。
2. 特性對比
| 特性 | @Scheduled | 定時任務框架（以Quartz為例） |
|---|---|---|
| 任務持久化 | ❌ 任務信息僅存於內存 | ✅ 支持數據庫持久化，任務可恢復 |
| 分佈式調度 | ❌ 單機運行，多實例會重複執行 | ✅ 集羣環境下任務互斥，避免重複執行 |
| 動態調整任務 | ❌ 需重啓應用修改配置 | ✅ 支持運行時動態修改觸發規則 |
| 失敗重試機制 | ❌ 默認無重試 | ✅ 支持自定義重試策略和次數 |
| 任務分片 | ❌ 不支持 | ✅ 支持任務分片執行（如Elastic Job） |
| 任務依賴管理 | ❌ 不支持 | ✅ 支持任務鏈式或DAG依賴調度 |
| 監控與管理界面 | ❌ 無 | ✅ 提供Web控制枱（如XXL-JOB） |
| Cron表達式靈活性 | ✅ 支持標準Cron | ✅ 支持擴展Cron（如Quartz的秒級精度） |
| 任務執行線程池 | ✅ 可自定義TaskScheduler | ✅ 提供線程池配置和任務隊列管理 |
3. cheduled
3.1. 基礎用法
場景：每天凌晨3點清理臨時文件
步驟：
1.在SpringBoot啓動類加@EnableScheduling
@SpringBootApplication
@EnableScheduling // 關鍵！開啓定時任務支持
public class MyApp {
public static void main(String[] args) {
SpringApplication.run(MyApp.class, args);
}
}
在Bean中寫任務方法
@Component
public class CleanTempFileJob {
// 最簡單的固定間隔執行
@Scheduled(fixedRate = 5000) // 每5秒執行一次
public void cleanCache() {
System.out.println("正在清理臨時文件..." + new Date());
}
// Cron表達式控制複雜時間
@Scheduled(cron = "0 0 3 * * ?") // 每天3點執行
public void dailyClean() {
// 業務邏輯...
}
}
優點：
✅ 開發快，5行代碼就能跑起來
✅ 無需引入額外依賴
✅ 適合快速驗證想法
3.2. 致命缺陷
場景升級：
當項目部署到兩台服務器時，你突然發現——明明只該執行一次的任務，兩個節點同時跑起來了！這就是單機方案的致命缺陷。
問題總結：
| 場景 | 現象 | 根本原因 |
|---|---|---|
| 多實例部署 | 重複執行 | 無集羣協調機制 |
| 任務執行時間過長 | 其他定時任務被延遲 | 默認單線程執行 |
| 服務器重啓 | 未完成的任務不會自動恢復 | 無持久化機制 |
舉個真實案例：
// 統計每日訂單量的任務
@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演示）
# 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. 本質區別
| 對比維度 | @Scheduled | Quartz |
|---|---|---|
| 學習成本 | 5分鐘入門 | 需要理解Job/Trigger等概念 |
| 多節點執行 | 所有節點同時執行 | 同一任務集羣中只執行一次 |
| 任務中斷恢復 | 不支持 | 支持自動恢復未完成任務 |
| 任務執行時間 | 單線程，長任務會阻塞其他任務 | 線程池隔離，任務互相獨立 |
| 動態調整 | 需重啓應用 | 可通過API動態修改調度策略 |
| 適用場景 | 單機簡單任務 | 分佈式環境、需要可靠性的任務 |
6. Q&A
6.1. 我該什麼時候切換用Quartz？
當遇到以下情況時：
- 需要部署多個服務實例
- 任務執行超過30秒可能影響其他任務
- 老闆要求不能因為服務器重啓丟任務
6.2. Quartz配置好麻煩，有簡化方案嗎？
試試用@PersistJobDataAfterExecution註解：
@PersistJobDataAfterExecution // 自動持久化任務數據
@DisallowConcurrentExecution // 禁止併發執行
public class SafeJob extends QuartzJobBean {
// ...
}
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. 總結
記住這個選擇口訣：
單機簡單用註解，
多節點上Quartz。
若是任務要可靠，
持久化配置不能少。
