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

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

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

原文: SpringBoot系列教程之Bean之指定初始化顺序的若干姿势

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>

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 1"; public CDemo2() {
System.out.println(name);
}
}

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

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

  • 需要有注入关系,如 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);
}
}

上面的注解放在 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");
}
}

注意上面的代码,虽然说有循环依赖,但是通过@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);
}
}

我们希望 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 加载顺序的机会

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

下面是一个简单的实例 demo,重写DemoBeanPostProcessorpostProcessAfterInstantiation方法,在 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的实例化顺序放在了最前面了

4. 小结

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

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

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

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

II. 其他

0. 项目

1. 一灰灰 Blog

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

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

SpringBoot系列教程之Bean之指定初始化顺序的若干姿势的更多相关文章

  1. SpringBoot系列教程之Bean加载顺序之错误使用姿势辟谣

    在网上查询 Bean 的加载顺序时,看到了大量的文章中使用@Order注解的方式来控制 bean 的加载顺序,不知道写这些的博文的同学自己有没有实际的验证过,本文希望通过指出这些错误的使用姿势,让观文 ...

  2. Spring 系列教程之 bean 的加载

    Spring 系列教程之 bean 的加载 经过前面的分析,我们终于结束了对 XML 配置文件的解析,接下来将会面临更大的挑战,就是对 bean 加载的探索.bean 加载的功能实现远比 bean 的 ...

  3. SpringBoot系列教程之Redis集群环境配置

    之前介绍的几篇redis的博文都是基于单机的redis基础上进行演示说明的,然而在实际的生产环境中,使用redis集群的可能性应该是大于单机版的redis的,那么集群的redis如何操作呢?它的配置和 ...

  4. kali linux 系列教程之metasploit 连接postgresql可能遇见的问题

    kali linux 系列教程之metasploit 连接postgresql可能遇见的问题 文/玄魂   目录 kali linux 下metasploit 连接postgresql可能遇见的问题. ...

  5. RabbitMQ系列教程之二:工作队列(Work Queues)(转载)

    RabbitMQ系列教程之二:工作队列(Work Queues)     今天开始RabbitMQ教程的第二讲,废话不多说,直接进入话题.   (使用.NET 客户端 进行事例演示)          ...

  6. WCF系列教程之WCF服务协定

    本文参考自:http://www.cnblogs.com/wangweimutou/p/4422883.html,纯属读书笔记,加深记忆 一.服务协定简介: 1.WCF所有的服务协定层里面的服务接口, ...

  7. WCF系列教程之WCF服务宿主与WCF服务部署

    本文参考自http://www.cnblogs.com/wangweimutou/p/4377062.html,纯属读书笔记,加深记忆. 一.简介 任何一个程序的运行都需要依赖一个确定的进程中,WCF ...

  8. kali Linux系列教程之BeFF安装与集成Metasploit

    kali Linux系列教程之BeFF安装与集成Metasploit 文/玄魂 kali Linux系列教程之BeFF安装与集成Metasploit 1.1 apt-get安装方式 1.2 启动 1. ...

  9. Kali Linux系列教程之OpenVas安装

    Kali Linux系列教程之OpenVas安装 文 /玄魂 目录 Kali Linux系列教程之OpenVas安装 前言 1.  服务器层组件 2.客户层组件 安装过程 Initial setup ...

随机推荐

  1. 浅谈 Vector

    目录 浅谈Vector 1.容器基本操作 2.vector 初始化 3.vector的赋值与swap 4.vector的增删改除 1.增加元素 2.访问元素 3.删除元素 4.元素的大小 浅谈Vect ...

  2. java数据结构——红黑树(R-B Tree)

    红黑树相比平衡二叉树(AVL)是一种弱平衡树,且具有以下特性: 1.每个节点非红即黑; 2.根节点是黑的; 3.每个叶节点(叶节点即树尾端NULL指针或NULL节点)都是黑的; 4.如图所示,如果一个 ...

  3. [技术栈]CRC校验原理及C#代码实现CRC16、CRC32计算FCS校验码

    1.CRC.FCS是什么 CRC,全称Cyclic Redundancy Check,中文名称为循环冗余校验,是一种根据网络数据包或计算机文件等数据产生简短固定位数校验码的一种信道编码技术,主要用来检 ...

  4. 规则引擎 - drools 使用讲解(简单版) - Java

    drools规则引擎 项目链接 现状: 运维同学(各种同学)通过后台管理界面直接配置相关规则,这里是通过输入框.下拉框等完成输入的,非常简单: 规则配置完毕后,前端请求后端,此时服务端根据参数(即规则 ...

  5. Eureka Server不剔除已关停的节点的问题

    由于Eureka拥有自我保护机制,当其注册表里服务因为网络或其他原因出现故障而关停时,Eureka不会剔除服务注册,而是等待其修复.这是AP的一种实现. 自我保护机制:Eureka Server在运行 ...

  6. Spring boot - 梳理 - 根本上说,Spring Boot项目只不过是一个普通的Spring项目,只是使用了Spring Boot的起步依赖和自动配置

    根本上说,Spring Boot项目只不过是一个普通的Spring项目,只是使用了Spring Boot的起步依赖和自动配置

  7. 十分钟快速学会Matplotlib基本图形操作

    在学习Python的各种工具包的时候,看网上的各种教程总是感觉各种方法很多很杂,参数的种类和个数也十分的多,理解起来需要花费不少的时间. 所以我在这里通过几个例子,对方法和每个参数都进行详细的解释,这 ...

  8. rabbitmq linux卸载

    rabbitmq是运行在erlang环境下的,所以卸载时应将erlang卸载. 1.卸载rabbitmq相关 卸载前先停掉rabbitmq服务,执行命令 $ service rabbitmq-serv ...

  9. .Net Core自动化部署系列(一):Jenkins + GitLab

    项目进行微服化改造后系统发布就变得愈为重要,因为持续集成导致部署变得越来越频繁,人工部署带来的一些问题日渐凸显,大家可能都有被系统部署线问题困扰过的经历. 本篇我们将会使用Jenkins+Gitlab ...

  10. 利用procedure批量插入数据

    正文   要求在页面查询到5000条数据,为了方便插入,准备用shell脚本写curl命令调用自己写的代码接口,但是速度慢,而且写的时候遇到点儿小问题,故用sql语句写了这个功能   由于operat ...