二刷Spring循环依赖源码(下)

简介: 二刷Spring循环依赖源码(下)

3.为啥需要三个缓存

Spring 为啥用三个缓存去解决循环依赖问题?

上面两个缓存的地方,我们只是没有考虑代理的情况。


代理的存在

Bean在创建的最后阶段,会检查是否需要创建代理,如果创建了代理,那么最终返回的就是代理实例的引用。我们通过beanname获取到最终是代理实例的引用

也就是说:上文中,假设A最终会创建代理,提前暴露A的引用, B填充属性时填充的是A的原始对象引用。A最终放入成品库里是代理的引用。那么B中依然是A的早期引用。这种结果最终会与我们的期望的大相径庭了。

怎么办???


Spring 是这么做的
=======AbstractAutowireCapableBeanFactory.doCreateBean
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
            throws BeanCreationException {
        【1】Instantiate the bean.
        BeanWrapper instanceWrapper = null;
        if (mbd.isSingleton()) {
            instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
        }
        if (instanceWrapper == null) {
            instanceWrapper = createBeanInstance(beanName, mbd, args);
        }
        【早期引用】
        final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
        【2】在需要暴露早期引用的条件下
        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            【2.1】绑定当前Bean引用到ObjectFactory,注册到三级singletonFactories 
            addSingletonFactory(beanName, new ObjectFactory<Object>() {
                【重写getObject】
                @Override
                public Object getObject() throws BeansException {
                    return getEarlyBeanReference(beanName, mbd, bean);
                }
            });
        }
}
===AbstractAutowireCapableBeanFactory.doCreateBean--->DefaultSingletonBeanRegistry.getSingleton
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
        synchronized (this.singletonObjects) {
            if (!this.singletonObjects.containsKey(beanName)) {
                【3】放入到singletonFactories 缓存中,清除其他缓存
                this.singletonFactories.put(beanName, singletonFactory);
                this.earlySingletonObjects.remove(beanName);
                this.registeredSingletons.add(beanName);
            }
}
===========AbstractBeanFactory.doGetBean--->DefaultSingletonBeanRegistry.getSingleton
【4】按Beanname取Bean
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        【4.1】先尝试从成品缓存获取
        Object singletonObject = this.singletonObjects.get(beanName);
        【4.2】成品缓存没有,且正在创建,尝试从半成品缓存获取
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    【4.3】半成品缓存没有,且允许早期引用,尝试从工厂缓存中查找有么此Bean的工厂类存在
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        【4.4】存在,执行getObject获取早期引用,放入到半成品缓存,并将工厂类从工厂缓存中移除
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }

注册 ObjectFactory工厂类到工厂缓存

singletonFactory.getObject();会调用重写getObject()调用getEarlyBeanReference的后续操作。

  • 如果后续操作没有创建代理,返回的依然是原始引用
  • 如果需要代理,在此处返回就是代理的引用
早期的扩展处理
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
        Object exposedObject = bean;
        if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
            for (BeanPostProcessor bp : getBeanPostProcessors()) {
                if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                    SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                    exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
                    if (exposedObject == null) {
                        return null;
                    }
                }
            }
        }
        return exposedObject;
    }

可以看出此处是执行扩展的操作。

AbstractAutoProxyCreator

【1】针对提前创建代理,返回代理引用
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        this.earlyProxyReferences.put(cacheKey, bean);
        return wrapIfNecessary(bean, beanName, cacheKey);
}
【2】针对不是提前创建代理的情况
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (bean != null) {
            Object cacheKey = getCacheKey(bean.getClass(), beanName);
            if (this.earlyProxyReferences.remove(cacheKey) != bean) {
                return wrapIfNecessary(bean, beanName, cacheKey);
            }
        }
        return bean;
}

可以看出singletonFactory工厂缓存,解决了代理问题的关键

大体流程如图

image.png


关键点:

  • A绑定到ObjectFactory 注册到工厂缓存singletonFactory中,
  • B在填充A时,先查成品缓存有没有,再查半成品缓存有没有,最后看工厂缓存有没有单例工厂类,有A的ObjectFactory。调用getObject ,执行扩展逻辑,可能返回的代理引用,也可能返回原始引用。
  • 成功获取到A的早期引用,将A放入到半成品缓存中,B填充A引用完毕。
  • 代理问题, 循环依赖问题都解决了。


四、额外思考的自问自答


在这之外,我还有一些思考,并提出自己的观点。

1:为啥不提前调用ObjectFactory.getObject ()直接执行扩展逻辑处理A的早期引用,得到半成品实例引用放入到earlySingletonObjects中,非要先放一个工厂类到工厂缓存中?使用三级缓存呢?

答:假设A只是依赖B 。如果提前执行A扩展操作,在A创建的后期,还会遍历一遍扩展点,岂不是浪费?

2.二级缓存存在意义是啥?

答:其实吧,我觉得  二级缓存earlySingletonObjects三级缓存singletonFactories 。都是为分工明确而生。

  • 一级缓存singletonObjects: 就是存的最终的成品
  • 二级缓存earlySingletonObjects  就是为存半成品Bean
  • 三级缓存singletonFactories: 就是为存bean工厂

因为是早期暴露,从工厂里创建完成后,是半成品,放入半成品缓存,全部流程执行完时是成品放入到成品缓存分工明确

这也为什么,我认为叫成品缓存,半成品缓存,单例工厂缓存 更加合适的原因

3.是不是走极端,让我设计此块,我非得设计成单个缓存。提前执行后续操作,把他放到singletonObjects

好像也没有问题,就是非常乱


五、总结


以上就是我对Spring循环依赖的一些理解与思考

循环依赖的关键点:提前暴露绑定A原始引用的工厂类到工厂缓存。等需要时触发后续操作处理A的早期引用,将处理结果放入二级缓存


相关文章
|
7天前
|
缓存 Java 开发工具
Spring是如何解决循环依赖的?从底层源码入手,详细解读Spring框架的三级缓存
三级缓存是Spring框架里,一个经典的技术点,它很好地解决了循环依赖的问题,也是很多面试中会被问到的问题,本文从源码入手,详细剖析Spring三级缓存的来龙去脉。
Spring是如何解决循环依赖的?从底层源码入手,详细解读Spring框架的三级缓存
|
7天前
|
XML 缓存 Java
手写Spring源码(简化版)
Spring包下的类、手写@ComponentScan注解、@Component注解、@Autowired注解、@Scope注解、手写BeanDefinition、BeanNameAware、InitializingBean、BeanPostProcessor 、手写AnnotationConfigApplicationContext
手写Spring源码(简化版)
|
7天前
|
缓存 安全 Java
Spring框架中Bean是如何加载的?从底层源码入手,详细解读Bean的创建流程
从底层源码入手,通过代码示例,追踪AnnotationConfigApplicationContext加载配置类、启动Spring容器的整个流程,并对IOC、BeanDefinition、PostProcesser等相关概念进行解释
Spring框架中Bean是如何加载的?从底层源码入手,详细解读Bean的创建流程
|
24天前
|
人工智能 前端开发 Java
【实操】Spring Cloud Alibaba AI,阿里AI这不得玩一下(含前后端源码)
本文介绍了如何使用 **Spring Cloud Alibaba AI** 构建基于 Spring Boot 和 uni-app 的聊天机器人应用。主要内容包括:Spring Cloud Alibaba AI 的概念与功能,使用前的准备工作(如 JDK 17+、Spring Boot 3.0+ 及通义 API-KEY),详细实操步骤(涵盖前后端开发工具、组件选择、功能分析及关键代码示例)。最终展示了如何成功实现具备基本聊天功能的 AI 应用,帮助读者快速搭建智能聊天系统并探索更多高级功能。
174 2
【实操】Spring Cloud Alibaba AI,阿里AI这不得玩一下(含前后端源码)
|
1月前
|
存储 缓存 Java
面试问Spring循环依赖?今天通过代码调试让你记住
该文章讨论了Spring框架中循环依赖的概念,并通过代码示例帮助读者理解这一概念。
面试问Spring循环依赖?今天通过代码调试让你记住
|
1月前
|
缓存 Java Spring
spring如何解决循环依赖
Spring框架处理循环依赖分为构造器循环依赖与setter循环依赖两种情况。构造器循环依赖不可解决,Spring会在检测到此类依赖时抛出`BeanCurrentlyInCreationException`异常。setter循环依赖则通过缓存机制解决:利用三级缓存系统,其中一级缓存`singletonObjects`存放已完成的单例Bean;二级缓存`earlySingletonObjects`存放实例化但未完成属性注入的Bean;三级缓存`singletonFactories`存放创建这些半成品Bean的工厂。
|
23天前
|
Java Spring 容器
循环依赖难破解?Spring Boot神秘武器@RequiredArgsConstructor与@Lazy大显神通!
【8月更文挑战第29天】在Spring Boot应用中,循环依赖是一个常见问题。当两个或多个Bean相互依赖形成闭环时,Spring容器会陷入死循环。本文通过对比@RequiredArgsConstructor和@Lazy注解,探讨它们如何解决循环依赖问题。**@RequiredArgsConstructor**:通过Lombok生成包含final字段的构造函数,优先通过构造函数注入依赖,简化代码但可能导致构造函数复杂。**@Lazy**:延迟Bean的初始化,直到首次使用,打破创建顺序依赖,增加灵活性但可能影响性能。根据具体场景选择合适方案可有效解决循环依赖问题。
26 0
|
2月前
|
Java Spring 容器
Spring Boot 启动源码解析结合Spring Bean生命周期分析
Spring Boot 启动源码解析结合Spring Bean生命周期分析
80 11
|
30天前
|
设计模式 Java 程序员
学习 Spring 源码的意义是什么呢?
研究Spring源码能深化框架理解,提升代码分析与设计能力,助您掌握设计模式及最佳实践,增强解决问题的效率,促进职业生涯发展,并激发技术热情。选择稳定版本,从核心模块开始,结合实际项目并参与社区,让学习之旅既充实又具乐趣。
|
2月前
|
缓存 Java 程序员
spring IoC 源码
spring IoC 源码
47 3