前言
首先，先说明一点：此篇博文相对来说是比较小的专题，只讲解Spring IoC加载Bean的顺序问题。
为了更好的了解这里面的原理，建议先了解Spring容器内部对Bean执行初始化的原理，因此推荐下面博文（若已了解，请忽略）：
【小家Spring】Spring IOC容器启动流程 AbstractApplicationContext#refresh()方法源码分析（二），Spring容器启动/刷新的完整总结
【小家Spring】AbstractBeanFactory#getBean()、doGetBean完成Bean的初始化、实例化，以及BeanPostProcessor后置处理器源码级详细分析
本文的讲解方式，以案例为主，进行各种case的分析讲解
为什么要控制Bean的加载顺序？
@Order注解等并不能控制Bean的加载顺序的~~因为你如果熟悉原理了就知道Spring在解析Bean的时候，根本就没有参考这个注解
另外@Configuration配置类的加载，也不会受到@Order注解的影响。因为之前源码解释过，它拿到配置的数组，仅仅就是一个for循环遍历去解析了
另外需要说明的一点是：@Configuration注解的解析顺序，在Spring Boot环境下会受到影响的（毕竟Boot都是自动的，而不是我们手动传值的） 相关注解有：@AutoConfigureAfter、@AutoConfigureBefore、@AutoconfigureOrder等等
Spring容器载入bean顺序是不确定的，spring框架没有约定特定顺序逻辑规范。
但是但Spring能保证如果A依赖B(如beanA中有@Autowired B的变量)，那么B将先于A被加载（这属于Spring容器内部就自动识别处理了）。但如果beanA不直接依赖B，我们如何让B仍先加载?
需要的场景距离如下
- bean A 间接（并不是直接@Autowired）依赖 bean B。如bean A有一个属性，需要在初始化的时候对其进行赋值（需要在初始化的时候做，是因为这个属性其实是包装了其它的几个Bean的，比如说代理了Bean B），所以这就形成了Bean A间接的依赖Bean B了
- bean A是事件发布者（或JMS发布者），bean B (或一些) 负责监听这些事件，典型的如观察者模式。我们不想B 错过任何事件，那么B需要首先被初始化。
以上是两种典型的，Bean初始化的时候存在依赖关系的情况，都可以通过@DependsOn来解决，件下面Demo 。（当然有的时候可以通过别的方式间接解决，比如特殊接口SmartInitializingSingleton ，又或者是Spring Boot提供的CommandLineRunner、ApplicationRunner等接口，但这些都不是本文研究的重点）
Bean加载循序、依赖关系Case~
备注：这里面解答的方案，不考虑上面说到的使用SmartInitializingSingleton等间接的方案
准备工作：（两个controller和一个service）
@Controller public class HelloController { public HelloController() { System.out.println("HelloController 初始化。。。"); } @ResponseBody @GetMapping("/hello") public String helloGet() throws Exception { return "hello...Get"; } } @Controller public class AsyncHelloController { public AsyncHelloController() { System.out.println("AsyncHelloController 初始化。。。"); } } @Service public class HelloServiceImpl implements HelloService { public HelloServiceImpl() { System.out.println("HelloServiceImpl 初始化。。。"); } }
启动容器，打印顺序（初始化顺序如下：）
HelloServiceImpl 初始化。。。 AsyncHelloController 初始化。。。 HelloController 初始化。。。
需要注意的是：这个demo的日志都是放在默认的构造函数里面的，因此即使你使用了@Autowired，也是不会打乱构造函数的执行顺序的，因为，因为@Autowired的解析发生在给属性赋值的populate()方法里（具体查之前博文或者源码），这个时候自己已经实例化了，才会去给属性赋值嘛
所以如果你要求的时机稍微比较晚可以在赋值期间、或者实例化期间去
@DependsOn：让HelloController在AsyncHelloController之前实例化
//@DependsOn // 这里面写String数组。不写不会生效，但是若写了，名字要写正确，否则会报错的 @DependsOn({"helloController"}) // 名称必须写对，必须是容器里存在的Bean，否则启动报错的（fast-fail是好事） @Controller public class AsyncHelloController { ... } HelloServiceImpl 初始化。。。 HelloController 初始化。。。 --> HelloController先被实例化了~~~ AsyncHelloController 初始化。。。
需要特别注意的是，使用@DependsOn注解时，一定要注意父子容器的问题（因为它底层也是getBean()）。比如下面这样在service层依赖controller的话，就报错：
@DependsOn({"helloController"}) //NoSuchBeanDefinitionException: No bean named 'helloController' available @Service public class HelloServiceImpl implements HelloService { ... }
SpringBoot环境下，不会报错。具体原因请关注SpringBoot的原理分析相关博文吧
使用@Lazy间接实现
@Lazy public class AsyncHelloController { ... } HelloServiceImpl 初始化。。。 HelloController 初始化。。。
我们发现它只有两句输出，这个时候AsyncHelloController还没有实例化。只有首次访问它的时候才会实例化，所以我们是通过间接的方式实现了这个效果。
这种方式不建议使用在这种DependsOn的场景，因为它不是为了这个而生的。若有别的Bean @Autowired了它之类的，这种做法显然就失效了~~~
//May be used on any class directly or indirectly annotated with @Component // or on methods annotated with @Bean // 若这个Bean xml里也配置了，就会议xml里配置的为准 @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface DependsOn { String[] value() default {}; }
@DependsOn 用于@Bean注解上的使用
由于使用方式很简单，因此略过~
@Configuration配置类顺序控制
@Configuration配置类也是容器里面一个特殊的Bean，因为它不需要完成业务功能，因此它
纯Spring环境
由于在纯Spring环境下，Config配置类都是由我们手动指定传进去的，所以Spring并没有再对它进行排序处理。如下非web环境和web环境：
public static void main(String[] args) { // 这里Config是自己指定、所以加载顺序就是我们传入的顺序 new AnnotationConfigApplicationContext(RootConfig.class, Root2Config.class); } @Override protected Class<?>[] getRootConfigClasses() { return new Class<?>[]{RootConfig.class, Root2Config.class}; }
@Configuration的加载顺序，并不影响@Bean的互相引用：
@Configuration public class RootConfig { // 虽然入参里的Parent 在配置类Root2Config里，但spring还是能够去容器中找过来的。 @Bean public Child child(Parent parent) { System.out.println(parent); return new Child(); } } @Configuration public class Root2Config { @Bean public Parent parent() { return new Parent(); } } 配置文件加载顺序为：RootConfig 、 Root2Config @Override protected Class<?>[] getRootConfigClasses() { return new Class<?>[]{RootConfig.class, Root2Config.class}; }
有这效果我们可以看到，Config的先后顺序，并不影响@Bean的引用。
此处需要特别说明的一点是：请不要循环引用，否则会报错~（笔记这个和Bean的属性赋值方面的循环引用还是不一样的，有点类似构造器的循环引用。我们知道的是，Spring是不能解决构造器的循环引用的）
Spring Boot环境
略，具体使用方法大都同Spring。但是在基础上增强了，它支持用户自定义@Configuration的加载顺序
总结
如果了解了Spring IoC容器初始化的原理后，再去看看这些依赖、循环引用等Case，是很容易被解释和理解的。这就是为为什么我把这种偏应用的东西，反而放到后面博文来书写的重要原因吧。
万变不离其宗，根基稳了才能决定上层建筑
