Spring定时任务高级使用篇

 2022-09-09
原文地址:https://cloud.tencent.com/developer/article/1179985

Spring定时任务高级使用篇

前面一篇博文 《Spring之定时任务基本使用篇》 介绍了Spring环境下,定时任务的简单使用姿势,也留了一些问题,这一篇则希望能针对这些问题给个答案

I. 定时任务进阶篇

1. 问题小结

前面一篇博文,抛出了下面的几个问题,接下来则围绕问题进行分析

  • 一个项目中有多个定时任务时,他们是并行执行的还是串行执行的?
  • 如果默认是串行的 - 那么有相同的crond表达式的定时任务之间,有先后顺序么? - 某个任务的阻塞是否会影响后面的任务? - 如果需要他们并行执行,可以怎么做?
  • 如果是并发执行的 - 是新创建线程还是采用线程池来复用呢? - 在并发执行时,假设有个每秒执行一次的任务,但是它执行一次消耗的时间大于1s时,这个任务的表现时怎样的呢?不断地新增线程来执行还是等执行完毕之后再执行下一次的呢?

2. 多定时任务的串并行分析

如何确认一个项目中的多个定时任务是串行执行还是并发执行呢?要想验证这个功能,最好的法子就是写个testcase,比如定义两个定时任务,在其中一个任务中写个死循环,看另外一个任务是否会正常执行

    @Scheduled(cron = "0/1 * * * * ?")
    public void sc1() throws InterruptedException {
        System.out.println(Thread.currentThread().getName() + " | sc1 " + System.currentTimeMillis());
        while (true) {
            Thread.sleep(5000);
        }
    }
    
    @Scheduled(cron = "0/1 * * * * ?")
    public void sc2() {
        System.out.println(Thread.currentThread().getName() + " | sc2 " + System.currentTimeMillis());
    }

首先我们分析的是 sc1和sc2这两个任务的执行是串行还是并行的,暂时先不考虑 sc1 调用时阻塞,下一秒是否是开新的线程再调用sc1

  • 若串行:则sc1打印一次,sc2可能打印0或者1次
  • 若并行:sc1打印一次,sc2打印n多次

实际运行,GIF图演示如下

202209092300120342.png

sch01.gif

上图的结果,印证了默认的情况下,多个定时任务时串行执行的;如果一个任务出现阻塞,其他的任务都会受到影响

3. 定时任务执行的优先级

既然是顺序执行的,那么优先级怎么定?每次都是固定的,还是随机的呢?

要验证上面的方法,也容易,同样两个任务,看他们的输出是否会乱掉,如果每次都是任务1打印完再打印任务2,那就是固定优先级的;否则每次调度时,顺序不好说

测试代码如下

    @Scheduled(cron = "0/1 * * * * ?")
    public void sc1()  {
        System.out.println(Thread.currentThread().getName() + " | sc1 " + System.currentTimeMillis());
    }
    
    @Scheduled(cron = "0/1 * * * * ?")
    public void sc2() {
        System.out.println(Thread.currentThread().getName() + " | sc2 " + System.currentTimeMillis());
    }

实测结果如下

202209092300136493.png

sch02.jpg

从输出得出结论:顺序是串掉的,并没有表现出明显的优先级关系

4. 并行调度

接下来的问题就是我希望这些任务可以并发执行,可以实现么?

当然是可以,用起来也比较简单,首先是在Application上添加注解@EnableAsync,开启异步调用,然后再计划任务上加上@Async注解即可,一个简单的demo如下

    @EnableAsync
    @EnableScheduling
    @SpringBootApplication
    public class QuickMediaApplication {
    
        public static void main(String[] args) {
            SpringApplication.run(QuickMediaApplication.class, args);
        }
    
        @Scheduled(cron = "0/1 * * * * ?")
        @Async
        public void sc1()  {
            System.out.println(Thread.currentThread().getName() + " | sc1 " + System.currentTimeMillis());
        }
    }

上面执行之后,查看输出(异步调度时,理论上线程名应该不一样)

202209092300157314.png

sch03.jpg

从上面的输出,可以简单的推理,每次调度上面的任务都是新开了一个线程来做的,所以如果在定时任务中写了死循环,是否会导致无限线程,最后整个进程崩掉?

额外提一句,linux系统下单进程的线程数是有上线的,查看命令为:

    ulimit -u

在测试之前,先看下上面的正常任务执行,如下面的动图,线程数并没有夸张的长法

202209092300180235.png

sch04.gif

接下来换成死循环的调度方式,实际测试如下,线程数蹭蹭的上涨

202209092300203546.png

sch05.gif

所以使用默认的异步调用方式,并不是一个好注意,说不准就被玩死了自己都不知道,那么可以用自己的线程池来管理这些异步任务么?

5. 自定义线程池

用自定义的线程池来取代默认线程管理方式,无疑是一个更加安全和灵活的方式,使用起来也并不麻烦,和平常创建线程池的套路没什么区别,要在Spring生态中使用,就把它搞成bean即可

直接借助Spring的线程池ThreadPoolTaskExecutor

    @Bean
    public AsyncTaskExecutor asyncTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setThreadNamePrefix("yhh-schedule-");
        executor.setMaxPoolSize(10);
        executor.setCorePoolSize(3);
        executor.setQueueCapacity(0);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
        return executor;
    }
    
    @Scheduled(cron = "0/1 * * * * ?")
    @Async
    public void sc1() throws InterruptedException {
        System.out.println(Thread.currentThread().getName() + " | sc1 " + System.currentTimeMillis());
        while (true) {
            Thread.sleep(1000 * 5);
        }
    }

实际演示的结果如下,最多10个线程,再提交的任务直接丢弃

202209092300255937.png

sch06.gif

简单说一下,用自定义线程池的好处:

  • 合理的分配线程池参数
  • 拒绝策略的选择也比较有意思(可以按照自己的想法来处理"负载"的任务)
  • 线程池命名,对于以后问题排查,会有很大的帮助

6. 小结

本来这篇博文在昨天即8月2号就应该写完的,结果晚上生产环境下除了点问题,解决线上故障之后就比较晚了,留到了今天,哎,拖延症也是要不得。。。

下面小结Spring中定时任务的几个知识点

  • 默认所有的定时任务都是串行调度的,一个线程,且即便crond完全相同的两个任务先后顺序也没法保证(具体原因需要源码分析,看下这块是怎么支持)
  • 使用@Async注解可以使定时任务异步调度;但是需要开启配置,在启动类上添加 @EnableAsync 注解
  • 开启并发执行时,推荐用自定义的线程池来替代默认的,理由见上面

II. 其他

0. 相关

1. 一灰灰Bloghttps://liuyueyi.github.io/hexblog

一灰灰的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛

2. 声明

尽信书则不如,已上内容,纯属一家之言,因个人能力有限,难免有疏漏和错误之处,如发现bug或者有更好的建议,欢迎批评指正,不吝感激

3. 扫描关注

小灰灰Blog&公众号

202209092300316778.png

QrCode

知识星球

202209092300335529.png

zhishi