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

@Configuration
public class SchedulerConfig implements SchedulingConfigurer {

    @Resource
    private ThreadPoolTaskScheduler threadPoolTaskScheduler;

    @Override
    public void configureTasks(ScheduledTaskRegistrar scheduledTaskRegistrar) {
        scheduledTaskRegistrar.setTaskScheduler(threadPoolTaskScheduler);
    }
}

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

@Component
@Slf4j
public class ShutdownHookDemo implements ApplicationListener<ContextClosedEvent> {

    @Resource
    private ThreadPoolTaskScheduler threadPoolTaskScheduler;
    
    @Override
    public 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那么就不存在优雅退出了，因为会被立即停止执行。