每篇一句

先把专业搞深一点，然后再向两边扩散

相关阅读

【小家Spring】Spring IOC容器启动流程 AbstractApplicationContext#refresh()方法源码分析（一）
【小家Spring】Spring IOC容器启动流程 AbstractApplicationContext#refresh()方法源码分析（二）
【小家Spring】AbstractBeanFactory#getBean()、doGetBean完成Bean的初始化、实例化，以及BeanPostProcessor后置处理器源码级详细分析

前言

首先，先说明一点：此篇博文相对来说是比较小的专题，只讲解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仍先加载?

需要的场景距离如下

1. bean A 间接（并不是直接@Autowired）依赖 bean B。如bean A有一个属性，需要在初始化的时候对其进行赋值（需要在初始化的时候做，是因为这个属性其实是包装了其它的几个Bean的，比如说代理了Bean B），所以这就形成了Bean A间接的依赖Bean B了
2. 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，是很容易被解释和理解的。这就是为为什么我把这种偏应用的东西，反而放到后面博文来书写的重要原因吧。
万变不离其宗，根基稳了才能决定上层建筑

---

关注A哥

Author	A哥(YourBatman)
个人站点	www.yourbatman.cn
E-mail	yourbatman@qq.com
微 信	fsx641385712
活跃平台
公众号	BAT的乌托邦（ID：BAT-utopia）
知识星球	BAT的乌托邦
每日文章推荐	每日文章推荐