一灰灰blog 一灰灰blog
首页
  • InfluxDB
  • MongoDB
  • MySql
  • 基础系列
  • DB系列
  • 搜索系列
  • MQ系列
  • WEB系列
  • 中间件
  • 运维
  • SpringSecurity
  • SpringCloud
  • QuickAlarm
  • QuickCrawer
  • QuickFix
  • QuickMedia
  • QuickSpi
  • QuickTask
  • 高可用
  • 分类
  • 标签
  • 归档
  • 收藏
  • 关于
GitHub (opens new window)

一灰灰blog

资深搬运工
首页
  • InfluxDB
  • MongoDB
  • MySql
  • 基础系列
  • DB系列
  • 搜索系列
  • MQ系列
  • WEB系列
  • 中间件
  • 运维
  • SpringSecurity
  • SpringCloud
  • QuickAlarm
  • QuickCrawer
  • QuickFix
  • QuickMedia
  • QuickSpi
  • QuickTask
  • 高可用
  • 分类
  • 标签
  • 归档
  • 收藏
  • 关于
GitHub (opens new window)
  • 基础系列

    • 配置

    • AOP

    • Bean

      • 【基础系列】Bean之基本定义与使用
      • 【基础系列】Bean之自动加载
      • 【基础系列】Bean之动态注册
      • 【基础系列】Bean之注销与动态注册实现服务mock(应用篇)
      • 【基础系列】Bean之条件注入@Condition使用姿势
      • 【基础系列】Bean之@ConditionalOnBean与@ConditionalOnClass
      • 【基础系列】Bean之条件注入@ConditionalOnExpression
      • 【基础系列】Bean之条件注入@ConditionalOnProperty
      • 【基础系列】Bean之多实例选择
      • 【基础系列】FactoryBean及代理实现SPI机制的实例(应用篇)
      • 【配置系列】Bean加载顺序之错误使用姿势辟谣
      • 【基础系列】指定Bean初始化顺序的若干姿势
        • I. 环境搭建
        • II. 初始化顺序指定
          • 1. 构造方法依赖
          • 2. @DependOn 注解
          • 3. BeanPostProcessor
          • 4. 小结
        • II. 其他
          • 0. 项目 & 博文
          • 1. 一灰灰Blog
      • 【基础系列】从0到1实现一个自定义Bean注册器(应用篇)
      • 【基础系列】自动配置选择生效
      • 【基础系列-实战】如何指定bean最先加载(应用篇)
      • 【基础系列】实现一个自定义的@Autowired(应用篇)
      • 【基础系列】SpringContext.getBean()方法调用导致NPE?
    • SpEL

    • 事件

    • 国际化

    • 定时器

    • 日志

  • DB系列

  • 搜索系列

  • MQ系列

  • WEB系列

  • 中间件

  • 运维

  • SpringSecurity

  • SpringCloud

  • Spring系列
  • 基础系列
  • Bean
一灰灰
2019-10-29

【基础系列】指定Bean初始化顺序的若干姿势

上一篇博文介绍了@Order注解的常见错误理解,它并不能指定bean的加载顺序,那么问题来了,如果我需要指定bean的加载顺序,那应该怎么办呢?

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

  • 构造方法依赖
  • @DependOn 注解
  • BeanPostProcessor 扩展

# I. 环境搭建

我们的测试项目和上一篇博文公用一个项目环境,当然也可以建一个全新的测试项目,对应的配置如下:(文末有源码地址)

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.7</version>
    <relativePath/> <!-- lookup parent from update -->
</parent>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
    <java.version>1.8</java.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </pluginManagement>
</build>
<repositories>
    <repository>
        <id>spring-milestones</id>
        <name>Spring Milestones</name>
        <url>https://repo.spring.io/milestone</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# II. 初始化顺序指定

# 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 2";

    public CDemo2() {
        System.out.println(name);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

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

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

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

# 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);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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

在使用这个注解的时候,有一点需要特别注意,它能控制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");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

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

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

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

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

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

# 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);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

我们希望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;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

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

看到这种骚操作,是不是有点蠢蠢欲动,比如我有个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);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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

# 4. 小结

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

  • 实例化 (调用构造方法)
  • 初始化 (注入依赖属性,调用@PostConstruct方法)

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

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

# II. 其他

# 0. 项目 & 博文

  • 191023-SpringBoot系列教程之Bean加载顺序之错误使用姿势辟谣 (opens new window)

  • 工程:https://github.com/liuyueyi/spring-boot-demo (opens new window)

  • 项目: https://github.com/liuyueyi/spring-boot-demo/blob/master/spring-boot/008-beanorder (opens new window)

# 1. 一灰灰Blog

尽信书则不如,以上内容,纯属一家之言,因个人能力有限,难免有疏漏和错误之处,如发现bug或者有更好的建议,欢迎批评指正,不吝感激

下面一灰灰的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛

  • 一灰灰Blog个人博客 https://blog.hhui.top (opens new window)
  • 一灰灰Blog-Spring专题博客 http://spring.hhui.top (opens new window)

一灰灰blog

编辑 (opens new window)
#Bean#Order
上次更新: 2021/10/15, 19:56:22
【配置系列】Bean加载顺序之错误使用姿势辟谣
【基础系列】从0到1实现一个自定义Bean注册器(应用篇)

← 【配置系列】Bean加载顺序之错误使用姿势辟谣 【基础系列】从0到1实现一个自定义Bean注册器(应用篇)→

最近更新
01
【基础系列】基于maven多环境配置
04-25
02
【WEB系列】内嵌Tomcat配置Accesslog日志文件生成位置源码探索
04-24
03
【搜索系列】ES查询常用实例演示
04-18
更多文章>
Theme by Vdoing | Copyright © 2017-2022 一灰灰Blog
MIT License | 鄂ICP备18017282号 |
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式
×