时间轮：XXL-JOB 高效、精准定时任务调度实现思路分析

news2025/1/30 18:24:18

大家好，我是此林。

定时任务是我们项目中经常会遇到的一个场景。那么如果让我们手动来实现一个定时任务框架，我们会怎么做呢？

最直接的方式是创建一个定时任务线程池，用户每提交一个定时任务，就分配一个线程去执行。每个线程使用 Thread.sleep() 或者 while (true) 不断轮询，检查当前时间是否达到了任务的触发时间。

一个线程只能执行一个任务，如果定时任务很多，线程池的线程很快就会被占满，导致新的任务无法执行。比如机器是 4 核 CPU，最多可能支持 10 个线程同时执行任务。超过这个数量的任务只能阻塞等待，影响可用性。
一般定时任务都是要永久执行，不可能就执行一次或几次就丢弃了。在这种方案下，一台机器只能执行那几个任务，因为那几个任务一直在占用线程池，其他任务无法执行。

为了解决上面的问题，我们可以改进方案，使用 检查任务-派发任务 模式：

但这种方式也有一个问题：当任务列表里有几百、几千个任务时，扫描任务的线程可能处理不过来，导致一些任务在被扫描到时已经过期了。

那你可能会说，可以增加时间啊，比如提前两秒就提交入线程池。但这样会导致触发时间精度下降，比如某个任务严格要求每3秒执行一次，提前两秒去执行显然是不行的。

为了解决任务过期问题，我们接下来引入 任务预读 和 时间轮 的概念。

这里就援引一张网络上的时间轮图片。

可以把时间轮想象成 时钟表：

当时间轮的指针随着时间推进时，就会触发当前槽位内的任务执行。

同样的，我们开启一个独立的线程，不断扫描任务列表，通过任务的触发时间，计算每个任务在时间轮上的槽位。如下图，为 XXL-JOB 源码。

JobScheduleHelper.java

Thread scheduleThread 部分源码

上述线程的把任务添加到时间轮的操作称之为：预读

同时，还有一个独立线程 ringThread，可以理解为时间轮上的指针。它通过 while 循环不断获取当前的秒数（java.util.Calendar）。

int nowSecond = Calendar.getInstance().get(Calendar.SECOND);

通过对当前秒数（nowSecond）对60秒取模，去时间轮里相应的槽位得到相应的任务列表，提交给线程池执行任务（JobTriggerPoolHelper）。

如上操作，检查任务的线程（scheduleThread） 无需等到任务即将到达触发时间时，再向线程池提交任务，只需要预读任务加入到时间轮即可。派发任务的工作由 指针（ringThread）完成即可。从而实现了防止了任务的过期，保证了精准触发。

JobScheduleHelper.java

XXL-JOB 的时间轮没有使用环形结构，而是一个ConcurrentHashMap。后续是对60取模来实现类似的循环功能。

scheduleThread

由于调度中心将来可能会集群部署，所以这里使用 select...for update 的悲观锁，保证在同一时刻只能有一个调度中心在调度任务，防止任务重复调度。

XXL-JOB的MySQL表有个任务表，这里默认一次最多读前6000个任务到内存任务列表中（preReadCount = 6000，PRE_READ_MS = 5000，即5秒）。

所以这里读取的任务列表是未来5秒内将要触发的任务（最多前6000个，防止OOM或线程池来不及处理）

遍历任务列表，对60取模，计算出槽位，将任务放入时间轮的对位槽位。

问：如果一个任务每300秒执行一次呢？是不是应该还有个记录圈数字段呢？

答：由于预读操作是未来5秒内将要触发的任务，所以不需要额外记录圈数，这个地方也是XXL-JOB和一般时间轮稍微不一样的点。

ringThread

这里的任务触发会把任务添加到线程池里，线程池并行地通过自研RPC的方式通知执行器执行。

（分布式环境下调度中心和执行器分别部署）

JobTriggerPoolHelper.java

这里有两个线程池，fastTriggerPool 和 slowTriggerPool。

线程池选择逻辑

默认情况下，任务会分配给 fastTriggerPool，即高频率触发的线程池。
如果某个任务在过去一分钟内超时超过 10 次（即 jobTimeoutCount 超过 10），那么该任务会被分配到 slowTriggerPool，即低频率触发的线程池。这是为了 限制高频超时任务对资源的占用，避免它们占用过多线程池资源，影响正常任务的调度。

源码见下图。