生命太短暂，不要去做一些根本没有人想要的东西。本文已被 https://www.yourbatman.cn 收录，里面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的专栏供以免费学习。关注公众号【BAT的乌托邦】逐个击破，深入掌握，拒绝浅尝辄止。
前言
各位小伙伴大家好，我是A哥。关于Spring初始化Bean的顺序问题，是个老生常谈的话题了，结论可总结为一句话：全局无序，局部有序。Spring Bean整体上是无序的，而现实是大多数情况下我们真的无需关心，无序就无序呗，无所谓喽。但是（此处应该有但是哈），我有理由相信，对于有一定从业经验的Javaer来说，或多或少都经历过Bean初始化顺序带来的“困扰”，也许是因为没有对你的功能造成影响，也许可能是你全然“不知情”，所以最终就不了了之~
隐患终归隐患，依照墨菲定律来讲，担心的事它总归是会发生的。A哥经常“教唆”程序员要面向工资编程，虽然这价值观有点扭曲，但不可否认很多小伙伴真是这么想的（命中你了没有），稍加粉饰了而已。话粗理不粗哦，almost所有的Javaer都在用Spring，你凭什么工资比你身边同事的高呢？
Spring对Bean的（生命周期）管理是它最为核心的能力，同时也是很复杂、很难掌握的一个知识点。现在就可以启动你的工程，有木有这句日志：
"Bean 'xxx' of type [xxxx] is not eligible for getting processed by all BeanPostProcessors"
+ "(for example: not eligible for auto-proxying)"
这是一个典型的Spring Bean过早初始化问题，搜搜看你日志里是否有此句喽。这句日志是由Spring的BeanPostProcessorChecker这个类负责输出，含义为：你的Bean xxx不能被所有的BeanPostProcessors处理到（有的生命周期触达不到），提醒你注意。此句日志在低些的版本里是warn警告级别，在本文约定的版本里官方把它改为了info级别。
绝大多数情况下，此句日志的输出不会对你的功能造成影响，因此无需搭理。这也是Spring官方为何把它从warn调低为info级别的原因
我在CSDN上写过一篇“Spring Bean过早初始化导致的误伤”的文章，访问量达近4w：
从这个数据（访问量）上来看，这件事“并不简单”，遇到此麻烦的小伙伴不在少数且确实难倒了一众人。关于Spring Bean的顺序，全局是不可控的，但是局部上它提供了多种方式来方便使用者提高/降低优先级（比如前面的使用@AutoConfigureBefore调整配置顺序竟没生效？这篇文章），本文就聊聊static关键字对于提供Bean的优先级的功效。
版本约定
本文内容若没做特殊说明，均基于以下版本：
JDK：1.8Spring Framework：5.2.2.RELEASE
正文
本文采用从 问题提出-结果分析-解决方案-原理剖析 这4个步骤，层层递进的去感受static关键字在Spring Bean上的魅力~
警告一：来自BeanPostProcessorChecker
这是最为常见的一种警告，特别当你的工程使用了shiro做鉴权框架的时候。在我记忆中这一年来有N多位小伙伴问过我此问题，可见一斑。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
@Configurationclass AppConfig { AppConfig() { System.out.println("AppConfig init..."); } @Bean BeanPostProcessor postProcessor() { return new MyBeanPostProcessor(); }}class MyBeanPostProcessor implements BeanPostProcessor { MyBeanPostProcessor() { System.out.println("MyBeanPostProcessor init..."); }} |
运行程序，输出结果：
AppConfig init...
2020-05-31 07:40:50.979 INFO 15740 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'appConfig'
of type [com.yourbatman.config.AppConfig$$EnhancerBySpringCGLIB$$29b523c8] is not eligible for getting
processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
MyBeanPostProcessor init...
...
结果分析（问题点/冲突点）：
AppConfig优先于MyBeanPostProcessor进行实例化常识是：MyBeanPostProcessor作为一个后置处理器理应是先被初始化的，而AppConfig仅仅是个普通Bean而已，初始化理应靠后
出现了BeanPostProcessorChecker日志：表示AppConfig这个Bena不能被所有的BeanPostProcessors处理，所以有可能会让它“错过”容器对Bean的某些生命周期管理，因此可能损失某些能力（比如不能被自动代理），存在隐患但凡只要你工程里出现了BeanPostProcessorChecker输出日志，理应都得引起你的注意，因为这属于Spring的警告日志（虽然新版本已下调为了info级别）
说明：这是一个Info日志，并非warn/error级别。绝大多数情况下你确实无需关注，但是如果你是一个容器开发者，建议请务必解决此问题（毕竟貌似大多数中间件开发者都有一定代码洁癖
