一种SpringBoot下Scheduler定时任务优雅退出方案

背景

近期业务中有一个定时任务发现每次服务部署时，偶发性的会触发问题，这里记录一下问题的跟进解决。

分析现象

该定时任务每2分钟执行一次，完成数据的更新处理。同时服务部署了多个服务器节点，为保证每次只有一个服务器节点上的任务在跑，引入了基于Redis缓存的分布式锁。
示例源码

@Scheduled(cron = "10 */2 * * * ?")
public void execute() {String jobName = getJobName();DistributeLock lock = distributeLock.newLock(getJobKey(), 5 * 60);if (!lock.tryLock()) {logger.info(" {} execute get lock faild......", jobName);return;}try {logger.info("execute start........ {}", jobName);long startTime = System.currentTimeMillis();doExecute();long endTime = System.currentTimeMillis();logger.info("execute end........,time:{} ms", (endTime - startTime));} catch (Exception e) {logger.error("execute error", e);} finally {lock.unlock();}
}

当服务部署时，分析日志发现存在以下异常。

• 任务存在开始日志，但是缺少执行结束时候的日志。
• 新服务启动后，会存在空的运行周期，所有的节点获取锁失败。

原因： 我们假设任务在具体执行doExecute方法时，服务器节点收到了重新部署的命令。

• 那么此时JVM进程会被kill，由于JVM直接被kill，并没有任何优雅退出的处理，此时也就不会有任务执行结束的日志.
• 同样的，上述代码中的finally语句也不会被执行到，所以锁就不会被释放。
• 由于锁未被及时释放，当下一个2分钟执行周期来到时，我们看到上一个锁的时间是5*60s，此时是无法获取锁的，导致空了一个定时任务周期。

解决方案

方案1：缩短锁的持有时间

将锁的持有时间修改为2分钟，考虑到通常的节点部署时间是超过2分钟的，这样可以保证新服务部署的时候，上一个锁是已经过期的。

看似是可以解决问题的，那么实际可以的吗。其实不然，这种方案是有风险的，因为这里忽略了doExecute的实际执行时间。

原有的5分钟是确定任务最长执行时间不会超过5分钟，但是将锁过期时间设置2分钟实际是否风险的。

举个例子：

10:00 任务1开始执行，执行时间为3分钟，要到10:03才会结束。

10:02 任务2开始执行，此时任务1还在执行，但是由于锁已经过期了，此时任务2也开始执行，要到10:05才会结束。

这就会导致，同一时刻，会存在重叠的任务在执行。
所以不能冒然调整锁的持有时间。

方案2： 利用钩子在服务器停止的时候，将锁显示释放

该方案依赖Spring或者JVM的关闭钩子，在进程销毁的时候，进行一些清理工作。

比如可以依赖Spring的ApplicationListener监听ContextClosedEvent事件。

@Component
@Slf4j
public class DistributeLockShutdownHook implements ApplicationListener<ContextClosedEvent> {@Overridepublic void onApplicationEvent(ContextClosedEvent event) {log.info("shutdown hook, ContextClosedEvent");// 先判断当前节点是否持有定时任务的锁，如果持有// 利用redis缓存的api，直接删除定时任务持有的锁；// 如果不持有锁，不做处理。}
}

这样可以保证锁是清理掉的，后续启动的节点就可以成功获取锁了。

不过这里有一点要注意，在清理时，一定是当前节点之前持有了这把锁才清理。否则，如果不做判断直接清理，就会出现问题，这通常与我们服务部署时，是按照百分比部署有关系。

10:00 B节点正在执行任务，持有锁，任务执行3分钟。

10:01 A节点此时要重新部署服务，将锁删除

10:02 C节点开始执行任务，获取锁成功，也开始执行任务。

那么此时也会导致多个任务在重叠执行。

方案3： 通过定制化线程池，等待当前定时任务执行完成优雅退出

可以看到方案1和方案2，当前正在执行的任务都是直接被终止掉了，那是否有办法等待当前定时任务执行完成，再关闭JVM呢。可以尝试使用以下方案。

首先，我们给Spring Schedule定时任务指定了线程池，同时配置了线程池的关闭策略和关闭等待时间。

@Configuration
public class ThreadPoolTaskSchedulerConfig {@Beanpublic ThreadPoolTaskScheduler threadPoolTaskScheduler () {ThreadPoolTaskScheduler threadPoolTaskScheduler = new ThreadPoolTaskScheduler();//线程池大小为10threadPoolTaskScheduler.setPoolSize(10);//设置线程名称前缀threadPoolTaskScheduler.setThreadNamePrefix("scheduled-thread-test-");//关键点: 设置线程池关闭的时候等待所有任务都完成再继续销毁其他的BeanthreadPoolTaskScheduler.setWaitForTasksToCompleteOnShutdown(true);//关键点：设置线程池中任务的等待时间，如果超过这个时候还没有销毁就强制销毁，以确保应用最后能够被关闭，而不是阻塞住threadPoolTaskScheduler.setAwaitTerminationSeconds(60);threadPoolTaskScheduler.initialize();return threadPoolTaskScheduler;}
}

@Configuration
public class SchedulerConfig implements SchedulingConfigurer {@Resourceprivate ThreadPoolTaskScheduler threadPoolTaskScheduler;@Overridepublic void configureTasks(ScheduledTaskRegistrar scheduledTaskRegistrar) {scheduledTaskRegistrar.setTaskScheduler(threadPoolTaskScheduler);}
}

然后监听Spring的ContextClosedEvent，在其中触发线程池的shutdown方法。

@Component
@Slf4j
public class ShutdownHookDemo implements ApplicationListener<ContextClosedEvent> {@Resourceprivate ThreadPoolTaskScheduler threadPoolTaskScheduler;@Overridepublic void onApplicationEvent(ContextClosedEvent event) {log.info("shutdown hook, ContextClosedEvent");threadPoolTaskScheduler.destroy();}
}

对于ThreadPoolTaskScheduler的destroy方法，源码如下所示：
可以看到会触发ExecutorService的shutDown方法，等待任务执行完成。而awaitTerminationIfNecessary方法则是限时等待，如果超时，则将线程中断。

/*** Calls {@code shutdown} when the BeanFactory destroys* the task executor instance.* @see #shutdown()*/
@Override
public void destroy() {shutdown();
}/*** Perform a shutdown on the underlying ExecutorService.* @see java.util.concurrent.ExecutorService#shutdown()* @see java.util.concurrent.ExecutorService#shutdownNow()*/
public void shutdown() {if (logger.isInfoEnabled()) {logger.info("Shutting down ExecutorService" + (this.beanName != null ? " '" + this.beanName + "'" : ""));}if (this.executor != null) {if (this.waitForTasksToCompleteOnShutdown) {this.executor.shutdown();}else {for (Runnable remainingTask : this.executor.shutdownNow()) {cancelRemainingTask(remainingTask);}}awaitTerminationIfNecessary(this.executor);}
}private void awaitTerminationIfNecessary(ExecutorService executor) {if (this.awaitTerminationMillis > 0) {try {if (!executor.awaitTermination(this.awaitTerminationMillis, TimeUnit.MILLISECONDS)) {if (logger.isWarnEnabled()) {logger.warn("Timed out while waiting for executor" +(this.beanName != null ? " '" + this.beanName + "'" : "") + " to terminate");}}}catch (InterruptedException ex) {if (logger.isWarnEnabled()) {logger.warn("Interrupted while waiting for executor" +(this.beanName != null ? " '" + this.beanName + "'" : "") + " to terminate");}Thread.currentThread().interrupt();}}
}

这样我们可以根据任务最大的超时时间，设置线程池属性，在JVM关闭时等待线程池中的任务执行完成。
方案对比：

• 方案3的实现会导致部署时间的增加，但是可以确保当前定时任务处理完成。
• 方案1和方案2会对当前任务不做处理，同时方案1会存在一定的风险。

可以结合实际业务场景需要进行选择，当然这里只有方案3才是优雅退出。

补充

提到优雅退出，实际Spring有针对web的优雅退出。

修改application.properties配置文件，将server.shutdown从默认的immediate修改为graceful.同时设置等待时间为60s。

也就是说当收到退出请求时，如果此时有web请求还在处理，那么可最多等待60s后再退出。

server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=60s

{"name": "server.shutdown","type": "org.springframework.boot.web.server.Shutdown","description": "Type of shutdown that the server will support.","sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties","defaultValue": "immediate"
}{"name": "spring.lifecycle.timeout-per-shutdown-phase","type": "java.time.Duration","description": "Timeout for the shutdown of any phase (group of SmartLifecycle beans with the same 'phase' value).","sourceType": "org.springframework.boot.autoconfigure.context.LifecycleProperties","defaultValue": "30s"
}

当存在一个正在处理的耗时web请求，当进程关闭时，日志中会包含以下信息

2023-08-05 00:16:32.264 o.s.b.w.e.tomcat.GracefulShutdown : Commencing graceful shutdown. Waiting for active requests to complete
2023-08-05 00:17:32.278 o.s.b.w.e.tomcat.GracefulShutdown: Graceful shutdown aborted with one or more requests still active

最后再强调一次，这里无论哪一种优雅退出，都是针对的kil -15这种操作，这是操作系统给了应用进程优雅退出的机会，如果是kill -9那么就不存在优雅退出了，因为会被立即停止执行。