Spring 循环引用(三)AbstractFactoryBean 如何解决循环依赖

Spring 循环引用(三)AbstractFactoryBean 如何解决循环依赖

Spring 系列目录:https://www.cnblogs.com/binarylei/p/10198698.html

本章讨论的范围:AbstractFactoryBean 创建单例 Bean 过程中出现的循环依赖问题,多例 Bean 的创建根本不会出现循环依赖,因为会直接抛异常。

1. 循环依赖问题

在 AbstractFactoryBean 中有一个特殊的属性 earlySingletonInstance,用于提前将 bean 暴露。第一次看到这个属性很奇怪:

  1. Spring IoC 容器已经解决了单例 bean 非构造器注入时的循环依赖问题,这里为什么还需要解决循环依赖?
  2. 对于单例 bean 而言,只有在 FactoryBean 初始化完成后才能获取对象,也就是先执行 afterPropertiesSet 再执行 getObject 方法,也就是说 initialized 在 getObject 应该为 true 才对,有可能为 false 吗?

带着疑问,我们先看一下代码:

private T singletonInstance;        # FactoryBean创建的对象bean
private T earlySingletonInstance;	# 提前暴露bean,用于解决循环依赖

AbstractFactoryBean 初始化完成后调用 afterPropertiesSet 创建对象,然后通过 getObject 获取对象。

@Override
public void afterPropertiesSet() throws Exception {
    if (isSingleton()) {
        this.initialized = true;
        this.singletonInstance = createInstance();
        this.earlySingletonInstance = null;
    }
}

@Override
public final T getObject() throws Exception {
    if (isSingleton()) {
        // 单例,解决循环依赖,先生成代理对象,当getObject时才生成对象
        return (this.initialized ? this.singletonInstance : getEarlySingletonInstance());
    } else {
        // 多例,不会解决循环依赖,直接报错
        return createInstance();
    }
}

说明: 正常流程下,AbstractFactoryBean 初始化完成后,调用 afterPropertiesSet 创建对象,此时 initialized = true 且对象创建完成,当 getObject 时直接返回 singletonInstance。什么情况下 initialized 会为 false 呢?

我的第一想法是,这两个 FactoryBean 相互依赖,形成 AB - BA 的关系,但心里也有点惴惴不安,因为 Spring IoC 应该已经解决了这类循环依赖的问题,不管怎样,先进行一番实验再说。

2. 准备实验

class FactoryBeanA extends AbstractFactoryBean<BeanA> {
    @Override
    public Class<?> getObjectType() {
        return BeanA.class;
    }
    @Override
    protected BeanA createInstance() throws Exception {
        return new BeanAImpl();
    }
}

class FactoryBeanB extends AbstractFactoryBean<BeanB> {
    @Override
    public Class<?> getObjectType() {
        return BeanB.class;
    }
    @Override
    protected BeanB createInstance() throws Exception {
        return new BeanBImpl();
    }
}

class BeanAImpl implements BeanA {
}
class BeanBImpl implements BeanB {
}

interface BeanA {
}
interface BeanB {
}

说明: 因为 AbstractFactoryBean 通过 getEarlySingletonInstance 生成的代理对象是通过 JDK 的动态代理生成的,所以 BeanAImpl 和 BeanBImpl 必须有接口。

猜想1:两个 FactoryBean 直接互相依赖

在 FactoryBeanA 和 FactoryBeanB 中添加如下代码,FactoryBeanA 和 FactoryBeanB 创建时形成相互依赖关系:

class FactoryBeanA extends AbstractFactoryBean<BeanA> {
    @Autowired
    private FactoryBeanB factoryBeanB;
}

class FactoryBeanB extends AbstractFactoryBean<BeanA> {
    @Autowired
    private FactoryBeanA factoryBeanA;
}

说明: 果不其然,容器运行时根本没有调用到 getEarlySingletonInstance() 方法,也就是没有出现 FactoryBean 还未初始化完成就需要调用 getObject 创建对象的情况,当然 FactoryBeanA 和 FactoryBeanB 创建过程肯定是有循环依赖的。

猜想2:两个 FactoryBean#getObject 互相依赖

在 FactoryBeanA 和 FactoryBeanB 中添加如下代码:

class FactoryBeanA extends AbstractFactoryBean<BeanA> {
    @Autowired
    private BeanB beanB;
}

class FactoryBeanB extends AbstractFactoryBean<BeanA> {
    @Autowired
    private BeanA beanA;
}

说明: 果然,容器运行时调用到 getEarlySingletonInstance() 方法。也就是出现了 FactoryBean 还未初始化完,但要调用 getObject 创建对象的情况,这是肯定不行了,这就是循环依赖产生的根据原因,如何解决呢?

总结: 两个猜想说明

  1. 猜想 1 :Spring IoC 已经解决了 Bean 创建过程中的相互依赖,即 FactoryBeanA 和 FactoryBeanB 直接相互依赖问题。
  2. 猜想 2 :AbstractFactoryBean 的 earlySingletonInstance 属性解决的正是 FactoryBean#getObject() 时产生的相互依赖问题。

3. 原因分析

说明: AbstractFactoryBean 循环依赖原因分析

  1. 执行第②步时,FactoryBeanA 在初始化时需要注入 BeanB,此时 FactoryBeanA 正在初始化。
  2. 注入 BeanB 时,又需要执行第⑦步来初始化 BeanA,但此时 FactoryBeanA 都还未初始化完成(FactoryBeanA 在第⑩步执行 afterPropertiesSet 才初始化完成),怎么能调用 FactoryBeanA#getObject 来创建 BeanA 对象呢?这样就陷入了循环依赖中。

4. 解决方案

当然,我们很容易想到,像 Spring IoC 一样,如果我们在 FactoryBeanA#getObject 时,创建一个代理对象 earlySingletonInstance 提前暴露到出去,这样 FactoryBeanA#getObject 不就可以正常初始化了吗。事实上 AbstractFactoryBean 也正是这么做的。

说明: 从时序图可以看到

  1. 第10 步:此时 FactoryBeanA 未初始化完成,因此 getObject 方法通过 getEarlySingletonInstance 返回了一个代理对象 earlySingletonInstance,真实的对象 beanA 实际上并没有创建。
  2. 第14 步:此时 FactoryBeanA 调用 afterPropertiesSet 完成初始化,调用 createInstance 创建真实的对象 beanA。

我们看一下 getEarlySingletonInstance 方法,会生成一个代理对象 earlySingletonInstance,当调用 getObject 时会直接将这个代理对象返回。

private T getEarlySingletonInstance() throws Exception {
    Class<?>[] ifcs = getEarlySingletonInterfaces();
    if (ifcs == null) {
        throw new FactoryBeanNotInitializedException(
            getClass().getName() + " does not support circular references");
    }
    if (this.earlySingletonInstance == null) {
        this.earlySingletonInstance = (T) Proxy.newProxyInstance(
            this.beanClassLoader, ifcs, new EarlySingletonInvocationHandler());
    }
    return this.earlySingletonInstance;
}

说明: earlySingletonInstance 通过 JDK 的动态代理生成代理对象,所以如果 FactoryBean 要支持循环依赖,必须有接口。

5. 还有什么问题

到目前为止,似乎一切顺利,FactoryBean 的循环依赖通过提前暴露动态代理对象,避免了死循环,但真的没有问题了吗?

  1. FactoryBeanB 中注入 BeaA 时,FactoryBeanA 还未初始化完成,注入的是一个代理对象 earlySingletonInstance。
  2. Spring IoC 中,FactoryBeanA 初始化完成时,调用 afterPropertiesSet 完成初始化,真正暴露到容器中的是实例对象 singletonInstance。
  3. earlySingletonInstance 和 singletonInstance 是一个东西吗?如果不是,是不是可能造成数据不一致的情况,那不违反了单例原则吗?

你可能对下面这段代码感到困惑,因为本章中我们讨论的都是单例 Bean 的问题,怎么可能不相等呢?

@Test
public void test() {
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(
        CircularFactoryBeanDemo.class);

    BeanA beanA = context.getBean(BeanA.class);
    FactoryBeanB factoryBeanB = context.getBean(FactoryBeanB.class);

    Assert.assertNotEquals(beanA, factoryBeanB.getBeanA());
}

说明: 首先 earlySingletonInstance 是 JDK 代理对象,singletonInstance 是真正的实例,它们俩肯定不是一个东西。EarlySingletonInvocationHandler 正是代理了 singletonInstance 对象,即 earlySingletonInstance 底层其实也是使用 singletonInstance,这样就保证了数据的一致性,并不违反单例原则。

private class EarlySingletonInvocationHandler implements InvocationHandler {
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // getSingletonInstance() 直接返回了 singletonInstance 
        return method.invoke(getSingletonInstance(), args);
    }
}

说明: 既然 earlySingletonInstance 底层实际上也是使用 singletonInstance 对象,那至少数据肯定是一致的。

下图显示了这两个 beanA 之间的关系:

还有什么问题?现在我们已经知道 earlySingletonInstance 和 singletonInstance 是代理关系,我们如果想获取 singletonInstance 的注解等信息,可能通过正常的途径就无法获取了。特别是现在元编程大行其道的情况下,我们很多时候都需要获取类的注解、方法参数等信息,只能通过原始的对象类型获取。此时要特别小心。

6. 总结

  1. 和 Spring IoC 一样,AbstractFactoryBean 也是通过提前暴露代理对象 earlySingletonInstance 解决循环依赖问题。
  2. earlySingletonInstance 是通过 JDK 动态代理实现的,底层代理的正是真实对象 singletonInstance,这样保证了数据的一致性,也并不违反单例原则。正因为是 JDK 动态代理,所以想解决这类循环依赖的问题,Bean 必须有接口。
  3. earlySingletonInstance 和 singletonInstance 并不是同一个对象,导致 "注入的 beanA" 和 "容器中暴露的 beanA" 并不是同一个对象。实际上 Spring IoC 循环依赖也有类似的问题。
  4. 同样是因为上述问题,如果想获取类的注解、方法参数等信息,只能通过原始的对象类型获取。特别是现在元编程大行其道的情况下,此时要特别小心。
  5. 最后,虽然 Spring 对循环依赖问题提供了部分解决方案,但实际工作中,如果出现了循环依赖的问题,首先想到的应该是通过重构代码来解耦,而不是听之任之,放任不管。

7. 补充说明:循环依赖+类型推断引发的 Bug

到现在为止,AbstractFactoryBean 循环依赖的问题已经解决,再将上述案例稍稍改动一下,将 FactoryBeanA 和 FactoryBeanB 上的泛型倒掉,重新测试一下:

private static class FactoryBeanA extends AbstractFactoryBean {  
    @Override
    public Class<?> getObjectType() {
        return BeanA.class;
    }
}
private static class FactoryBeanB extends AbstractFactoryBean {
    @Override
    protected Object createInstance() throws Exception {
        return new BeanBImpl();
    }
}

再次测试,这里你会发现初始化 BeanA 时居然抛出 NoSuchBeanDefinitionException 异常。

@Test
public void test2() {
    DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory();
    beanFactory.addBeanPostProcessor(beanFactory.createBean(
        AutowiredAnnotationBeanPostProcessor.class));

    beanFactory.registerBeanDefinition("userA",BeanDefinitionBuilder
        .rootBeanDefinition(FactoryBeanA.class).getBeanDefinition());
    beanFactory.registerBeanDefinition("userB", BeanDefinitionBuilder
        .rootBeanDefinition(FactoryBeanB.class).etBeanDefinition());

    BeanA beanA = beanFactory.getBean("userA");
}

说明: 在猜想 2 中还可以正常运行的案例,此时居然抛出 NoSuchBeanDefinitionException 异常,明明容器中已经注册了 BeanA 和 BeanB,简直让人匪夷所思。

最简单的解决方案是:不要有循环依赖,因为你不知道这雷什么时候会爆。

当然这两个案例的最大的区别是 FactoryBean 类上一个有泛型,一个没有泛型。当 FactoryBeanB 注入 BeanA 时,需要根据类型 BeanA 查找对应的 bean,即 beanFactory.getBean(BeanA.class)。此时 FactoryBeanA 正在初始化,不可以根据 FactoryBeanA#getObjectType 获取对象类型,但可以根据其泛型获取对象类型。在本例中,FactoryBeanA 没有对应的泛型,也就在容器中找不到 BeanA,无法注入 FactoryBeanB,进而抛出 NoSuchBeanDefinitionException。

说明: 在第⑥步,FactoryBeanB 注入 BeanA 时,需要在 Spring IoC 容器中根据 BeanA 类型查找依赖。因为 FactoryBeanA 和 FactoryBeanB 都外于正在创建的状态中,此时如果执行每⑨步 getSingletonFactoryBeanForTypeCheck 获取对象类型时会返回 null,也就是说不能通过 FactoryBean#getObjectType() 获取对象类型,但可以通过 FactoryBean 泛型获取对象类型。

// 部分初始化FactoryBean,调用getObjectType获取对象类型。
// 所谓部分初始化指的是只实例化FactoryBean对象,不进行属性注入。
// 部分初始化的FactoryBean对象,会缓存到factoryBeanInstanceCache集合中,当真正创建时从该集合中移除
private FactoryBean<?> getSingletonFactoryBeanForTypeCheck(String beanName, RootBeanDefinition mbd) {
    ...
    if (isSingletonCurrentlyInCreation(beanName) ||
        (mbd.getFactoryBeanName() != null && isSingletonCurrentlyInCreation(mbd.getFactoryBeanName()))) {
        return null;
    }
    ...
}

每天用心记录一点点。内容也许不重要,但习惯很重要!

posted on 2020-02-11 08:33  binarylei  阅读(1529)  评论(1编辑  收藏  举报

导航