企业官网建设流程全解析

做Java开发这些年，经常遇到一类需求：每隔几分钟同步一次数据、每天凌晨清理过期的token、每月1号生成上个月的报表，这类“按固定规则重复触发”的动作，就是典型的定期事件。很多新手第一反应是new一个Thread然后while(true)循环里sleep，跑测试的时候看着没问题，一上线就各种崩溃、重复执行、不执行。这篇文章就围绕“用Java怎么把定期事件管好”这件事，把自带的调度器、Spring注解、重型框架、分布式场景逐层讲清楚，并结合我实际踩过的坑，给出一套可以直接落地的选型思路。

1. 先搞清楚“定期事件”到底有几种类型，否则后面全是坑

1.1 三种触发模式：固定速率、固定延迟、日历驱动

在选技术方案之前，先要把业务需求翻译成调度语义。我见过太多人把三种模式混为一谈，导致任务行为完全偏离预期。

第一种是固定速率（fixed rate），意思是“每隔5分钟触发一次”，它只关心两次开始时间之间的间隔。比如你8点00分启动，那么8点05、8点10、8点15都会各触发一次，不管上一次任务跑了多久。适合用在“必须按时产生结果”的场景，比如监控心跳上报。

第二种是固定延迟（fixed delay），意思是“上次任务结束后过5分钟再跑下一次”。如果任务执行了3分钟，下一次触发就在第8分钟；如果任务执行了10分钟，下一次就在第15分钟。它保证任务不会并发叠加，适合批处理、数据同步这种“不能同时跑两份”的场景。

第三种是日历驱动（calendar-based），典型就是Cron表达式：“每天凌晨2点”“每周一9点”“每月1号”。它跟“每隔多久”无关，只跟日历上的时间点有关。报表生成、日志清理基本都是这类。

这三者的核心区别在于：固定速率是按照墙上时钟切分的，固定延迟是按照任务结束时间推进的，日历驱动是按照日历规则匹配的。如果你把固定速率的任务做成固定延迟，高峰期可能出现任务积压；反过来如果业务要求每次都重新计时，你用了固定速率，任务执行时间一长，下一次就可能和上一次重叠。

1.2 一个“时间管理”需求对应的Java生态演进

从Java本身的演进看，定期事件的处理经历了三代变化：最早是Timer/TimerTask，然后是ScheduledExecutorService，再到Spring的@Scheduled和Quartz这类框架。三代方案不是替代关系，而是适用边界不同。理解这条演进线，你就能判断什么场景该用哪个，而不是一头扎进某个框架里。

后面几个章节我会逐个拆解，你会发现一个问题：所有语言层面的调度方案都是基于“单机、进程存活、时间准”这三个假设的。一旦你的应用跑多实例，或者任务执行时间超过周期，或者机器重启，方案就要升级。这一点是做技术选型时最容易忽略的。

2. Java自带的调度器：能用，但别随便用到生产环境

2.1 Timer/TimerTask：教科书里的方案，生产中要绕开

Timer是Java 1.3就有的调度器，用法很简单：

Timer timer = new Timer("clean-expired-token"); timer.schedule(new TimerTask() { @Override public void run() { // 清理过期token的业务逻辑 } }, 0, TimeUnit.MINUTES.toMillis(30));

这段代码的意思就是延迟0毫秒启动，之后每30分钟执行一次。如果你要做倒计时（延迟执行一次），timer.schedule(task, delay)就够了。

但Timer有两个非常致命的设计缺陷。第一，它内部只有一个工作线程，所有注册到同一个Timer上的任务都是排队执行的，只要有一个任务执行时间过长，后面的任务全部延期。第二，任何一个任务抛出未捕获异常，整个工作线程会直接终止，这个Timer就废了，其他任务也永远不跑了。

我见过一个真实事故：有人用Timer去做多个定时任务，其中一个任务偶发数据库连接超时，异常一抛，整个Timer线程死掉，剩下的任务全部静默停止，业务方过了三天才发现日报没生成。所以用Timer写生产代码，等于把一个定时炸弹放在代码里。

2.2 ScheduledExecutorService：线程池化之后的正确姿势

JUC包里的ScheduledExecutorService解决了Timer的单线程问题。它本质上是ThreadPoolExecutor的扩展，核心调度逻辑是基于延迟队列实现的，注册的任务会被封装成ScheduledFutureTask，按触发时间排序后进队列，工作线程到了时间就取出来执行。因为支持多线程，即使一个任务执行超时或抛异常，其他任务也不受影响。

基础用法：

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2); // 固定速率：每5分钟执行一次，按启动时刻计算 scheduler.scheduleAtFixedRate(() -> { collectMetrics(); }, 0, 5, TimeUnit.MINUTES); // 固定延迟：上次执行结束后再过10分钟执行 scheduler.scheduleWithFixedDelay(() -> { syncOrderData(); }, 0, 10, TimeUnit.MINUTES);

这两个方法的差异非常重要，直接对应1.1节说的两种模式。scheduleAtFixedRate是按照理想开始时间安排下一次任务，如果执行时间超过了周期，线程池里的线程会被占满，新任务立刻开始，就出现重叠；scheduleWithFixedDelay则严格等上一次完成后再计时，天然避免重叠。

还有一个隐藏点：ScheduledExecutorService的任务异常不会被打印出来。scheduleAtFixedRate执行的任务如果抛了异常，这个任务的后续执行会被取消，而且异常被吞掉，你只能在日志里看到任务突然没了。所以业务代码里必须自己做好try-catch，最好把异常包装成可控日志输出。

2.3 自带方案的边界：缺Cron、缺持久化、缺分布式协调

ScheduledExecutorService已经是语言层面最好的方案，但它有几个能力盲区。第一，没有Cron表达式，只支持固定速率和固定延迟，做不到“每月1号凌晨3点”这种日历规则，你得自己算下一次执行时间，算起来很繁琐。第二，没有持久化，进程一重启，内存队列里的调度计划全部丢失，任务少可能无所谓，任务一多就必须考虑重启补偿。第三，没有分布式协调，多实例部署时每个节点都会执行同一份任务，重复执行的问题就暴露出来了。

所以我的判断是：如果你只在单机环境跑一个简单的固定间隔任务，用ScheduledExecutorService完全够；一旦需求里出现“按日历规则触发”“任务不能重复执行”“需要记录执行历史”，就该往框架层走了。

3. Spring @Scheduled：业务开发里出镜率最高的方案

3.1 三个基础属性怎么选

如果你的项目已经用了Spring Boot，绝大多数定期事件根本不用自己启动线程池，直接在方法上挂@Scheduled注解即可。启动类或配置类上加@EnableScheduling开启调度能力：

@Configuration @EnableScheduling public class ScheduleConfig { }

然后业务方法：

@Component public class TokenCleanTask { private static final Logger log = LoggerFactory.getLogger(TokenCleanTask.class); // 每天凌晨2点执行 @Scheduled(cron = "0 0 2 * * ?") public void cleanExpiredToken() { log.info("begin clean expired token"); // 业务逻辑 log.info("finish clean expired token"); } // 启动后延迟5秒执行，之后每30分钟一次 @Scheduled(initialDelay = 5000, fixedRate = 1800000) public void syncConfig() { } // 上次执行结束后1小时再执行 @Scheduled(fixedDelayString = "3600000") public void refreshCache() { } }

fixedRate和fixedDelay的语义和2.2节一致，initialDelay用于应用启动后先等一段时间再开始第一个周期，避免启动时和业务初始化冲突。Cron表达式则是日历驱动的核心。

3.2 Cron表达式一句话说透

网上关于Cron的教程很多，但绝大多数把七个字段背一遍完事，没有讲关键。Spring的Cron是六个字段：秒、分、时、日、月、周，顺序是固定的，秒是第一个。

举几个看得懂的例子：

这里有两个极易踩的坑。第一个是“日”和“周”两个字段不能同时设具体值，大多数场景把其中一个写成?，表示“不指定”。第二个是*和?的区别：*表示匹配任意值，?表示“此处不关心、由另一个字段决定”。如果两个字段都写具体值，Spring会直接抛异常，很多人第一次写Cron就是卡在这里。

提示：Cron表达式的解析是基于应用所在JVM的默认时区，不是你代码里写的TimeZone.getDefault()在哪儿，问题就藏在服务器时区和业务时区不一致上，后面第5章专门讲。

3.3 线程模型与并发控制

Spring的@Scheduled任务默认是单线程串行执行的。什么意思？就是所有注解了@Scheduled的方法，在同一个调度线程里排队执行，如果A任务跑了10分钟，B任务即使到点了也得等着。想改成多线程很简单，实现SchedulingConfigurer并自定义TaskScheduler：

@Configuration public class ScheduleConfig implements SchedulingConfigurer { @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler(); scheduler.setPoolSize(8); scheduler.setThreadNamePrefix("scheduled-"); scheduler.initialize(); taskRegistrar.setTaskScheduler(scheduler); } }

线程池调多大不是随便填的。一个粗略的经验：核心线程数 = 所有定时任务里最长执行时间的任务数 + 2，保证长任务不会占完所有线程导致短任务饿死。这一步很多人不配置，等任务一多才发现执行时间漂移。

Spring方案的另一个能力缺口是本实例内并发控制。同一个任务上一次没执行完，下一次又触发了，@Scheduled并不会自动帮你挡住。常见的兜底方案是分布式锁，或者用ReentrantLock配合tryLock，但分布式环境下必须用跨进程的锁，这个在第4章展开。

3.4 什么时候该放弃Spring自带的这套

触发条件其实很清楚：你需要任务的持久化（应用重启后任务不丢失）、失败重试机制、执行历史查询、集群环境下的精确调度，这四样里只要占了两样，@Scheduled就不够用了。它本质上是一个轻量级、无状态、不落库的调度方案，适合固定在代码里、周期相对稳定、不需要动态调整的任务。

4. 分布式场景：单机定时任务在集群里最容易翻车

4.1 问题本质：每个实例都会执行一遍

假设你的订单同步任务用@Scheduled(cron = "0 */5 * * * ?")实现，部署了两个实例，那么每分钟两个实例都会各自执行一次同步逻辑，数据被同步两遍，轻则浪费资源，重则主键冲突、重复扣减、账不平。这不是调度器的bug，而是分布式系统的常态。

要解决“同一个时间点只允许一个实例执行”，核心思想就是“抢锁”。抢到锁的节点执行，没抢到的直接跳过本轮。

4.2 轻量解法：Redis分布式锁 + ShedLock

最朴素的分布式锁解法是Redis的SETNX加过期时间：

Boolean locked = redisTemplate.opsForValue() .setIfAbsent("lock:order-sync", "1", 5, TimeUnit.MINUTES); if (Boolean.TRUE.equals(locked)) { try { syncOrder(); } finally { redisTemplate.delete("lock:order-sync"); } }

这段代码有两个要注意的地方。第一个是必须在拿到锁后设置过期时间，防止持有锁的进程宕机导致死锁。第二个是锁过期时间必须大于任务最长执行时间，否则任务还没跑完锁就自动释放，其他节点就会重新执行，出现并发。

自己写锁很容易出细节问题，所以更推荐直接用ShedLock这个专门做“分布式定时任务锁”的库。它的设计思路是：调度依然由@Scheduled触发，但真正执行前先往数据库或Redis里写一条锁记录，成功获锁才执行，执行完再释放。用起来大致是这样：

@Component public class OrderSyncTask { @Scheduled(cron = "0 */5 * * * ?") @SchedulerLock(name = "orderSync", lockAtMostFor = "4m", lockAtLeastFor = "30s") public void syncOrder() { // 业务逻辑 } }

这里lockAtMostFor表示锁最长持有时间，必须比任务预估最大执行时间略长；lockAtLeastFor表示锁最少持有时间，用来防止两个实例的时钟不同步导致短时间窗口内都被获锁。ShedLock支持数据库和Redis两种存储，单机小规模集群用数据库表就够了。

4.3 成熟框架：XXL-Job的调度中心与执行器模型

如果你连“调度触发、任务管理、执行日志、失败告警、动态修改执行时间”都想做，那就要上真正的分布式调度平台了。目前国内Java生态用得比较多的是XXL-Job，它的模型是调度中心（Admin）负责任务的调度和分配，执行器（Executor）部署在业务服务里接收指令并执行。

这个模型的好处在于：调度职责和执行职责分离，你可以动态调整某个任务的Cron而不用改代码重启服务，也可以在调度中心看到每次执行的成功失败情况、耗时、日志。我用XXL-Job做过一个数据补偿服务，几百个任务靠管理后台统一管理，比全用@Scheduled维护起来省心太多。

4.4 选型指南：什么规模用什么方案

综合前面所有分析，我给一个可以直接用的判断标准：

这一层选型决定了你后面是轻松还是痛苦。我见过不少团队上来就上XXL-Job，结果就两三个任务，还得额外部署一个Admin，运维成本反而比收益高。反过来，任务超过几十个还在用@Scheduled，光排查执行历史就能让人崩溃。技术选型只看适配度，不看好不好听。

5. 我踩过的坑与最终建议：五个比代码本身更重要的细节

5.1 时区不一致：任务在白天跑了

有次我负责一个定时推送任务，Cron写的是凌晨2点执行，结果每天早上8点才推。定位半天发现，服务器系统时区是UTC，而应用一直用默认时区解析Cron，凌晨2点(UTC)推到了北京时间上午10点。排查方法很简单：在Java进程启动参数里强制指定Asia/Shanghai，或代码里显式设置TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"))，更规范的方式是在@Scheduled处不用默认时区，而是通过定制TaskScheduler的setTimeZone方法来固定Cron解析时区。不要依赖服务器系统时区，这是生产环境的定时任务第一条铁律。

5.2 任务重叠：固定速率遇上慢执行

任务上一次还没执行完，下一次又开始了，结果两个线程同时操作同一批数据，出现重复。我用的解决办法分三步：第一步，评估任务的合理最大执行时间，把调度模式从fixedRate改成fixedDelay或scheduleWithFixedDelay，确保不重叠；第二步，在任务方法入口加分布式锁，保险兜底；第三步，把内部业务改成幂等写入，从数据层面保证重复执行不产生坏结果。三层叠加后，重叠问题基本绝迹。

5.3 异常要吞得明白，不能静默消失

前面提到过，ScheduledExecutorService的定时任务抛异常会取消后续调度，@Scheduled也一样，任务异常会导致调度线程异常终止。更麻烦的是异常不一定打印出来，排查时日志里什么都没有。我现在的习惯是：所有定时任务方法体只做三件事——try-catch抓异常、打error日志、记录失败标记。不要在任何定时任务里直接让异常抛出去，因为调度器不是业务方，它不会对你的异常做任何处理。

@Scheduled(cron = "0 0 2 * * ?") public void safeTask() { try { doBusiness(); } catch (Exception e) { log.error("定时任务执行失败", e); // 可选：写入任务失败表，供补偿 } }

5.4 应用重启与漏执行：别指望调度器帮你补偿

无论你用哪种调度方案，JVM重启期间的定时任务都不会自动补执行。如果业务允许，重启前做好“时间窗口补偿”设计：任务每次执行时先查一下上次执行时间，如果发现超过了预期间隔，则先补一次执行。这个思路在很多数据同步场景里非常实用，因为漏跑一次就等于丢了一批数据。我的做法是把“上次成功执行时间”存到数据库，任务执行时先判断是否超过周期阈值，是就先跑一次补偿，再跑正常调度逻辑。这样即使运维半夜重启服务器，数据也不会断档。

5.5 最后的个人经验总结

结合我这些年的实操经验，帮你把决策成本降到最低：能用@Scheduled解决的就别引入框架，能用一个库解决的就别自研，所有定时任务都要显式处理异常和执行历史。我目前维护的项目里，简单任务用@Scheduled(cron)，需要防止并发的加ShedLock，任务量大、管理要求高的服务单独部署XXL-Job执行器，三层各司其职，线上运行一年多没再出过调度事故。定期事件本身不难，难的是把它放在分布式、多实例、异常频发的真实环境里，还能稳定按点跑起来。希望这篇文章能帮你少走几条弯路。