SpringBoot Bean指定初始化顺序详解

不念不忘少年蓝@ 2022-12-19 01:23 486阅读 0赞

**最近遇到SpringBoot容器外类初始化依赖容器内bean的问题，由于容器内bean初始化有一定顺序，网上查了查资料，这里记录一下。**

# 0. 前言 #

本文将介绍几种可行的方式来控制 bean 之间的加载顺序

*  @Order指明顺序
 *  @AutoConfigureOrder
 *  构造方法依赖
 *  @DependOn 注解
 *  BeanPostProcessor 扩展

# 1. @Order和@AutoConfigureOrder说明 #

## 1.1. 错误姿势 ##

下面我们会介绍两种典型注解的错误使用姿势，一个`@Order`，一个`@AutoConfigureOrder`

### 1.1.1 @Order ###

**err.case1: 类上添加 Order 注解**

**结论：Sprintboot默认自动扫描，order 值的大小，与指定 bean 之间的初始化顺序无关。**

一种常见的错误观点是在类上添加这个 Order 注解，就可以指定 bean 之间的初始化顺序，order 值越小，则优先级越高，接下来我们实际测试一下，是否如此

我们创建两个 DemoBean, 指定不同的 Order 顺序

@Order(4)
    @Component
    publicclass BaseDemo1 {
        private String name = "base demo 1";
    
        public BaseDemo1() {
            System.out.println(name);
        }
    }
    
    @Order(3)
    @Component
    publicclass BaseDemo2 {
        private String name = "base demo 2";
    
        public BaseDemo2() {
            System.out.println(name);
        }
    }

根据前面的观点，order值小的优先级高，那么 BaseDemo2 应该先被初始化，实际测试一下，输出如下

![755543141f36491c442c754f1f346b50.png][]

**err.case2: 配置类中 Bean 声明方法上添加@Order**

**结论：通过`@Bean`注解扫描，order 值的大小，与指定 bean 之间的初始化顺序无关。**

Bean 除了上面的自动扫描之外，还有一种方式就是通过`@Bean`注解，下面我们演示一下在配置类中指定 bean 加载顺序的错误 case

同样我们新建两个测试 bean

publicclass BaseDemo3 {
        private String name = "base demo 3";
    
        public BaseDemo3() {
            System.out.println(name);
        }
    }
    
    publicclass BaseDemo4 {
        private String name = "base demo 4";
    
        public BaseDemo4() {
            System.out.println(name);
        }
    }

接下来在配置类中定义 bean

@Configuration
    publicclass ErrorDemoAutoConf {
        @Order(2)
        @Bean
        public BaseDemo3 baseDemo3() {
            returnnew BaseDemo3();
        }
    
        @Order(1)
        @Bean
        public BaseDemo4 baseDemo4() {
            returnnew BaseDemo4();
        }
    }

同样的，如果`@Order`注解有效，那么`BaseDemo4`应该先被初始化

![a2d2335cd88cb1235534f90f55bd2f2a.png][]

从上面的实际测试输出可以看出，@Order 注解在上面的方式中也不生效，如果有兴趣的同学可以试一下，将上面配置类中的两个方法的顺序颠倒一下，会发现`BaseDemo4`先加载

**err.case3: @Order 注解修饰配置类**

**结论：通过@Order 注解是用来指定配置类的加载顺序，初始化顺序与@Order大小值无关。**

这也是一种常见的错误 case，认为@Order 注解是用来指定配置类的加载顺序的，然而真的是这样么?

我们创建两个测试的配置类

@Order(1)
    @Configuration
    publicclass AConf {
        public AConf() {
            System.out.println("AConf init!");
        }
    }
    
    @Order(0)
    @Configuration
    publicclass BConf {
        public BConf() {
            System.out.println("BConf init");
        }
    }

如果@Order 注解生效，那么 BConf 配置类会优先初始化，那么我们实测一下

![5ba7691cc047cedb1e211635d2ead1c0.png][]

从上面的结果可以看出，并不是 BConf 先被加载；当然这种使用姿势，实际上和第一种错误 case，并没有什么区别，配置类也是 bean，前面不生效，这里当然也不会生效。

那么是不是我们的理解不对导致的呢，实际上这个`@Order`放在配置类上之后，是这个配置类中定义的 Bean 的优先于另一个配置类中定义的 Bean 呢？

同样的我们测试下这种 case，我们定义三个 bean，两个 conf

publicclass Demo1 {
        private String name = "conf demo bean 1";
    
        public Demo1() {
            System.out.println(name);
        }
    }
    
    publicclass Demo2 {
        private String name = "conf demo bean 2";
    
        public Demo2() {
            System.out.println(name);
        }
    }
    
    publicclass Demo3 {
        private String name = "conf demo bean 3";
    
        public Demo3() {
            System.out.println(name);
        }
    }

然后我们将 Demo1, Demo3 放在一个配置中，Demo2 放在另外一个配置中

@Order(2)
    @Configuration
    publicclass AConf1 {
        @Bean
        public Demo1 demo1() {
            returnnew Demo1();
        }
    
        @Bean
        public Demo3 demo3() {
            returnnew Demo3();
        }
    }
    
    @Order(1)
    @Configuration
    publicclass BConf1 {
    
        @Bean
        public Demo2 demo2() {
            returnnew Demo2();
        }
    }

如果@Order 注解实际上控制的是配置类中 Bean 的加载顺序，那么 BConf1 中的 Bean 应该优先加载，也就是说 Demo2 会优先于 Demo1, Demo3，实际测试一下，输出如

![3a2210124d30fa3fa455378837d152aa.png][]

上面的输出结果和我们预期的并不一样，所以`@Order`注解来决定配置类的顺序也是不对的

### 1.1.2. @AutoConfigureOrder ###

从命名来看，这个注解是用来指定配置类的顺序的，然而对于这个注解的错误使用也是非常多的，而大多的错误使用在于没有真正的了解到它的使用场景

接下来我们来演示一下错误的使用 case

在工程内新建两个配置类，直接使用注解

@Configuration
    @AutoConfigureOrder(1)
    publicclass AConf2 {
        public AConf2() {
            System.out.println("A Conf2 init!");
        }
    }
    
    @Configuration
    @AutoConfigureOrder(-1)
    publicclass BConf2 {
        public BConf2() {
            System.out.println("B conf2 init!");
        }
    }

当注解生效时，BConf 会优先级加载

![6a4981065c461d14b74d8c93d321f461.png][]

从输出结果来看，和我们预期的不一样；那么这个注解是不是作用于配置类中的 Bean 的顺序，而不是配置类本身呢？

同样的我们设计一个 case 验证一下

publicclass DemoA {
        private String name = "conf demo bean A";
    
        public DemoA() {
            System.out.println(name);
        }
    }
    
    publicclass DemoB {
        private String name = "conf demo bean B";
    
        public DemoB() {
            System.out.println(name);
        }
    }
    
    publicclass DemoC {
        private String name = "conf demo bean C";
    
        public DemoC() {
            System.out.println(name);
        }
    }

对应的配置类

@Configuration
    @AutoConfigureOrder(1)
    publicclass AConf3 {
        @Bean
        public DemoA demoA() {
            returnnew DemoA();
        }
    
        @Bean
        public DemoC demoC() {
            returnnew DemoC();
        }
    }
    
    @Configuration
    @AutoConfigureOrder(-1)
    publicclass BConf3 {
    
        @Bean
        public DemoB demoB() {
            returnnew DemoB();
        }
    }

如果 DemoB 后被加载，则说明上面的观点是错误的，实测结果如下

![9ec7cd22744089491c41506037c82d9f.png][]

所以问题来了，`@AutoConfigureOrder`这个注解并不能指定配置类的顺序，还叫这个名，干啥？存粹是误导人不是!!!

接下来我们看一下`@Order`和`@AutoConfigureOrder`的正确使用方式

## 1.2. 使用说明 ##

### 1.2.1. @Order ###

先看一下这个注解的官方注释

> \{@code @Order\} defines the sort order for an annotated component. Since Spring 4.0, annotation-based ordering is supported for many kinds of components in Spring, even for collection injection where the order values of the target components are taken into account (either from their target class or from their \{@code @Bean\} method). While such order values may influence priorities at injection points, please be aware that they do not influence singleton startup order which is an orthogonal concern determined by dependency relationships and \{@code @DependsOn\} declarations (influencing a runtime-determined dependency graph).

最开始 Order 注解用于切面的优先级指定；在 4.0 之后对它的功能进行了增强，**@Order 支持集合的注入时，指定集合中 bean 的顺序**。

**并且特别指出了，它对于单实例的 bean 之间的顺序，没有任何影响；**这句话根据我们上面的测试也可以验证。

接下来我们需要看一下通过@Order 注解来注入集合时，指定顺序的场景。

首先我们定义两个 Bean 实现同一个接口，并添加上`@Order`注解。

publicinterface IBean {
    }
    
    @Order(2)
    @Component
    publicclass AnoBean1 implements IBean {
    
        private String name = "ano order bean 1";
    
        public AnoBean1() {
            System.out.println(name);
        }
    }
    
    @Order(1)
    @Component
    publicclass AnoBean2 implements IBean {
    
        private String name = "ano order bean 2";
    
        public AnoBean2() {
            System.out.println(name);
        }
    }

然后在一个测试 bean 中，注入`IBean`的列表，我们需要测试这个列表中的 Bean 的顺序是否和我们定义的`@Order`规则一致

@Component
    publicclass AnoTestBean {
    
        public AnoTestBean(List<IBean> anoBeanList) {
            for (IBean bean : anoBeanList) {
                System.out.println("in ano testBean: " + bean.getClass().getName());
            }
        }
    }

根据我们的预期, anoBeanList 集合中，anoBean2 应该在前面

![847f302b581bdde239e737e10e8b2be6.png][]

根据上面的输出，也可以看出列表中的顺序和我们预期的一致，并且 `AnoOrderBean1`与 `AnoOrderBean2` 的加载顺序和注解没有关系

### 1.2.2. @AutoConfigureOrder ###

这个注解用来指定配置文件的加载顺序，然而前面的测试中并没有生效，那么正确的使用姿势是怎样的呢？

**`@AutoConfigureOrder`适用于外部依赖的包中 AutoConfig 的顺序，而不能用来指定本包内的顺序**

为了验证上面的说法，我们再次新建两个工程，并指定自动配置类的顺序

工程一配置如下：

@AutoConfigureOrder(1)
    @Configuration
    @ComponentScan(value = {"com.git.hui.boot.order.addition"})
    publicclass AdditionOrderConf {
        public AdditionOrderConf() {
            System.out.println("additionOrderConf init!!!");
        }
    }

注意自动配置类如要被正确加载，需要在工程的 `/META-INF/spring.factories`文件中定义

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.git.hui.boot.order.addition.AdditionOrderConf

工程二的配置如下:

@Configuration
    @AutoConfigureOrder(-1)
    @ComponentScan("com.git.hui.boot.order.addition2")
    publicclass AdditionOrderConf2 {
    
        public AdditionOrderConf2() {
            System.out.println("additionOrderConf2 init!!!");
        }
    }

然后我们在项目内部添加一个配置

@AutoConfigureOrder(10)
    @Configuration
    publicclass OrderConf {
        public OrderConf() {
            System.out.println("inner order conf init!!!");
        }
    }

因为注解适用于外部依赖包中的自动配置类的顺序，所以上面三个配置类中，正确的话 AdditionOrderConf2 在 AdditionOrderConf1 之前；

而 OrderConf 并不会收到注解的影响，默认环境下，内部定义的配置类会优于外部依赖，从下面的输出也可以佐证我们说明（当然为了验证确实如此，还应该调整下两个外部工程配置类的顺序，并观察下加载顺序是否随之改变，我们这里省略掉了）

![2ca84b3445055c410212af7c8ec5904a.png][]

## 1.3 . 小结 ##

本篇主要介绍了网上对`@Order`和`@AutoConfigureOrder`常见的错误使用姿势，并给出了正确的使用 case。

下面用简单的几句话介绍一下正确的姿势

*  **`@Order`注解不能指定 bean 的加载顺序，它适用于 AOP 的优先级，以及将多个 Bean 注入到集合时，这些 bean 在集合中的顺序。**
 *  **`@AutoConfigureOrder`指定外部依赖的 AutoConfig 的加载顺序（即定义在`/META-INF/spring.factories`文件中的配置 bean 优先级)**，在当前工程中使用这个注解并没有什么鸟用。
 *  同样的 `@AutoConfigureBefore`和 `@AutoConfigureAfter`这两个注解的适用范围和`@AutoConfigureOrder`一样。

# 2. 初始化顺序指定 #

## 2.1. 构造方法依赖 ##

这种可以说是最简单也是最常见的使用姿势，但是在使用时，需要注意循环依赖等问题

我们知道 bean 的注入方式之中，有一个就是通过构造方法来注入，借助这种方式，我们可以解决有优先级要求的 bean 之间的初始化顺序

比如我们创建两个 Bean，要求 CDemo2 在 CDemo1 之前被初始化，那么我们的可用方式

@Component
    public class CDemo1 {
    
        private String name = "cdemo 1";
    
        public CDemo1(CDemo2 cDemo2) {
            System.out.println(name);
        }
    }
    
    @Component
    public class CDemo2 {
    
        private String name = "cdemo 1";
    
        public CDemo2() {
            System.out.println(name);
        }
    }

实测输出结果如下，和我们预期一致

![cbe0bdb51d484d45d9901e079a17ea38.png][]

虽然这种方式比较直观简单，但是有几个限制

*  需要有注入关系，如 CDemo2 通过构造方法注入到 CDemo1 中，如果需要指定两个没有注入关系的 bean 之间优先级，则不太合适（比如我希望某个 bean 在所有其他的 Bean 初始化之前执行）
 *  循环依赖问题，如过上面的 CDemo2 的构造方法有一个 CDemo1 参数，那么循环依赖产生，应用无法启动

另外一个需要注意的点是，在构造方法中，不应有复杂耗时的逻辑，会拖慢应用的启动时间

## 2.2. @DependOn 注解 ##

这是一个专用于解决 bean 的依赖问题，当一个 bean 需要在另一个 bean 初始化之后再初始化时，可以使用这个注解

使用方式也比较简单了，下面是一个简单的实例 case

@DependsOn("rightDemo2")
    @Component
    public class RightDemo1 {
        private String name = "right demo 1";
    
        public RightDemo1() {
            System.out.println(name);
        }
    }
    
    @Component
    public class RightDemo2 {
        private String name = "right demo 2";
    
        public RightDemo2() {
            System.out.println(name);
        }
    }

上面的注解放在 `RightDemo1` 上，表示`RightDemo1`的初始化依赖于`rightDemo2`这个 bean

![461201c6c3f415780316b412471def50.png][]

在使用这个注解的时候，有一点需要特别注意，它能控制 bean 的实例化顺序，但是 bean 的初始化操作（如构造 bean 实例之后，调用`@PostConstruct`注解的初始化方法）顺序则不能保证，比如我们下面的一个实例，可以说明这个问题

@DependsOn("rightDemo2")
    @Component
    public class RightDemo1 {
        private String name = "right demo 1";
    
        @Autowired
        private RightDemo2 rightDemo2;
    
        public RightDemo1() {
            System.out.println(name);
        }
    
        @PostConstruct
        public void init() {
            System.out.println(name + " _init");
        }
    }
    
    @Component
    public class RightDemo2 {
        private String name = "right demo 2";
    
        @Autowired
        private RightDemo1 rightDemo1;
    
        public RightDemo2() {
            System.out.println(name);
        }
    
        @PostConstruct
        public void init() {
            System.out.println(name + " _init");
        }
    }

注意上面的代码，虽然说有循环依赖，但是通过`@Autowired`注解方式注入的，所以不会导致应用启动失败，我们先看一下输出结果

![03b800b6b6a8fc4d85aa3d9e010e0aed.png][]

有意思的地方来了，我们通过`@DependsOn`注解来确保在创建`RightDemo1`之前，先得创建`RightDemo2`；

所以从构造方法的输出可以知道，先实例 RightDemo2, 然后实例 RightDemo1；

然后从初始化方法的输出可以知道，在上面这个场景中，虽然 RightDemo2 这个 bean 创建了，但是它的初始化代码在后面执行

> 题外话：  
> 有兴趣的同学可以试一下把上面测试代码中的 `@Autowired`的依赖注入删除，即两个 bean 没有相互注入依赖，再执行时，会发现输出顺序又不一样

## 2.3. BeanPostProcessor ##

最后再介绍一种非典型的使用方式，如非必要，请不要用这种方式来控制 bean 的加载顺序

先创建两个测试 bean

@Component
    public class HDemo1 {
        private String name = "h demo 1";
    
        public HDemo1() {
            System.out.println(name);
        }
    }
    
    @Component
    public class HDemo2 {
        private String name = "h demo 2";
    
        public HDemo2() {
            System.out.println(name);
        }
    }

我们希望 HDemo2 在 HDemo1 之前被加载，借助 BeanPostProcessor，我们可以按照下面的方式来实现

@Component
    public class DemoBeanPostProcessor extends InstantiationAwareBeanPostProcessorAdapter implements BeanFactoryAware {
        private ConfigurableListableBeanFactory beanFactory;
        @Override
        public void setBeanFactory(BeanFactory beanFactory) {
            if (!(beanFactory instanceof ConfigurableListableBeanFactory)) {
                throw new IllegalArgumentException(
                        "AutowiredAnnotationBeanPostProcessor requires a ConfigurableListableBeanFactory: " + beanFactory);
            }
            this.beanFactory = (ConfigurableListableBeanFactory) beanFactory;
        }
    
        @Override
        @Nullable
        public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
            // 在bean实例化之前做某些操作
            if ("HDemo1".equals(beanName)) {
                HDemo2 demo2 = beanFactory.getBean(HDemo2.class);
            }
            return null;
        }
    }

请将目标集中在`postProcessBeforeInstantiation`，这个方法在某个 bean 的实例化之前，会被调用，这就给了我们控制 bean 加载顺序的机会

![e636564d989832600ddc2c1f4e969801.png][]

看到这种骚操作，是不是有点蠢蠢欲动，比如我有个 bean，希望在应用启动之后，其他的 bean 实例化之前就被加载，用这种方式是不是也可以实现呢?

下面是一个简单的实例 demo，重写`DemoBeanPostProcessor`的`postProcessAfterInstantiation`方法，在 application 创建之后，就加载我们的 FDemo 这个 bean

@Override
    public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
        if ("application".equals(beanName)) {
            beanFactory.getBean(FDemo.class);
        }
    
        return true;
    }
    
    
    @DependsOn("HDemo")
    @Component
    public class FDemo {
        private String name = "F demo";
    
        public FDemo() {
            System.out.println(name);
        }
    }
    
    @Component
    public class HDemo {
        private String name = "H demo";
    
        public HDemo() {
            System.out.println(name);
        }
    }

从下图输出可以看出，`HDemo`, `FDemo`的实例化顺序放在了最前面了

![9c8c175c976b1b3984ea9b6c3980f05e.png][]

### 2.4. 小结 ###

在小结之前，先指出一下，一个完整的 bean 创建，在本文中区分了两块顺序

*  实例化 （调用构造方法）
 *  初始化 （注入依赖属性，调用`@PostConstruct`方法）

本文主要介绍了三种方式来控制 bean 的加载顺序，分别是

*  通过构造方法依赖的方式，来控制有依赖关系的 bean 之间初始化顺序，但是需要注意循环依赖的问题
 *  `@DependsOn`注解，来控制 bean 之间的实例顺序，需要注意的是 bean 的初始化方法调用顺序无法保证
 *  BeanPostProcessor 方式，来手动控制 bean 的加载顺序

# 3 参考： #

*  [SpringBoot系列教程之Bean加载顺序之错误使用姿势辟谣][SpringBoot_Bean]
 *  [https://segmentfault.com/a/1190000020873720][https_segmentfault.com_a_1190000020873720]
 *  工程：[https://github.com/liuyueyi/spring-boot-demo][https_github.com_liuyueyi_spring-boot-demo]
 *  项目: [https://github.com/liuyueyi/spring-boot-demo/blob/master/spring-boot/008-beanorder][https_github.com_liuyueyi_spring-boot-demo_blob_master_spring-boot_008-beanorder]

[755543141f36491c442c754f1f346b50.png]: /images/20221120/a5ed1c13858c4ba0a483574a6e4b676e.png
[a2d2335cd88cb1235534f90f55bd2f2a.png]: /images/20221120/eddd7e24d04f46f881d7a8c349f853ed.png
[5ba7691cc047cedb1e211635d2ead1c0.png]: /images/20221120/8523a018fa584e8081b5d8702b3234b0.png
[3a2210124d30fa3fa455378837d152aa.png]: /images/20221120/fd07b1f3ef8e4ff080208a6e336bcb9b.png
[6a4981065c461d14b74d8c93d321f461.png]: /images/20221120/5c930b1ad0f24404ad195585ef2d57aa.png
[9ec7cd22744089491c41506037c82d9f.png]: /images/20221120/e7eddf7074f34662892b067e631c59cd.png
[847f302b581bdde239e737e10e8b2be6.png]: /images/20221120/eaa12f975372407086055a1415038be3.png
[2ca84b3445055c410212af7c8ec5904a.png]: /images/20221120/3d95e7f8d0b94f7ba573c83ff7a89d4e.png
[cbe0bdb51d484d45d9901e079a17ea38.png]: /images/20221120/9c450271d11347b3a8d646ccd6986d7f.png
[461201c6c3f415780316b412471def50.png]: /images/20221120/b0dc63cca1bf4c48bbbee2fdc76f07d5.png
[03b800b6b6a8fc4d85aa3d9e010e0aed.png]: /images/20221120/a3aaa81953a642a0a81cfd8a9cbf6c02.png
[e636564d989832600ddc2c1f4e969801.png]: /images/20221120/ea8b543bc61e4c56b5dc77ee44f0ec6a.png
[9c8c175c976b1b3984ea9b6c3980f05e.png]: https://img-blog.csdnimg.cn/img_convert/9c8c175c976b1b3984ea9b6c3980f05e.png
[SpringBoot_Bean]: http://mp.weixin.qq.com/s?__biz=MzU3MTAzNTMzMQ==&mid=2247484360&idx=1&sn=97188fc2e5595b1ba67db2e2634262c3&chksm=fce71864cb9091721af0288a0a4c9a4145b62dd63c927db6f0a14ceb8f13faa23183499f06e4&scene=21#wechat_redirect
[https_segmentfault.com_a_1190000020873720]: https://segmentfault.com/a/1190000020873720
[https_github.com_liuyueyi_spring-boot-demo]: https://github.com/liuyueyi/spring-boot-demo
[https_github.com_liuyueyi_spring-boot-demo_blob_master_spring-boot_008-beanorder]: https://github.com/liuyueyi/spring-boot-demo/blob/master/spring-boot/008-beanorder