前言

早上研发经理给我分配了一个开发任务：每5秒统计一次APP在线人数，并问我啥时能上线？

我心想这需求用Spring的定时任务完美解决啊！作为一个萌新正好借此机会在经理面前表现一番，于是我拍着胸脯跟经理说半小时就能做好。

不曾想在做的过程中遇到大坑，花了半天才搞好。在这里友情提醒一下广大程序员小伙伴们开发估时间有一定要给自己留点余地，千万不想学我（此刻我已流下悔恨的泪水~）

目录

1. 定时任务怎么不执行了？
2. 深入源码中找原因
3. 3种解决方案对比，谁最简单？
4. 定时任务你真的会用吗？
5. Quartz——更好的任务调度框架

定时任务怎么不执行了？

要想让Spring Boot项目支持定时任务，我们需要做一些准备工作：

首先，在启动入口类上加上@EnableScheduling注解，开始定时任务支持；

下面来看一下我的定时任务（为了方便演示，具体逻辑已略去）；

没什么难的，按照我的预想项目启动之后应该是每5秒输出一次日志的，大概是这样：

敲完定时任务最后一行代码，一看时间才过去10分钟，心想就我这速度也是没谁了，经理肯定得夸我呀！

你以为我会立刻就向经理报告吗？错！作为一个具备专业素养的程序员，肯定得自己测试完再向经理报告啦。

OK，启动项目测试下任务执行情况，看到控制台输出的结果之后我是虎躯一震，发现事情并没有那么简单，先来看输出结果：

我写的定时任务规则明明是每5秒执行一次，可这实际执行时间一会间隔6秒、一会间隔4秒、一会又间隔5秒，完全不按套路出牌啊！啥情况？

深入源码找原因

代码报错你们觉得我会很慌？错！我会感到浑身兴奋（实则内心慌的一批~）

报错是好事，毕竟我是要成为“Debug小王子”的男人！

从哪开始Debug呢？既然我是使用@EnableScheduling注解开启定时任务支持的，那就从它开始吧；

这个注解的代码真是太太太简洁了，简洁到啥都没有，主要就是通过@Import导入了一个SchedulingConfiguration配置类。

好吧，在下佩服！

继续跟进：

没想到的是SchedulingConfiguration配置类里面也仅仅定义了一个ScheduledAnnotationBeanPostProcessor类型的bean。

这家伙隐藏够深的啊！继续跟进，终于让我发现了点东西：

首先，ScheduledAnnotationBeanPostProcessor实现了ApplicationListener接口；

这个接口有啥用呢？

实现了这个接口，我们就可以监听到Spring Boot在启动过程的不同周期的回调事件，这里监听的是ApplicationContext的刷新事件。

也就是说，在Spring Boot启动过程中，当容器上下文ApplicationContext刷新结束后会回调ScheduledAnnotationBeanPostProcessor当中的onApplicationEvent方法：

onApplicationEvent方法里又调用了finishRegistration方法；

这finishRegistration方法比较长就不贴图了，反正里面主要就做了一件事：加载一个叫taskScheduler的bean。

直觉告诉我这个bean肯定是Spring Boot自动装载的（用飘柔就是这么自信！哎~ 别打我……）。

我们来验证一下这个大胆的猜想，打开Spring Boot的自动装载清单文件spring.factories：

果然发现了一个TaskSchedulingAutoConfiguration配置类，是不是已经开始有点崇拜我了！

进去看一下：

是不是有个叫taskScheduler的bean？这个taskScheduler的类型是ThreadPoolTaskScheduler，ThreadPool？一看名字就知道是使用线程池实现的，果然下面的taskSchedulerBuilder方法里就有设置池子的大小的方法。

最终的线索指向了TaskSchedulingProperties这个属性类，我们来看一下它里面有什么秘密：

它里面默认的线程池大小就是1。

明白了，这下全明白了！

让我们从头来捋一遍整个逻辑：

1. 当我们使用注解开启定时任务支持时，Spring Boot在启动过程中会去找一个叫taskScheduler的bean当作整个应用的任务调度器；
2. 这个taskScheduler默认是由Spring Boot自动加载的，它里面有一个执行定时任务的线程池，默认大小就是1；

也就是说所有任务都只能由这一个线程来执行，如果有多个定时任务需要执行，那也只能排队顺序执行；

这时我正好想到项目里正好还有几个其他的定时任务在跑，各个任务执行时间点、耗费时间都不一样；

因为只有一个线程来执行所有任务，那么当有一个定时任务要耗费很长时间时，那么其他定时任务即使到了执行时间点也只能继续等待了？

接下来我用两个定时任务来测试一下，看看它们的线程名是不是一样？

改造一下两个定时任务的逻辑：

• 首先任务一每5秒执行一次、每次耗时4秒，任务二每3秒执行一次；
• 其次两个任务里都将打印当前执行任务线程名；

来看一下执行结果：

可以看到2个定时任务的执行线程名是一样的；仔细看一下任务2的执行时间点，原本应该1秒执行一次，现在却执行的毫无规律可言。

3种解决方案对比，谁最简单？

我总结了一下发现网上主要有2种解决方案。

方法一：

实现SchedulingConfigurer接口，提供一个自定义的TaskScheduler；

方法二：

首先提供一个自定义的线程池，并使用@EnableAsync注解开启异步支持：

再在定时任务方法上加上@Async注解启用异步执行；

首先，经过我实际测试，两种方法都能解决问题。

但是在我看来这2中办法都太笨重，又是要新建配置类、又要另外使用一个注解，简直不能忍（主要是我懒~）！

下面我来提供一下最简单的解决方案，还记得在源码中我们最终找到的TaskSchedulingProperties这个属性类吗？

这个配置类通过注解绑定了项目配置文件中以spring.task.scheduling开头的配置属性，所以我们只需要在application.properties文件中提供一个spring.task.scheduling.pool.size属性就能改变线程池的带下了；

是不是比上面2种解决方法更简单？自己找到的解决方法就是好用！

定时任务你真的会用吗？

是不是感觉自己对定时任务好像也没那么了解了？下面顺道来复习一下吧。

首先来看一下@Scheduled注解：

可以看到@Scheduled注解中有多个配置元素：

1. cron表达式，可以灵活指定任务执行时间，几乎可以实现任何你想要的时间点与周期；
2. zone时区，默认当前时区，一般不会用到；
3. fixedDelay，表示自上一次任务执行完成后延迟多久再次执行，参数为long类型，单位毫秒；
4. fixedDelayString，同fixedDelay，只是参数类型变为String；
5. fixedRate，表示任务将按照固定的频率执行，参数为long类型，单位毫秒；
6. fixedRateString，同fixedRate，只是参数类型变为String；
7. initialDelay，表示应用启动后将会延迟多久才会第一次执行任务，参数为long类型，单位毫秒；
8. initialDelayString，同initialDelay，只是参数类型变为String；

接下来重点说一下cron表达式吧。

cron表达式共有7位域（Spring当中只需6位域），从左到右分别代表：

秒 分 小时 日期 月份 星期 年份（可省略）

其中：

• *字符表示所有的值，用在秒域表示每秒钟、用在分钟域表示每分钟；
• -字符表示一个范围区间，例如5-10，用在秒域表示从第5秒开始到第10秒结束、每秒执行一次，用在分钟域则表示从第5分钟开始到第10分钟结束、每分钟执行一次。
• ,字符表示指定的值，l例如10,15,20用在分钟域表示只在第10分钟、第15分钟、第20分钟各执行一次；
• /字符表示指定步长，例如0/15用在秒域表示从第0秒开始、每15秒执行一次，用在分钟域表示从第0分钟开始、每15分钟执行一次；
• ?字符只能用在日期和星期两个域，表示不明确的值。日期和星期是一一对应关系，如果设置了日期，那么可在星期域使用?代替明确的星期值；
• L字符只能用在日期和星期两个域，表示最后一天。单独用在日期域表示一个月的最后一天，单独用在星期域表示一个星期的最后一天（星期六），另外当L用在星期域时可以和数字组合使用，例如5L表示在一个月的最后一个星期四执行（5代表星期四）；
• W字符只能用在日期域，表示任务将在离指定日期的最近的一个工作日(周一到周五)执行。例如我在日期域写上15W，那代表任务将在离15号最近的一个工作日执行，如果15号正好是周六、那么任务会提前在14号触发，如果15号是周日则任务会在16号触发；
• L和W字符可组合使用、但只能用在日期域，表示一个月的最后一个工作日（最后一个星期五）；
• #字符只能用在星期域，用于指定一个月的第几个星期几。例如7#3表示一个月的第三周的星期六（7代表星期六，3代表第三周）；
• 至于C字符，网上都说是要根据指定日历计算执行时间，至于怎么指定日历的压根不提，我也是醉了！这个我真不知道怎么使用；

Quartz——更好的任务调度框架

Spring的定时任务虽然使用起来很方便，但我在实际应用中发现存在以下几个问题：

• 不支持高可用，当项目需要发新版时，需要停止应用进程，那么定时任务也会停止导致数据缺失。
• 不支持分布式，当项目需要上集群或者负载均衡时，一个任务会被多次执行导致数据错乱。
• 不支持动态操作，当需要修改某个任务执行时间、或者停止/启动某个定时任务时，我们只能修改代码重新发布。

作为一个有理想有抱负的程序员，我是绝对不允许项目中存在这种问题的。

经过我的一番搜寻，终于找到了Quartz这个开源任务调度框架，它不仅可以动态添加删除任务，还支持手动开启或停止任务；最关键的是它支持分布式部署，可以保证任务不漏跑不重跑，还能将任务分散到不同的机器同步执行。

这是我们公司内部在用的基于Quartz框架实现的一套可以动态管理定时任务的系统：

鉴于篇幅有限，在这就不展开介绍了，后续有机会在单独写一篇详细介绍一下Quartz框架的用法。

“分享干货，收获快乐”

我是一名程序员，喜欢我的文章欢迎 关注 及 转发，我会经常与大家分享工作当中的实用技巧与经验。