1. 三种定时任务方案到底在选什么先说结论定时任务从来不只是“定时执行一段代码”那么简单。真正拉开差距的是任务要不要支持动态修改、要不要分布式部署、执行失败怎么办、要不要可视化管理。你把这个问题想清楚了选型就完成了一大半。我做后端开发这几年Scheduled、Quartz、XXL-Job三种方案都实战过也见过不少人一上来就上 XXL-Job结果小项目维护成本比任务本身还高也见过团队死守 Scheduled到了需要动态调整任务周期时只能改代码发版。这几种方案没有绝对的好坏关键是看你的业务处在什么阶段、有没有分布式诉求、团队有没有精力维护调度平台。先给一个直观的定位ScheduledSpring 生态自带零依赖适合单机、简单周期任务。Quartz老牌调度框架功能全面支持集群但配置复杂适合中等复杂度、要 Cron 表达式 持久化的场景。XXL-Job分布式任务调度平台自带管理界面、动态修改、失败重试、日志追踪适合微服务、集群、需要运维友好的场景。后面我直接按照“先理解思路再上手实操最后避坑”的顺序展开每个环节都会结合实例说明。2. 三种方案的核心机制与适用边界2.1 Scheduled轻量到“没有任何存在感”如果你用过 Spring Boot对下面这段代码一定不陌生Component public class TaskService { Scheduled(cron 0 0 2 * * ?) public void dailyReport() { // 每天凌晨2点执行报表生成 } }Scheduled 本质是 Spring 容器帮你注册了一个定时器底层默认用的是 JDK 的 ScheduledExecutorService。单机环境下定时任务不需要动态调整、不需要持久化、没有复杂的调度依赖它就是最好的选择。因为代码量少、调试方便、没有额外学习成本。但它有几个天生的限制很多人踩了坑才知道默认单线程执行。你写了多个 Scheduled 方法默认情况下它们是排在一个线程池里串行跑的。如果一个任务阻塞了其他任务全卡住。这个问题我后面在避坑部分细讲。Cron 表达式写死在代码里。想改执行周期就得改代码、重新发版。对于业务方频繁调整时间的场景这基本不可接受。没有失败重试。任务抛异常日志里记一下就结束了没有重试机制也不会有告警。多实例部署时任务会重复执行。同一个服务如果起了多个实例定时任务会在每个实例上都跑一遍如果没有幂等处理效果就是任务被重复执行。上面这第四条其实就是热搜里那个“RedisTemplate分布式锁定时任务重复执行”的来源。这个问题在后面的实操部分我会单独拆解。2.2 Quartz功能全但也是有代价的“成熟”Quartz 是 Java 生态里历史最悠久的调度框架之一很多重量级系统内部都在用它。它的核心概念有几个Job任务逻辑、Trigger触发器、Scheduler调度器、JobDetail任务描述。触发器支持 Cron 表达式和 SimpleTrigger 等多种模式还支持任务持久化到数据库。Quartz 比 Scheduled 强在哪里Cron 表达式支持得更完善。Scheduled 也支持 Cron但 Quartz 的 Cron 是真正意义上到秒级的调度语法和校验都更严格。任务可持久化。任务配置存在数据库里应用重启后任务不会丢。支持集群模式。通过数据库表锁机制多个节点同时运行 Quartz 时同一个任务只会被一个节点触发。这个能力很重要但它有代价需要额外建 11 张表、集群节点时间要同步否则锁判断会出错、故障恢复机制比较薄节点挂了之后任务可能不会被自动转移。实际用下来Quartz 最难受的地方在于它只是一个调度框架没有管理界面。任务在哪个节点上跑的上次执行成功没有想手动触发一次这些全都要自己想办法。这也是后来 XXL-Job 这类调度平台火爆的核心原因。不过 Quartz 也不是没有优势。如果你的系统已经足够复杂就差一个可靠的本地调度内核而且团队没有精力运维一个独立调度中心Quartz 单机模式作为应用内嵌的调度组件其实是性价比很高的。2.3 XXL-Job是调度中心不是“库”也不是“表”XXL-Job 是大众点评开源出来的分布式任务调度平台。它和 Quartz 最大的理念差异在于Quartz 是一个框架而 XXL-Job 是一个平台。它自带 Web 管理界面你可以通过界面做这些事情新增/修改/删除任务修改后立即生效不用发版。手动触发一次任务方便测试。查看每个任务的历史执行记录包括成功、失败、耗时。执行日志在线查看不用登服务器翻日志文件。失败任务自动重试可配置重试次数。路由策略选择轮询、分片广播、故障转移、一致性哈希等。XXL-Job 的架构分两部分调度中心admin和执行器executor。调度中心独立部署负责任务调度和调度管理执行器就是你的业务服务引入 XXL-Job 的 SDK注册到调度中心当调度中心下发任务时执行器在本进程内执行任务代码。调度中心通过 HTTP 接口与执行器通信业务服务不需要公网暴露端口也是走内网 HTTP。从部署方式来说XXL-Job 算是微服务架构里最省心的分布式定时任务方案之一。它不强依赖数据库的锁机制来防止重复执行而是在调度层面通过“分片广播 执行器注册管理”来控制。比如任务配置为“分片广播”调度中心会调用所有注册的 executor每个 executor 拿到自己的分片序号和总分片数通过取模等方式实现数据切片处理。这样不仅避免了重复执行还能加速执行效率一举两得。3. 实操对比三套方案分别怎么写3.1 Scheduled 的启动姿势与默认陷阱依赖方面用 Spring Boot 时 Scheduled 不需要额外引入包只要在启动类加一个注解SpringBootApplication EnableScheduling public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }任务类长这样Component public class ReportTask { private static final Logger log LoggerFactory.getLogger(ReportTask.class); // 每天 2:30 执行 Scheduled(cron 0 30 2 * * ?) public void generateReport() { log.info(生成日报任务开始); // 业务逻辑 } }在这里必须强调一个关键点Spring 默认的定时任务线程池只有一个线程。这点很多人不知道直到线上出现任务相互阻塞才反应过来。我建议在项目里显式配置一个线程池避免默认行为坑人Configuration public class SchedulingConfig implements SchedulingConfigurer { Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(10)); } }这个线程池的大小怎么定没有统一标准我的经验是核心线程数 你任务中需要并发执行的最大任务数的 2 倍但建议最小不少于 4最大不必超过 20。线程太多也就是空占内存定时任务不是高并发接口没必要堆线程。另外Scheduled 还有一种 fixedRate 模式容易踩坑的是它的执行机制Scheduled(fixedRate 5000) public void run() { System.out.println(任务执行 System.currentTimeMillis()); // 模拟执行耗时 3 秒 Thread.sleep(3000); }fixedRate 5000 的意思是“每隔 5 秒触发一次不管上一个任务是否执行完”。对于单线程默认配置Spring 的实现方式是上一个任务结束并等待到下一个时间点再执行。如果任务执行时间超过 5 秒实际执行频率会变成任务结束后的 5 秒而不是理论上的 5 秒一次。如果你想严格避免任务重入建议在方法上加分布式锁或使用队列限流。这个“任务执行时长 调度周期”的问题是很多生产事故的来源最好在任务设计阶段就考虑清楚。3.2 Quartz 的三张表和三种触发器使用 Quartz 需要引入依赖Spring Boot 也提供了官方 starterdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-quartz/artifactId /dependency如果使用数据库持久化在配置文件里设置spring: quartz: job-store-type: jdbc jdbc: initialize-schema: always首次启动会自动建表。Quartz 的表结构初看挺唬人其实核心就三张表作用QRTZ_JOB_DETAILS存任务基本信息比如 Job 类名、任务名、是否持久化QRTZ_TRIGGERS存触发器信息比如任务对应哪个触发器、触发器状态QRTZ_CRON_TRIGGERS存 Cron 表达式本身的配置剩余的表是辅助的比如暂停状态、锁记录、日历配置等。理解这三张主表就能理解 Quartz 持久化的本质任务配置存库应用启动时从库里读任务按触发器规则执行。写一个最简单的 Quartz 任务和触发器// 1. 定义一个 Job public class SimpleJob implements Job { Override public void execute(JobExecutionContext context) { System.out.println(Quartz 任务执行); } } // 2. 在配置类里创建 JobDetail 和 Trigger Configuration public class QuartzConfig { Bean public JobDetail simpleJobDetail() { return JobBuilder.newJob(SimpleJob.class) .withIdentity(simpleJob) .storeDurably() .build(); } Bean public Trigger simpleJobTrigger() { CronScheduleBuilder cronBuilder CronScheduleBuilder.cronSchedule(0 0/5 * * * ?); return TriggerBuilder.newTrigger() .forJob(simpleJobDetail()) .withIdentity(simpleJobTrigger) .withSchedule(cronBuilder) .build(); } }Quartz 的 Trigger 类型有三种CronTrigger按 Cron 表达式执行最常用。SimpleTrigger按固定间隔执行类似 Scheduled 的 fixedRate。DailyTimeIntervalTrigger按每天的时间段和间隔执行适合“每天早九点到晚六点每半小时一次”这种需求。选择原则很简单能用 Cron 表达的就用 CronTrigger表达不了再考虑另两种。Quartz 集群模式配置也简单但要理解它的机制多个 Quartz 节点共享一张数据库调度时通过数据库锁QRTZ_LOCKS 表抢占任务谁抢到锁谁执行。这个机制会导致两个坑一是数据库成为性能瓶颈调度频率很高时不推荐二是集群中某个节点挂了它的任务不会自动迁移除非你配置了故障转移并重启调度器。3.3 XXL-Job 的搭建与接入全流程XXL-Job 分为调度中心admin和执行器executor我分别说。调度中心搭建在 GitHub 下载 XXL-Job 源码找到 xxl-job-admin 模块它是一个独立的 Spring Boot 应用。导入数据库脚本 tables_xxl_job.sql修改 application.properties 里的数据库连接MySQL 或 PostgreSQL 均可然后启动项目访问http://localhost:8080/xxl-job-admin默认账号 admin / 123456。这里有一个容易踩的细节XXL-Job 调度中心默认端口是 8080如果和业务服务冲突记得改。另外调度中心本身是无状态的可以多节点部署并用 Nginx 做负载均衡但要注意多节点调度中心需要共享同一个数据库相当于在数据库层做状态同步。执行器接入在业务服务的 pom.xml 引入dependency groupIdcom.xuxueli/groupId artifactIdxxl-job-core/artifactId version2.4.0/version /dependency在 application.yml 里配置xxl: job: admin: addresses: http://localhost:8080/xxl-job-admin accessToken: default_token executor: appname: report-service address: ip: port: 9999 logpath: /data/logs/xxl-job logretentiondays: 30然后在业务代码里加一个配置类创建 XxlJobSpringExecutor 实例Configuration public class XxlJobConfig { Value(${xxl.job.admin.addresses}) private String adminAddresses; Value(${xxl.job.accessToken}) private String accessToken; Value(${xxl.job.executor.appname}) private String appname; Value(${xxl.job.executor.port}) private int port; Bean public XxlJobSpringExecutor xxlJobExecutor() { XxlJobSpringExecutor executor new XxlJobSpringExecutor(); executor.setAdminAddresses(adminAddresses); executor.setAccessToken(accessToken); executor.setAppname(appname); executor.setPort(port); return executor; } }任务类写法如下Component public class ReportJobHandler { XxlJob(reportJob) public void reportJob() throws Exception { XxlJobHelper.log(报表任务开始执行); // 业务逻辑 XxlJobHelper.log(报表任务执行完成); XxlJobHelper.handleSuccess(报表生成成功); } }核心就一个注解 XxlJob(任务名称)这个名称要和调度中心后台创建任务时填写的“JobHandler”一致否则调度中心找不到执行器里的对应方法。4. 分布式定时任务重复执行的实战解法4.1 重复执行问题先判断根因回到热搜里的高频词“redistemplate分布式锁定时任务重复执行”。多实例部署时每个实例都会执行 Scheduled 任务所以重复执行是必然的不是你代码写错了是架构没有处理。我的处理思路分三步走能不能不做定时任务有些“定时任务”其实是数据更新类操作可以考虑用消息队列的延迟消息替代。比如下单 30 分钟未支付自动取消这种可以用 RocketMQ 的延迟消息而不是写一个定时扫描任务。能不能接受短时间重复执行如果任务执行结果是幂等的比如“同步状态字段为已过期”重复执行也无所谓那就不需要加锁。必须要实时保证只有一个实例执行那就引入分布式锁把任务竞争控制在锁层面。4.2 RedisTemplate 实现分布式锁的完整姿势基于 Redis 实现分布式锁核心靠 SETNXSET if Not eXists命令。下面是一个比较成熟的模板代码Service public class DistributedLockService { Autowired private StringRedisTemplate redisTemplate; /** * 尝试获取锁 * * param lockKey 锁的 key * param requestId 请求标识保证释放锁时只能释放自己的锁 * param expireTime 锁自动过期时间单位秒 */ public boolean tryLock(String lockKey, String requestId, long expireTime) { Boolean result redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(expireTime)); return Boolean.TRUE.equals(result); } /** * 释放锁使用 Lua 脚本保证比较和删除是原子操作 */ public boolean releaseLock(String lockKey, String requestId) { String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId); return Long.valueOf(1).equals(result); } }这里有两个细节值得单独讲第一requestId必须是每个线程唯一的。常见做法是生成 UUID。释放锁之前先比较 requestId是为了防止“锁过期了但线程 A 还在执行线程 B 拿到了锁此时线程 A 执行完去释放锁会把线程 B 的锁删掉”。这个低级错误在现实里特别常见很多人释放锁时直接redisTemplate.delete(lockKey)等于埋了个大坑。第二锁的过期时间设多长设短了任务还没执行完锁就自动过期别的实例抢先拿到锁造成并发设长了如果持有锁的实例挂了锁要在很长一段时间后才自动释放业务延迟大。我的经验是先估算任务的最长执行时间设为该时间的 3~5 倍。比如任务正常情况下 2 秒跑完最坏情况 10 秒那过期时间设 30 秒。4.3 锁续期与自旋Redis 锁的进阶坑上面的方案有一个隐患如果任务执行时间超过了锁的过期时间锁被 Redis 自动删了其他节点还是会趁机执行任务。要彻底解决需要实现“锁续期”机制在任务执行过程中每隔一段时间检测任务是否还在运行如果还在运行就刷新锁的过期时间。这个机制业界叫 watchdog看门狗Redisson 库内置了这个能力。如果你不想引入 Redisson自己实现也很简单private void watchDog(String lockKey, String requestId, long expireTime) { ScheduledExecutorService scheduler Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(() - { // 每 expireTime/3 秒续期一次 if (existsLock(lockKey, requestId)) { redisTemplate.expire(lockKey, expireTime, TimeUnit.SECONDS); } }, expireTime / 3, expireTime / 3, TimeUnit.SECONDS); }注意看门狗线程不能无限跑任务执行完要立刻关掉。更优雅的做法是用 Redisson 的 tryLock 方法它的核心实现就是如果你的业务逻辑执行时间超过了锁的 leaseTime看门狗会自动续期直到业务执行完再释放锁。所以我的建议是如果项目已经用了 Redisson直接用 RedissonLock 而不是自己造轮子如果只是零星两个定时任务用上面的模板代码更轻量。说到底分布式锁只是“防御手段”最好的方案是在架构层面规避。以我个人的经验大部分定时任务可以设计成“幂等 数据校验”比如任务执行前先查一下目标数据的状态如果已经是处理过的状态就直接跳过这样即使重复执行也不会产生脏数据。5. 选型建议场景驱动而不是技术驱动5.1 选型四步判断法下面分享我用的一套选型判断决策流程帮你在面对具体业务场景时快速做决定第一步确认容错要求如果业务允许“偶尔漏执行、允许手工补数据”那就选最简单的方式。报表统计、数据同步之类的任务往往是这种模式。反之如果漏执行会带来资损或者严重客诉就需要一个具备失败重试、告警监控能力的方案。第二步确认部署架构服务是单机部署还是多实例集群单机部署用 Scheduled 就够了。如果已经是集群就需要考虑分布式锁、或者直接换成支持分布式调度的 XXL-Job。这里有个容易忽略的点即便是集群部署如果只有个别任务需要分布式调度保障也不需要全量切换平台。第三步确认任务是否需要动态调整业务方经常调整任务时间吗是否希望非技术人员也能修改任务配置如果是直接选带管理界面的 XXL-Job省去一堆沟通和发版成本。第四步确认团队运维精力团队有没有多余的人力去维护调度中心XXL-Job 本身也是要单独部署、升级、监控的如果团队的精力只够维护业务应用那优先考虑 Scheduled 或 Quartz不要为了“看起来高级”选一个自己养不起的组件。5.2 一张表看清三个方案的核心差异下面是我自己整理的一个速查表供参考维度ScheduledQuartzXXL-Job依赖Spring 内置零依赖需引入 quartz 依赖需要搭建调度中心使用复杂度最简单中等中等偏上Cron 表达式支持支持支持任务持久化不支持支持数据库表支持数据库表动态修改任务不支持需改代码需配合 API 修改后台界面直接改失败重试无需自己实现自带重试分布式部署重复执行需加锁支持集群靠数据库锁原生支持路由策略丰富监控告警无无自带执行日志和告警运维成本最低中等中等偏上适合场景单机简单任务单机复杂调度分布式、微服务场景5.3 Spring Cloud 微服务架构下的推荐组合在微服务架构下我的建议是用 XXL-Job 做全局调度中心业务任务以 XxlJob 的方式接入。这不是因为它最“高级”而是因为你一旦有多个服务、每个服务都有定时任务总不能每个服务自己管理一套任务配置。到时候你光找“这个任务在哪个服务上、改时间要去哪个项目发版”就能混乱到崩溃。但也不是所有任务都要搬到 XXL-Job 上。我实际项目中的组合是全局性的数据同步任务用 XXL-Job 统一管理。单个服务内部的短周期任务比如每 5 分钟清理一次本地缓存这种任务用 Scheduled 就够了没必要让调度中心管。6. 常见问题与排查技巧实录6.1 Scheduled 任务突然不执行或延迟现象开发环境跑得好好的上了生产任务到点不执行或者明显延迟。排查思路检查应用日志里有没有定时任务执行记录的线程名称。默认线程名是scheduling-1如果你在日志里看到任务用其他线程执行那说明可能被业务代码手动调用过。检查线程池是否被耗尽。如果配置了 ScheduledThreadPool 且线程数很小而任务执行时间又长可能线程都卡在某个任务里。检查是否开启了EnableScheduling。漏掉这个注解任务不会执行这个问题看似低级但确实很容易忽略。6.2 Quartz 集群下任务被重复执行现象Quartz 配置了集群但同一个任务还是被多个节点触发。排查思路确认所有节点的spring.quartz.properties.org.quartz.jobStore.isClusteredtrue已配置。确认集群节点的时间是否一致。Quartz 集群靠时间戳判断锁的持有状态如果节点时间不同步锁判断就会出错。用 NTP 同步所有节点的系统时间是标准姿势。确认QRTZ_LOCKS表没有被误删或锁记录锁死。6.3 XXL-Job 任务明明配置了却一直不执行现象调度中心后台任务状态是“运行中”但执行器没收到任务。排查思路看调度中心的调度日志如果报“执行器地址为空”说明执行器没注册上。检查执行器配置的 appname 是否和后台一致。看执行器日志如果启动时报 xxl-job 地址连接失败检查 admin addresses 配置是否正确、防火墙有没有放开端口。检查 accessToken 是否一致。很多企业会改调度中心的 accessToken如果你业务服务的配置没同步会被鉴权拦截。这里分享一个我踩过的实际坑XXL-Job 执行器端口默认是 9999但服务部署在容器里时如果容器只暴露了业务端口比如 8080没暴露 9999调度中心发起的 HTTP 回调就会超时表面看任务没执行其实就是端口不通。解决方案是让执行器端口和业务端口一致或者用同一个端口提供服务。6.4 分布式锁获取失败时任务到底要不要执行这是一个很多人没想清楚的问题。获取不到分布式锁说明其他实例正在执行任务那么当前实例正确的做法是直接放弃本次执行而不是重试等待。错误写法Scheduled(cron 0 0 2 * * ?) public void task() { while (!distributedLockService.tryLock(key, requestId, expireTime)) { // 死循环等待锁 } // 执行任务 }正确写法Scheduled(cron 0 0 2 * * ?) public void task() { String requestId UUID.randomUUID().toString(); boolean locked distributedLockService.tryLock(lockKey, requestId, 30); if (!locked) { log.info(获取锁失败本实例跳过本次执行); return; } try { // 执行业务逻辑 } finally { distributedLockService.releaseLock(lockKey, requestId); } }为什么不用while循环等锁因为调度中心或Spring已经保证了任务在指定时间点触发。如果锁被其他实例持有说明别人正在处理当前实例等待没有意义直接跳过反而能避免任务堆积。等下一个调度周期到了再尝试获取锁就好了。这个思路配合 XXL-Job 的“分片广播 日志追踪”可以非常清晰地看到每一次调度的执行情况。最后再分享一个小技巧不管用哪种方案给定时任务加一个“执行记录表”。每次任务触发时记录开始时间、结束时间、执行结果、耗时。排查问题时这张表能救你命。你可以把它做成公共组件也可以用 AOP 切面统一记录成本很低收益极高。定时任务这东西线上环境不可控因素太多了能留下痕迹就尽量留下痕迹。