品Spring：关于@Scheduled定时任务的思考与探索，结果尴尬了

2019 年 10 月 11 日
笔记

非Spring风格的代码与Spring的结合

现在的开发都是基于Spring的，所有的依赖都有Spring管理，这没有问题。

但是要突然写一些非Spring风格的代码时，可能会很不习惯，如果还要和Spring风格的代码结合起来的话，就会稍显麻烦。

因为非Spring风格的代码不由Spring管理，所以Spring不会给我们注入依赖，相反，我们要自己去Spring中拿取依赖。

所以首先目标就是要获取Spring容器，即ApplicationContext，方法通常如下图01：

定义一个类实现ApplicationContextAware，类中定义一个静态的ApplicationContext字段，Spring会把容器注入到这个静态字段。

由于类的静态字段在JVM中一直存在，这样ApplicationContextUtils这个类就可以在非Spring风格的代码里使用Spring管理的bean了。

若用于定时任务是否有潜在的问题

Spring自带的定时任务，非常好用，而且我很早就用过，具体时间已经记不清了。

我依稀记得以前好像觉得容器还没有启动完成时，定时任务就有可能被触发。就姑且认为是这样吧，当然也可能不是。

如果我的定时任务运行的代码是非Spring风格的，我自然需要自己去new实例，如下图02：

如果这个非Spring风格的代码恰好又要使用Spring管理的bean，那就是刚刚上面提到的方式，如下图03：

可以看到SimpleService是Spring管理的bean，SimpleTask却不是，所以只能在构造方法里使用容器的getBean方式获取。

这种方式通常是没有问题的，我们也都是这样用的。但是要把它放到定时任务里呢？

会不会出现定时任务触发的较早，此时ApplicationContextUtils类里的静态字段ApplicationContext还没有被注入呢？

如果真这样的话，那可就空指针了。那到底会不会这样呢，一起来探索发现下吧。

探索与发现，没有频道

我比较认同这个观点：

当一个人什么都不知道的时候，他觉得自己什么都懂，老想出来指点江山。

当一个人随着学习知道的越多，他发现自己懂的越少，反而不敢随便乱说。

其实就是，知道的越多，问题就越多，随之而来的困惑也就越多。

我写完16篇《品Spring》文章，知道了bean定义注册的顺序、bean实例化的顺序、bean后处理器应用的顺序都和本文描述的问题有关。

所以我也不敢冒然乱说，只能逐步测试逼近答案，这就是典型的知道的“太多了”的烦恼，哈哈。

其实本文的问题就是一个先后顺序的问题，如果定时任务先触发就会产生空指针，如果静态字段先注入，就不会有空指针。

而我选择了相信有空指针，完全是吃瓜群众幸灾乐祸的心理，嘻嘻。

所以我就想办法安排空指针的出现。甚至“处心积虑”，直至使出浑身解数。

一、让定时任务的bean定义注册早于ApplicationContextUtils

抛开依赖不说，实例化的顺序就是bean定义注册的顺序。

bean定义注册的顺序怎么确定呢？单就扫描jar包而言，就是包名和类名的字母顺序。

因此，我的安排如下图04：

最终bean定义的顺序符合预期，如下图05：

这说明bean实例化的顺序是，先实例化定时任务，再实例化ApplicationContextUtils。保证了定时任务在前。

遗憾的是，我安排的空指针没有出现，一切是正常的，定时任务中可以获取到静态字段的值。

二、让定时任务以最快的速度触发

因为这两个bean定义是挨着的，所以实例化也是挨着的。会不会是实例化执行的太快了？

由于实例化的速度无法控制，所以就加快定时任务的触发速度，试试看。

改成1秒就触发，如下图06：

哎，遗憾的是还是一切正常，我太想看到报错了，哈哈，继续使“阴招”。

三、让ApplicationContextUtils的实例化过程卡住

定时任务肯定先实例化好，然后才会去实例化ApplicationContextUtils。

这次想办法让后者卡住，这样定时任务该先执行了吧。小样，我还治不了你啦。

因为定时任务是在单独的线程池中执行，所以让主线程睡一会即可，如下图07：

主线程确实卡住了，遗憾的是还是一切正常。

深入虎穴，不为虎子

ApplicationContext的注入和定时任务的处理都是由bean后处理器完成的。

所以把容器中的后处理器都输出来看看，如下图08：

可以看到共有12个，显示的顺序就是它们被应用的顺序。

也就是说对于每一个bean实例的创建，都会应用这12个，且按如图顺序应用。

只不过每个bean后处理器只处理自己关注的bean，对于不关注的不起作用而已。

而且这12个的顺序只对单个bean有意义，对于不同的bean，没有意义。

因为在测试时，我发现每次必须等容器启动好后，定时任务才开始执行。

所以只能去看处理定时任务的bean后处理器源码了，即ScheduledAnnotationBeanPostProcessor这个类。

于是就从上往下看源码，当看到这个方法后，我似乎明白了，如下图09：

这是一个事件的回调方法，参数是ContextRefreshed事件对象，说明在容器启动完成后会调用这个方法。

再看看方法体，就一句代码，finishRegistration，完成注册，说明在容器没有启动好之前，这个注册是不会完成的。

其实已经表达的很清楚了，只有在容器启动完成后，定时任务才会完成注册，才会开始被调度。

然后再看看完成注册方法，它的最后一句代码如下图10：

这个方法名很亲切吧，就是和初始化相关的。

然后再进到这个方法里看看，如下图11：

也只有一句代码，就是调度任务。哦，现在才开始调度。之前的只是注册任务，并没有调度。

惨遭打脸？其实并没有

我仔细看了几遍源码，发现写的很有特点，既支持容器启动好后触发定时任务，也支持容器启动过程中的及时触发。

只不过现在默认是前者而已。所以我怀疑以前可能就是及时触发，后来可能觉得不太合适，就进行了改造，成了现在这样子。

这既是探索与发现精神，也是好奇精神，就是它促使了我们向前发展，去了解更多的未知领域。

>>> 品Spring系列文章 <<<

品Spring：帝国的基石

品Spring：bean定义上梁山

品Spring：实现bean定义时采用的“先进生产力”

品Spring：注解终于“成功上位”

品Spring：能工巧匠们对注解的“加持”

品Spring：SpringBoot和Spring到底有没有本质的不同？

品Spring：负责bean定义注册的两个“排头兵”

品Spring：SpringBoot轻松取胜bean定义注册的“第一阶段”

品Spring：SpringBoot发起bean定义注册的“二次攻坚战”

品Spring：注解之王@Configuration和它的一众“小弟们”

品Spring：bean工厂后处理器的调用规则