【小家Spring】控制Spring IoC容器对Bean（含@Configuration配置类）的加载顺序（@DependsOn注解的使用）
【小家Spring】控制Spring IoC容器对Bean（含@Configuration配置类）的加载顺序（@DependsOn注解的使用）
前言
首先，先说明一点：此篇博文相对来说是比较小的专题，只讲解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，是很容易被解释和理解的。这就是为为什么我把这种偏应用的东西，反而放到后面博文来书写的重要原因吧。
万变不离其宗，根基稳了才能决定上层建筑