详解Spring 中如何控制2个bean中的初始化顺序

开发过程中有这样一个场景,2个 bean 初始化逻辑中有依赖关系,需要控制二者的初始化顺序。实现方式可以有多种,本文结合目前对 Spring 的理解,尝试列出几种思路。

场景

假设A,B两个 bean 都需要在初始化的时候从本地磁盘读取文件,其中B加载的文件,依赖A中加载的全局配置文件中配置的路径,所以需要A先于B初始化,此外A中的配置改变后也需要触发B的重新加载逻辑,所以A,B需要注入彼此。

对于下面的模型,问题简化为:我们需要initA()先于initB()得到执行。

@Service
public class A {
  @Autowired
  private B b;

  public A() {
    System.out.println("A construct");
  }

  @PostConstruct
  public void init() {
    initA();
  }

  private void initA() {
    System.out.println("A init");
  }
}

@Service
public class B {
  @Autowired
  private A a;

  public B() {
    System.out.println("B construct");
  }

  @PostConstruct
  public void init() {
    initB();
  }

  private void initB(){
    System.out.println("B init");
  }
}

方案一:立Flag

我们可以在业务层自己控制A,B的初始化顺序,在A中设置一个“是否初始化的”标记,B初始化前检测A是否得以初始化,如果没有则调用A的初始化方法,所谓的check-and-act。对于上述模型,实现如下:

@Service
public class A {

  private static volatile boolean initialized;

  @Autowired
  private B b;

  public A() {
    System.out.println("A construct");
  }

  @PostConstruct
  public void init() {
    initA();
  }

  public boolean isInitialized() {
    return initialized;
  }

  public void initA() {
    if (!isInitialized()) {
      System.out.println("A init");
    }
    initialized = true;
  }
}

@Service
public class B {

  @Autowired
  private A a;

  public B() {
    System.out.println("B construct");
  }

  @PostConstruct
  public void init() {
    initB();
  }

  private void initB() {
    if (!a.isInitialized()) {
      a.initA();
    }
    System.out.println("B init");
  }

执行效果:

A construct
B construct
A init
B init

这种立flag的方法好处是可以做到lazy initialization,但是如果类似逻辑很多的话代码中到处充斥着类似代码,不优雅,所以考虑是否框架本身就可以满足我们的需要。

方案二:使用DependsOn

Spring 中的 DependsOn 注解可以保证被依赖的bean先于当前bean被容器创建,但是如果不理解Spring中bean加载过程会对 DependsOn 有误解,自己也确实踩过坑。对于上述模型,如果在B上加上注解@DependsOn({"a"}),得到的执行结果是:

A construct
B construct
B init
A init

在这里问题的关键是:bean属性的注入是在初始化方法调用之前。

// 代码位置:AbstractAutowireCapableBeanFactory.doCreateBean
// 填充 bean 的各个属性,包括依赖注入
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
  // 调用初始化方法,如果是 InitializingBean 则先调用 afterPropertiesSet 然后调用自定义的init-method 方法
  exposedObject = initializeBean(beanName, exposedObject, mbd);
}

结合本例,发生的实际情况是,因为出现了循环依赖,A依赖B,加载B,B依赖A,所以得到了一个提前暴露的A,然后调用B的初始化方法,接着回到A的初始化方法。具体源码分析过程如下:

ApplicationContext 在 refresh 过程中的最后会加载所有的 no-lazy 单例。

本例中,先加载的bean A,最终通过无参构造器构造,然后,继续属性填充(populateBean),发现需要注入 bean B。所以转而加载 bean B(递归调用 getBean())。此时发现 bean B 需要 DependsOn("a"),在保存依赖关系(为了防止循环 depends)后,调用 getBean("a"),此时会得到提前暴露的 bean A ,所以继续 B 的加载,流程为: 初始化策略构造实例 -> 属性填充(同样会注入提前暴露的 bean A ) -> 调用初始化方法。

// 代码位置:AbstractBeanFactory.doGetBean
// Guarantee initialization of beans that the current bean depends on. 实例化依赖的 bean
    String[] dependsOn = mbd.getDependsOn();
    if (dependsOn != null) {
      for (String dep : dependsOn) {
        if (isDependent(beanName, dep)) {
          throw new BeanCreationException(mbd.getResourceDescription(),
              beanName, "Circular depends-on relationship between '"
              + beanName + "' and '" + dep + "'");
        }
        registerDependentBean(dep, beanName); // 缓存 bean 依赖的关系
        getBean(dep);
      }
    }

得到提前暴露的 bean A的过程为:

此时此刻,bean A 的属性注入完成了, 返回到调用初始化方法,所以表现的行为是:构造A -> 构造B -> B初始化 -> A初始化。

DependsOn只是保证的被依赖的bean先于当前bean被实例化,被创建,所以如果要采用这种方式实现bean初始化顺序的控制,那么可以把初始化逻辑放在构造函数中,但是复杂耗时的逻辑仿造构造器中是不合适的,会影响系统启动速度。

方案三:容器加载bean之前

Spring 框架中很多地方都为我们提供了扩展点,很好的体现了开闭原则(OCP)。其中 BeanFactoryPostProcessor 可以允许我们在容器加载任何bean之前修改应用上下文中的BeanDefinition(从XML配置文件或者配置类中解析得到的bean信息,用于后续实例化bean)。

在本例中,就可以把A的初始化逻辑放在一个 BeanFactoryPostProcessor 中。

@Component
public class ABeanFactoryPostProcessor implements BeanFactoryPostProcessor {
  @Override
  public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException {
    A.initA();
  }
}

执行效果:

A init
A construct
B construct
B init

这种方式把A中的初始化逻辑放到了加载bean之前,很适合加载系统全局配置,但是这种方式中初始化逻辑不能依赖bean的状态。

方案四:事件监听器的有序性

Spring 中的 Ordered 也是一个很重要的组件,很多逻辑中都会判断对象是否实现了 Ordered 接口,如果实现了就会先进行排序操作。比如在事件发布的时候,对获取到的 ApplicationListener 会先进行排序。

// 代码位置:AbstractApplicationEventMulticaster.ListenerRetriever.getApplicationListeners()
public Collection<ApplicationListener<?>> getApplicationListeners() {
    LinkedList<ApplicationListener<?>> allListeners = new LinkedList<ApplicationListener<?>>();
    for (ApplicationListener<?> listener : this.applicationListeners) {
      allListeners.add(listener);
    }
    if (!this.applicationListenerBeans.isEmpty()) {
      BeanFactory beanFactory = getBeanFactory();
      for (String listenerBeanName : this.applicationListenerBeans) {
        try {
          ApplicationListener<?> listener = beanFactory.getBean(listenerBeanName, ApplicationListener.class);
          if (this.preFiltered || !allListeners.contains(listener)) {
            allListeners.add(listener);
          }
        } catch (NoSuchBeanDefinitionException ex) {
          // Singleton listener instance (without backing bean definition) disappeared -
          // probably in the middle of the destruction phase
        }
      }
    }
    AnnotationAwareOrderComparator.sort(allListeners); // 排序
    return allListeners;
  }

所以可以利用事件监听器在处理事件时的有序性,在应用上下文 refresh 完成后,分别实现A,B中对应的初始化逻辑。

@Component
public class ApplicationListenerA implements ApplicationListener<ApplicationContextEvent>, Ordered {
  @Override
  public void onApplicationEvent(ApplicationContextEvent event) {
    initA();
  }

  @Override
  public int getOrder() {
    return Ordered.HIGHEST_PRECEDENCE; // 比 ApplicationListenerB 优先级高
  }

  public static void initA() {
    System.out.println("A init");
  }
}

@Component
public class ApplicationListenerB implements ApplicationListener<ApplicationContextEvent>, Ordered{
  @Override
  public void onApplicationEvent(ApplicationContextEvent event) {
    initB();
  }

  @Override
  public int getOrder() {
    return Ordered.HIGHEST_PRECEDENCE -1;
  }

  private void initB() {
    System.out.println("B init");
  }
}

执行效果:

A construct
B construct
A init
B init

这种方式就是站在事件响应的角度,上下文加载完成后,先实现A逻辑,然后实现B逻辑。

总结

在平时的开发中使用的可能都是一个语言,一个框架的冰山一角,随着对语言,对框架的不断深入,你会发现更多的可能。本文只是基于目前对于 Spring 框架的理解做出的尝试,解决一个问题可能有多种方式,其中必然存在权衡选择,取决于对业务对技术的理解。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Java中Spring获取bean方法小结

    Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架,如何在程序中获取Spring配置的bean呢? Bean工厂(com.springframework.beans.factory.BeanFactory)是Spring框架最核心的接口,它提供了高级IoC的配置机制.BeanFactory使管理不同类型的Java对象成为可能,应用上下文(com.springframework.context.ApplicationContext)建立在BeanFactory基础之上,提供

  • Spring的自动装配Bean的三种方式

    spring的自动装配功能的定义:无须在Spring配置文件中描述javaBean之间的依赖关系(如配置<property>.<constructor-arg>).IOC容器会自动建立javabean之间的关联关系. 如果没有采用自动装配的话,手动装配我们通常在配置文件中进行实现:一下代码就是手动装配: <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="ht

  • 通过spring用beanshell实现java接口示例

    说明 1.通过脚本语言让JAVA执行动态代码2.用Spring可以将脚本语言代理成Java接口的实现类3.Spring2.5.6中支持三种脚本语言ruby,Groovy,BeanShell4.示例中为spring与beanshell结合5.依赖spring2.5.6,bsh-2.0b4 复制代码 代码如下: import org.junit.Test;import org.springframework.scripting.bsh.BshScriptUtils; import bsh.EvalE

  • 详解Spring Boot 使用Java代码创建Bean并注册到Spring中

    从 Spring3.0 开始,增加了一种新的途经来配置Bean Definition,这就是通过 Java Code 配置 Bean Definition. 与Xml和Annotation两种配置方式不同点在于: 前两种Xml和Annotation的配置方式为预定义方式,即开发人员通过 XML 文件或者 Annotation 预定义配置 bean 的各种属性后,启动 spring 容器,Spring 容器会首先解析这些配置属性,生成对应都?Bean Definition,装入到 DefaultL

  • 详解Spring简单容器中的Bean基本加载过程

    本篇将对定义在 XMl 文件中的 bean,从静态的的定义到变成可以使用的对象的过程,即 bean 的加载和获取的过程进行一个整体的了解,不去深究,点到为止,只求对 Spring IOC 的实现过程有一个整体的感知,具体实现细节留到后面用针对性的篇章进行讲解. 首先我们来引入一个 Spring 入门使用示例,假设我们现在定义了一个类 org.zhenchao.framework.MyBean ,我们希望利用 Spring 来管理类对象,这里我们利用 Spring 经典的 XMl 配置文件形式进行

  • 解析Java中如何获取Spring中配置的bean

    一.什么是Spring?Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架 二.如何在程序中获取Spring配置的bean呢?方法一:在初始化时保存ApplicationContext对象代码: 复制代码 代码如下: ApplicationContext ac = new FileSystemXmlApplicationContex("applicationContext.xml");    ac.getBean("beanId"); 说明:

  • 详解Java的Spring框架中bean的注入集合

    使用value属性和使用<property>标签的ref属性在你的bean配置文件中的对象引用,这两种情况下可以处理单值到一个bean,如果你想通过多元值,如Java Collection类型List, Set, Map 及 Properties.要处理这种情况,Spring提供了四种类型的如下集合的配置元素: 可以使用<list> 或<set> 来连接任何实现java.util.Collection或数组. 会遇到两种情况(a)将收集的直接的值及(b)传递一个bean

  • 详解Java的Spring框架中bean的定义以及生命周期

    bean的定义 形成应用程序的骨干是由Spring IoC容器所管理的对象称为bean.bean被实例化,组装,并通过Spring IoC容器所管理的对象.这些bean由容器提供,例如,在XML的<bean/>定义,已经看到了前几章的形式配置元数据创建. bean定义包含所需要的容器要知道以下称为配置元数据的信息: 如何创建一个bean Bean 生命周期的详细信息 Bean 依赖关系 上述所有配置元数据转换成一组的下列属性构成每个bean的定义. Spring配置元数据 Spring IoC

  • 浅谈spring容器中bean的初始化

    当我们在spring容器中添加一个bean时,如果没有指明它的scope属性,则默认是singleton,也就是单例的. 例如先声明一个bean: public class People { private String name; private String sex; public String getName() { return name; } public void setName(String name) { this.name = name; } public String get

  • Spring中多配置文件及引用其他bean的方式

    Spring多配置文件有什么好处? 按照目的.功能去拆分配置文件,可以提高配置文件的可读性与维护性,如将配置事务管理.数据源等少改动的配置与配置bean单独分开. Spring读取配置文件的几种方式: 1.使用Spring自身提供的ApplicationContext方式读取 在Java程序中可以使用ApplicationContext两个实现类ClassPathXmlApplicationContext以及FileSystemXmlApplicationContext来读取多个配置文件,他们的

随机推荐