文章讲述了在使用cron表达式进行定时任务时，由于毫秒级别的误差导致记录时间比实际执行时间晚一分钟的问题。问题源于@Scheduled在检测到接近整点时提前触发，而newDate()获取的时间在格式化后丢失了精度。提出的处理方案是将定时任务启动时间调整为秒后200毫秒，以确保始终在目标分钟内触发。
这两天做到的一个功能，定时任务每整点生成一条记录，然后使用的cron表达式是：
@Scheduled(cron = "0 0 0/1 * * ?")意为每整点执行一次。
定时任务执行之后使用new Date() 拿到当前本机时间，作为记录的创建时间，使用时间格式化（yyyy-MM-dd HH:mm:00） 将秒钟设置成0。
存入数据库之后发现创建时间正常是整点，但是记录时间（格式化之后的时间）少了一分钟。
原因分析
最终发现 @Scheduled(cron = "0 0 0/1 * * ?")可能会存在毫秒级别的误差，例如此时是2023-06-27 06:59:59.688 ，这时候虽然还没到七点，但是scheduled会检测到最近的时间（精确到秒） 是七点钟，就会开始执行定时任务，而此时new Date（） 得到的实际是
2023-06-27 06:59:59.688 （作为创建时间）
格式化之后就是
2023-06-27 06:59:00.000（作为记录时间）
存入数据库之后
2023-06-27 06:59:59.688 也会mysql四舍五入变成 2023-06-27 07:00:00.000
所以就出现了明明是用同一个时间进行处理操作，为什么记录时间会慢一分钟的现象。
处理方案
可以把定时任务的启动秒钟增加一点，这样无论怎么样都会在那一分钟触发
@Scheduled(cron = "2 0 0/1 * * ?")
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
