180803-Spring定时任务高级使用篇

文章目录
  1. I. 定时任务进阶篇
    1. 1. 问题小结
    2. 2. 多定时任务的串并行分析
    3. 3. 定时任务执行的优先级
    4. 4. 并行调度
    5. 5. 自定义线程池
    6. 6. 小结
  2. II. 其他
    1. 0. 相关
    2. 1. 一灰灰Blog: https://liuyueyi.github.io/hexblog
    3. 2. 声明
    4. 3. 扫描关注

logo

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

I. 定时任务进阶篇

1. 问题小结

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
@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图演示如下

sch01.gif

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

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

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

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

测试代码如下

1
2
3
4
5
6
7
8
9
@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());
}

实测结果如下

sch02.jpg

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

4. 并行调度

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@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());
}
}

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

sch03.jpg

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

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

1
ulimit -u

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

sch04.gif

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

sch05.gif

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

5. 自定义线程池

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

直接借助Spring的线程池ThreadPoolTaskExecutor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@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个线程,再提交的任务直接丢弃

sch06.gif

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

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

6. 小结

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

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

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

II. 其他

0. 相关

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

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

2. 声明

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

3. 扫描关注

小灰灰Blog&公众号

QrCode

知识星球

zhishi

# Spring

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×