放肆的自由自在🍺|

ywwwik

园龄:2年5个月粉丝:1关注:4

2023-08-19 14:30阅读: 58评论: 0推荐: 0

Spring循环依赖即解决方案

本文会回答什么是循环依赖,Spring怎么解决循环依赖,Spring对于循环依赖无法解决的场景三个问题

1. 什么是循环依赖?

循环依赖其实就是循环引用,也就是两个或则两个以上的bean互相持有对方,最终形成闭环。比如A依赖于B,B依赖于C,C又依赖于A。如下图:

注意,这里不是函数的循环调用,是对象的相互依赖关系。循环调用其实就是一个死循环,除非有终结条件。

Spring中循环依赖场景有:

(1)构造器的循环依赖
(2)field属性的循环依赖。

思考:在编码的过程中,有时候会存在这样的诉求,那这时候,程序应该先创建哪个对象?

Spring怎么解决循环依赖:

Spring的循环依赖的理论依据其实是基于Java的引用传递,当我们获取到对象的引用时,对象的field或则属性是可以延后设置的(但是构造器必须是在获取引用之前)。

那spring一个对象产生需要以下几个步骤

(1)createBeanInstance:实例化,其实也就是调用对象的构造方法实例化对象

(2)populateBean:填充属性,这一步主要是多bean的依赖属性进行填充

(3)initializeBean:调用spring xml中的init 方法。

复制代码
/**
     * 实际创建指定的bean。 此时,预创建处理已经发生,
     * 例如 检查{@code postProcessBeforeInstantiation}回调。
     * 区分默认bean实例化、使用工厂方法和自动装配构造函数。
     */
    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
        // Instantiate the bean.
        BeanWrapper instanceWrapper = null;
        .....
        
        if (instanceWrapper == null) {
            instanceWrapper = createBeanInstance(beanName, mbd, args);
        }
        .....
        // Eagerly cache singletons to be able to resolve circular references
        // even when triggered by lifecycle interfaces like BeanFactoryAware.
        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            if (logger.isDebugEnabled()) {
                logger.debug("Eagerly caching bean '" + beanName +
                        "' to allow for resolving potential circular references");
            }
            //添加到三级缓存中
            addSingletonFactory(beanName, new ObjectFactory<Object>() {
                @Override
                public Object getObject() throws BeansException {
                    return getEarlyBeanReference(beanName, mbd, bean);
                }
            });
        }
 
        // Initialize the bean instance.
        Object exposedObject = bean;
        try {
            //填充依赖的bean实例。
            populateBean(beanName, mbd, instanceWrapper);
            if (exposedObject != null) {
                //调用spring xml中的init 方法。
                exposedObject = initializeBean(beanName, exposedObject, mbd);
            }
        }
        ......
        return exposedObject;
    }
复制代码

其实我们简单的思考一下就发现,出现循环依赖的问题主要在 (1)和 (2)两个步骤,也就是也就是(1)中构造器循环依赖和(2)中field循环依赖。

注:createBeanInstance(...)该步骤会调用构造方法

复制代码
/**
     *使用适当的实例化策略为指定的bean创建一个新实例:
     * 工厂方法,构造函数自动装配或简单实例化。
     * @return BeanWrapper for the new instance
     */
    protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
        
        .......
        // Need to determine the constructor...(确定构造函数)
        Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
        if (ctors != null ||
                mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
                mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
            return autowireConstructor(beanName, mbd, ctors, args);
        }
 
        // No special handling: simply use no-arg constructor.(使用默认无参构造器,
        //编程时候要求尽量保留无参构造器,因为你不知道哪个框架在哪会用到)
        return instantiateBean(beanName, mbd);
    }
复制代码

如何解决?

那么我们要解决循环引用也应该从初始化过程着手,对于单例来说,在Spring容器整个生命周期内,有且只有一个对象,所以很容易想到这个对象应该存在Cache中,Spring为了解决单例的循环依赖问题,使用了三级缓存

复制代码
/** Cache of singleton objects: bean name --> bean instance */
    //单例对象的cache
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);
 
    /** Cache of singleton factories: bean name --> ObjectFactory */
    //单例对象工厂的cache
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
 
    /** Cache of early singleton objects: bean name --> bean instance */
    //提前暴光的单例对象的Cache
    private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
复制代码

步骤:

1.Spring首先从一级缓存singletonObjects中获取。

2.如果获取不到,并且对象正在创建中,就再从二级缓存earlySingletonObjects中获取。

3.如果还是获取不到且允许singletonFactories通过getObject()获取,就从三级缓存singletonFactory.getObject()(三级缓存)获取.

4.如果从三级缓存中获取到就从singletonFactories中移除,并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。

复制代码
/**
     * 返回指定名称(原始)单例对象。
     * 检查已经实例化的单例,也允许对当前创建的单例对象的早期引用(用于解决循环依赖)
     * 
     * @return the registered singleton object, or {@code null} if none found
     */
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        //Spring首先从一级缓存singletonObjects中获取。
        Object singletonObject = this.singletonObjects.get(beanName);
 
        //isSingletonCurrentlyInCreation()判断当前单例bean是否正在创建中,也就是没有初始化
        //完成(比如A的构造器依赖了B对象所以得先去创建B对象, 或则在A的populateBean过程中依
        //赖了B对象,得先去创建B对象,这时的A就是处于创建中的状态。)
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
 
                //尝试从二级缓存earlySingletonObjects中获取。
                singletonObject = this.earlySingletonObjects.get(beanName);
 
                //allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象
                if (singletonObject == null && allowEarlyReference) {
                    //尝试从三级缓存singletonFactory.getObject()(三级缓存)获取
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
 
                    //如果从三级缓存中获取到
                    // 则从singletonFactories中移除,并放入earlySingletonObjects中。
                    // 其实也就是从三级缓存移动到了二级缓存。
                    if (singletonFactory != null) {
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    } 
复制代码

从三级缓存的分析来看,Spring解决循环依赖的诀窍就在于singletonFactories这个滴三级cache。这个cache的类型是ObjectFactory,定义如下:

/**
 * 定义一个可以返回对象实例的工厂
 * @param <T>
 */
public interface ObjectFactory<T> {
    T getObject() throws BeansException;
}

接口在这个方法中被引用,该接口在doCreateBean(...) 方法中 实例化步骤进行了调用

复制代码
/**
     *  添加一个构建指定单例对象的单例工厂
     *  紧急注册单例对象,用于解决解决循环依赖问题
     * To be called for eager registration of singletons, e.g. to be able to
     * resolve circular references.
     */
    protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
        Assert.notNull(singletonFactory, "Singleton factory must not be null");
        synchronized (this.singletonObjects) {
            if (!this.singletonObjects.containsKey(beanName)) {
                this.singletonFactories.put(beanName, singletonFactory);
                this.earlySingletonObjects.remove(beanName);
                this.registeredSingletons.add(beanName);
            }
        }
    }
复制代码

这里就是解决循环依赖的关键,这段代码发生在doCreateBean(...) 方法中 createBeanInstance之后,也就是说单例对象此时已经被创建出来(调用了构造器)。这个对象已经被生产出来了,虽然还不完美(还没有进行初始化的第二步和第三步),但是已经能被人认出来了(根据对象引用能定位到堆中的对象),所以Spring此时将这个对象提前曝光出来让大家认识,让大家使用。

这样做有什么好处呢?让我们来分析一下“A的某个field或者setter依赖了B的实例对象,同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步,并且将自己提前曝光到singletonFactories中,此时进行初始化的第二步,发现自己依赖对象B,此时就尝试去get(B),发现B还没有被create,所以走create流程,B在初始化第一步的时候发现自己依赖了对象A,于是尝试get(A),尝试一级缓存singletonObjects(肯定没有,因为A还没初始化完全),尝试二级缓存earlySingletonObjects(也没有),尝试三级缓存singletonFactories,由于A通过ObjectFactory将自己提前曝光了,所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全,但是总比没有好呀),B拿到A对象后顺利完成了初始化阶段1、2、3,完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中,A此时能拿到B的对象顺利完成自己的初始化阶段2、3,最终A也完成了初始化,进去了一级缓存singletonObjects中,而且更加幸运的是,由于B拿到了A的对象引用,所以B现在hold住的A对象完成了初始化。(简单来说,就是spring创造了一个 循环依赖的结束点标识)

怎么样的循环依赖无法处理?
(1)因为加入singletonFactories三级缓存的前提是执行了构造器来创建半成品的对象,所以构造器的循环依赖没法解决。因此,Spring不能解决“A的构造方法中依赖了B的实例对象,同时B的构造方法中依赖了A的实例对象”这类问题了!

(2)spring不支持原型(prototype)bean属性注入循环依赖,不同于构造器注入循环依赖会在创建spring容器context时报错,它会在用户执行代码如context.getBean()时抛出异常。因为对于原型bean,spring容器只有在需要时才会实例化,初始化它。

因为spring容器不缓存prototype类型的bean,使得无法提前暴露出一个创建中的bean。spring容器在获取prototype类型的bean时,如果因为环的存在,检测到当前线程已经正在处理该bean时,就会抛出异常。核心代码

复制代码
public abstract class AbstractBeanFactory{
    /** Names of beans that are currently in creation */
    private final ThreadLocal<Object> prototypesCurrentlyInCreation =
            new NamedThreadLocal<>("Prototype beans currently in creation");
            
    protected boolean isPrototypeCurrentlyInCreation(String beanName) {
        Object curVal = this.prototypesCurrentlyInCreation.get();
        // 如果beanName已经存在于正在处理中的prototype类型的bean集中,后面会抛出异常
        return (curVal != null &&
                (curVal.equals(beanName) || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName))));
    }
}
复制代码

本文作者:ywwwik

本文链接:https://www.cnblogs.com/ywwwik/p/17642449.html

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   ywwwik  阅读(58)  评论(0编辑  收藏  举报
(评论功能已被禁用)
相关博文:
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异
· 三行代码完成国际化适配,妙~啊~
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起
  1. 1 404 not found REOL
404 not found - REOL
00:00 / 00:00
An audio error has occurred.

作曲 : Reol

作词 : Reol

fade away...do over again...

fade away...do over again...

歌い始めの一文字目 いつも迷ってる

歌い始めの一文字目 いつも迷ってる

どうせとりとめのないことだけど

伝わらなきゃもっと意味がない

どうしたってこんなに複雑なのに

どうしたってこんなに複雑なのに

噛み砕いてやらなきゃ伝わらない

ほら結局歌詞なんかどうだっていい

僕の音楽なんかこの世になくたっていいんだよ

Everybody don't know why.

Everybody don't know why.

Everybody don't know much.

僕は気にしない 君は気付かない

何処にももういないいない

Everybody don't know why.

Everybody don't know why.

Everybody don't know much.

忘れていく 忘れられていく

We don't know,We don't know.

目の前 広がる現実世界がまた歪んだ

目の前 広がる現実世界がまた歪んだ

何度リセットしても

僕は僕以外の誰かには生まれ変われない

「そんなの知ってるよ」

気になるあの子の噂話も

シニカル標的は次の速報

麻痺しちゃってるこっからエスケープ

麻痺しちゃってるこっからエスケープ

遠く遠くまで行けるよ

安定なんてない 不安定な世界

安定なんてない 不安定な世界

安定なんてない きっと明日には忘れるよ

fade away...do over again...

fade away...do over again...

そうだ世界はどこかがいつも嘘くさい

そうだ世界はどこかがいつも嘘くさい

綺麗事だけじゃ大事な人たちすら守れない

くだらない 僕らみんなどこか狂ってるみたい

本当のことなんか全部神様も知らない

Everybody don't know why.

Everybody don't know why.

Everybody don't know much.

僕は気にしない 君は気付かない

何処にももういないいない

Everybody don't know why.

Everybody don't know why.

Everybody don't know much.

忘れていく 忘れられていく

We don't know,We don't know.