wordpress多城市子站高档网站模板
大家好，我是此林。
定时任务是我们项目中经常会遇到的一个场景。那么如果让我们手动来实现一个定时任务框架，我们会怎么做呢？
1. 基础实现：简单的线程池+时间轮询
最直接的方式是创建一个定时任务线程池，用户每提交一个定时任务，就分配一个线程去执行。每个线程使用 Thread.sleep() 或者 while (true) 不断轮询，检查当前时间是否达到了任务的触发时间。
这种方式的问题：
-
一个线程只能执行一个任务，如果定时任务很多，线程池的线程很快就会被占满，导致新的任务无法执行。比如机器是 4 核 CPU，最多可能支持 10 个线程同时执行任务。超过这个数量的任务只能阻塞等待，影响可用性。
-
一般定时任务都是要永久执行，不可能就执行一次或几次就丢弃了。在这种方案下，一台机器只能执行那几个任务，因为那几个任务一直在占用线程池，其他任务无法执行。
2. 优化方案：任务列表+线程池
为了解决上面的问题，我们可以改进方案，使用 检查任务-派发任务 模式：
-
创建一个任务列表，用来存放所有待执行的任务。
-
使用一个独立的线程，不断扫描任务列表，找到即将到达触发时间的任务。
-
将快到触发时间的任务提交给线程池，线程池里的线程只负责执行任务，而不需要一直轮询等待。
-
任务执行完后，线程自动释放回到线程池，提高并发能力。
这种方式的优点：
-
线程池里的线程专注执行任务，不需要每个线程都去检测触发时间，提高了 CPU 的利用率。
-
可以同时执行多个任务，避免任务阻塞导致的执行延迟。
-
任务调度逻辑集中管理，便于扩展和优化。
存在的问题：任务过期
但这种方式也有一个问题：当任务列表里有几百、几千个任务时，扫描任务的线程可能处理不过来，导致一些任务在被扫描到时已经过期了。
那你可能会说，可以增加时间啊，比如提前两秒就提交入线程池。但这样会导致触发时间精度下降，比如某个任务严格要求每3秒执行一次，提前两秒去执行显然是不行的。
3. 进一步优化：任务预读+时间轮
为了解决任务过期问题，我们接下来引入 任务预读 和 时间轮 的概念。
这里就援引一张网络上的时间轮图片。
时间轮的核心思想
可以把时间轮想象成 时钟表：
- 时间轮 = 一个圆形数组（环形结构）
- 每个刻度 = 一秒钟（时间槽位，slot）
- 当前指针 = 记录当前时间进度
- 任务 = 被分配到不同的槽位，等指针走到对应的槽位时执行
当时间轮的指针随着时间推进时，就会触发当前槽位内的任务执行。
同样的，我们开启一个独立的线程，不断扫描任务列表，通过任务的触发时间，计算每个任务在时间轮上的槽位。如下图，为 XXL-JOB 源码。
JobScheduleHelper.java
Thread scheduleThread 部分源码
- 通过任务触发时间计算在 时间轮 上的槽位
- 把任务添加入 时间轮 相应的槽位（一个槽位上可以同时存在多个任务，用一个列表维护）
- 更新任务的下一次触发时间。
上述线程的把任务添加到时间轮的操作称之为：预读
同时，还有一个独立线程 ringThread，可以理解为时间轮上的 指针 。它通过 while 循环不断获取当前的秒数（java.util.Calendar）。
int nowSecond = Calendar.getInstance().get(Calendar.SECOND);通过对当前秒数（nowSecond）对60秒取模，去时间轮里相应的槽位得到相应的任务列表，提交给线程池执行任务（JobTriggerPoolHelper）。
如上操作，检查任务的线程（scheduleThread） 无需等到任务即将到达触发时间时，再向线程池提交任务，只需要预读任务加入到时间轮即可。派发任务的工作由 指针（ringThread）完成即可。从而实现了防止了任务的过期，保证了精准触发。
4. XXL-JOB任务调度源码
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，即低频率触发的线程池。这是为了 限制高频超时任务对资源的占用，避免它们占用过多线程池资源，影响正常任务的调度。
源码见下图。
