zoukankan      html  css  js  c++  java
  • 曹工说Spring Boot源码(29)-- Spring 解决循环依赖为什么使用三级缓存,而不是二级缓存

    写在前面的话

    相关背景及资源:

    曹工说Spring Boot源码(1)-- Bean Definition到底是什么,附spring思维导图分享

    曹工说Spring Boot源码(2)-- Bean Definition到底是什么,咱们对着接口,逐个方法讲解

    曹工说Spring Boot源码(3)-- 手动注册Bean Definition不比游戏好玩吗,我们来试一下

    曹工说Spring Boot源码(4)-- 我是怎么自定义ApplicationContext,从json文件读取bean definition的?

    曹工说Spring Boot源码(5)-- 怎么从properties文件读取bean

    曹工说Spring Boot源码(6)-- Spring怎么从xml文件里解析bean的

    曹工说Spring Boot源码(7)-- Spring解析xml文件,到底从中得到了什么(上)

    曹工说Spring Boot源码(8)-- Spring解析xml文件,到底从中得到了什么(util命名空间)

    曹工说Spring Boot源码(9)-- Spring解析xml文件,到底从中得到了什么(context命名空间上)

    曹工说Spring Boot源码(10)-- Spring解析xml文件,到底从中得到了什么(context:annotation-config 解析)

    曹工说Spring Boot源码(11)-- context:component-scan,你真的会用吗(这次来说说它的奇技淫巧)

    曹工说Spring Boot源码(12)-- Spring解析xml文件,到底从中得到了什么(context:component-scan完整解析)

    曹工说Spring Boot源码(13)-- AspectJ的运行时织入(Load-Time-Weaving),基本内容是讲清楚了(附源码)

    曹工说Spring Boot源码(14)-- AspectJ的Load-Time-Weaving的两种实现方式细细讲解,以及怎么和Spring Instrumentation集成

    曹工说Spring Boot源码(15)-- Spring从xml文件里到底得到了什么(context:load-time-weaver 完整解析)

    曹工说Spring Boot源码(16)-- Spring从xml文件里到底得到了什么(aop:config完整解析【上】)

    曹工说Spring Boot源码(17)-- Spring从xml文件里到底得到了什么(aop:config完整解析【中】)

    曹工说Spring Boot源码(18)-- Spring AOP源码分析三部曲,终于快讲完了 (aop:config完整解析【下】)

    曹工说Spring Boot源码(19)-- Spring 带给我们的工具利器,创建代理不用愁(ProxyFactory)

    曹工说Spring Boot源码(20)-- 码网恢恢,疏而不漏,如何记录Spring RedisTemplate每次操作日志

    曹工说Spring Boot源码(21)-- 为了让大家理解Spring Aop利器ProxyFactory,我已经拼了

    曹工说Spring Boot源码(22)-- 你说我Spring Aop依赖AspectJ,我依赖它什么了

    曹工说Spring Boot源码(23)-- ASM又立功了,Spring原来是这么递归获取注解的元注解的

    曹工说Spring Boot源码(24)-- Spring注解扫描的瑞士军刀,asm技术实战(上)

    曹工说Spring Boot源码(25)-- Spring注解扫描的瑞士军刀,ASM + Java Instrumentation,顺便提提Jar包破解

    曹工说Spring Boot源码(26)-- 学习字节码也太难了,实在不能忍受了,写了个小小的字节码执行引擎

    曹工说Spring Boot源码(27)-- Spring的component-scan,光是include-filter属性的各种配置方式,就够玩半天了

    曹工说Spring Boot源码(28)-- Spring的component-scan机制,让你自己来进行简单实现,怎么办

    工程代码地址 思维导图地址

    工程结构图:

    什么是三级缓存

    在获取单例bean的时候,会进入以下方法:

    org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)
        
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
                    // 1
    		Object singletonObject = this.singletonObjects.get(beanName);
    		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
    			synchronized (this.singletonObjects) {
                                    // 2
    				singletonObject = this.earlySingletonObjects.get(beanName);
    				if (singletonObject == null && allowEarlyReference) {
                                            // 3
    					ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
    					if (singletonFactory != null) {
                                                    // 4
    						singletonObject = singletonFactory.getObject();
    						this.earlySingletonObjects.put(beanName, singletonObject);
    						this.singletonFactories.remove(beanName);
    					}
    				}
    			}
    		}
    		return singletonObject;
    	}
    

    这里面涉及到了该类中的三个field。

    	/** 1级缓存 Cache of singleton objects: bean name to bean instance. */
    	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    
    	/** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
    	private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
    
    	/** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */
    	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
    

    接着说前面的代码。

    • 1处,在最上层的缓存singletonObjects中,获取单例bean,这里面拿到的bean,直接可以使用;如果没取到,则进入2处

    • 2处,在2级缓存earlySingletonObjects中,查找bean;

    • 3处,如果在2级缓存中,还是没找到,则在3级缓存中查找对应的工厂对象,利用拿到的工厂对象(工厂对象中,有3个field,一个是beanName,一个是RootBeanDefinition,一个是已经创建好的,但还没有注入属性的bean),去获取包装后的bean,或者说,代理后的bean。

      什么是已经创建好的,但没有注入属性的bean?

      比如一个bean,有10个字段,你new了之后,对象已经有了,内存空间已经开辟了,堆里已经分配了该对象的空间了,只是此时的10个field还是null。

    ioc容器,普通循环依赖,一级缓存够用吗

    说实话,如果简单写写的话,一级缓存都没问题。给大家看一个我以前写的渣渣ioc容器:

    曹工说Tomcat4:利用 Digester 手撸一个轻量的 Spring IOC容器

    @Data
    public class BeanDefinitionRegistry {
        /**
         * map:存储 bean的class-》bean实例
         */
        private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();
        
        /**
         * 根据bean 定义获取bean
         * 1、先查bean容器,查到则返回
         * 2、生成bean,放进容器(此时,依赖还没注入,主要是解决循环依赖问题)
         * 3、注入依赖
         *
         * @param beanDefiniton
         * @return
         */
        private Object getBean(MyBeanDefiniton beanDefiniton) {
            Class<?> beanClazz = beanDefiniton.getBeanClazz();
            Object bean = beanMapByClass.get(beanClazz);
            if (bean != null) {
                return bean;
            }
    		// 0
            bean = generateBeanInstance(beanClazz);
    
    
            // 1 先行暴露,解决循环依赖问题
            beanMapByClass.put(beanClazz, bean);
            beanMapByName.put(beanDefiniton.getBeanName(), bean);
    
            // 2 查找依赖
            List<Field> dependencysByField = beanDefiniton.getDependencysByField();
            if (dependencysByField == null) {
                return bean;
            }
    		
            // 3
            for (Field field : dependencysByField) {
                try {
                    autowireField(beanClazz, bean, field);
                } catch (Exception e) {
                    throw new RuntimeException(beanClazz.getName() + " 创建失败",e);
                }
            }
    
            return bean;
        }
    }
    

    大家看上面的代码,我只定义了一个field,就是一个map,存放bean的class-》bean。

        /**
         * map:存储 bean的class-》bean实例
         */
        private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();
    
    • 0处,生成bean,直接就是new
    • 1处,先把这个不完整的bean,放进map
    • 2处,获取需要注入的属性集合
    • 3处,进行自动注入,就是根据field的Class,去map里查找对应的bean,设置到field里。

    上面这个代码,有啥问题没?spring为啥整整三级?

    ioc,一级缓存有什么问题

    一级缓存的问题在于,就1个map,里面既有完整的已经ready的bean,也有不完整的,尚未设置field的bean。

    如果这时候,有其他线程去这个map里获取bean来用怎么办?拿到的bean,不完整,怎么办呢?属性都是null,直接空指针了。

    所以,我们就要加一个map,这个map,用来存放那种不完整的bean。这里,还是拿spring举例。我们可以只用下面这两层:

    	/** 1级缓存 Cache of singleton objects: bean name to bean instance. */
    	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    
    	/** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
    	private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
    
    

    因为spring代码里是三级缓存,所以我们对源码做一点修改。

    修改spring源码,只使用二级缓存

    修改创建bean的代码,不放入第三级缓存,只放入第二级缓存

    创建了bean之后,属性注入之前,将创建出来的不完整bean,放到earlySingletonObjects

    这个代码,在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean,我这边只有4.0版本的spring源码工程,不过这套逻辑,算是spring核心逻辑,和5.x版本差别不大。

    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
    		BeanWrapper instanceWrapper = null;
    		if (mbd.isSingleton()) {
    			instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
    		}
    		if (instanceWrapper == null) {
                // 1
    			instanceWrapper = createBeanInstance(beanName, mbd, args);
    		}
    		final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
    		Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
    		...
    		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
    				isSingletonCurrentlyInCreation(beanName));
    		if (earlySingletonExposure) {
                // 2
    			earlySingletonObjects.put(beanName,bean);
    			registeredSingletonObjects.add(beanName);
    			// 3
    //			addSingletonFactory(beanName, new ObjectFactory() {
    //				public Object getObject() throws BeansException {
    //					return getEarlyBeanReference(beanName, mbd, bean);
    //				}
    //			});
    		}
    
    • 1处,就是创建对象,就是new
    • 2处,这是我加的代码,放入二级缓存
    • 3处,本来这就是增加三级缓存的位置,被我注释了。现在,就不会往三级缓存放东西了

    修改获取bean的代码,只从第一、第二级缓存获取,不从第三级获取

    org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)

    之前的代码是文章开头那样的,我这里修改为:

    	protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    		Object singletonObject = this.singletonObjects.get(beanName);
    		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
    			synchronized (this.singletonObjects) {
    				singletonObject = this.earlySingletonObjects.get(beanName);
    				return singletonObject;
    			}
    		}
    		return (singletonObject != NULL_OBJECT ? singletonObject : null);
    

    这样,就是只用两级缓存了。

    两级缓存,有啥问题?

    ioc循环依赖,一点问题都没有,完全够用了。

    我这边一个简单的例子,

    
    public class Chick{
        private Egg egg;
    
        public Egg getEgg() {
            return egg;
        }
    
        public void setEgg(Egg egg) {
            this.egg = egg;
        }
    }
    
    
    public class Egg {
        private Chick chick;
    
        public Chick getChick() {
            return chick;
        }
    
        public void setChick(Chick chick) {
            this.chick = chick;
        }
    
        <bean id="chick" class="foo.Chick" lazy-init="true">
            <property name="egg" ref="egg"/>
        </bean>
        <bean id="egg" class="foo.Egg" lazy-init="true">
            <property name="chick" ref="chick"/>
        </bean>
    
            ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
                    "context-namespace-test-aop.xml");
    
            Egg egg = (Egg) ctx.getBean(Egg.class);
    

    结论:

    所以,一级缓存都能解决的问题,二级当然更没问题。

    但是,如果我这里给上面的Egg类,加个切面(aop的逻辑,意思就是最终会生成Egg的一个动态代理对象),那还有问题没?

        <aop:config>
            <aop:pointcut id="mypointcut" expression="execution(public * foo.Egg.*(..))"/>
            <aop:aspect id="myAspect" ref="performenceAspect">
                <aop:after method="afterIncubate" pointcut-ref="mypointcut"/>
            </aop:aspect>
        </aop:config>
    
    

    注意这里的切点:

    execution(public * foo.Egg.*(..))
    

    就是切Egg类的方法。

    加了这个逻辑后,我们继续运行,在 Egg egg = (Egg) ctx.getBean(Egg.class);行,会抛出如下异常:

    我涂掉了一部分,因为那是官方对这个异常的推论,因为我们改了代码,所以推论不准确,因此干脆隐去。

    这个异常是说:

    兄弟啊,bean egg已经被注入到了其他bean:chick中。(因为我们循环依赖了),但是,注入到chick中的,是Egg类型。但是,我们这里最后对egg这个bean,进行了后置处理,生成了代理对象。那其他bean里,用原始的bean,是不是不太对啊?

    所以,spring给我们抛错了。

    怎么理解呢? 以io流举例,我们一开始都是用的原始字节流,然后给别人用的也是字节流,但是,最后,我感觉不方便,我自己悄悄弄了个缓存字符流(类比代理对象),我是方便了,但是,别人用的,还是原始的字节流啊。

    你bean不是单例吗?不能这么玩吧?

    所以,这就是二级缓存,不能解决的问题。

    什么问题?aop情形下,注入到其他bean的,不是最终的代理对象。

    三级缓存,怎么解决这个问题

    要解决这个问题,必须在其他bean(chick),来查找我们(以上面例子为例,我们是egg)的时候,查找到最终形态的egg,即代理后的egg。

    怎么做到这点呢?

    加个三级缓存,里面不存具体的bean,里面存一个工厂对象。通过工厂对象,是可以拿到最终形态的代理后的egg。

    ok,我们将前面修改的代码还原:

    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
    		BeanWrapper instanceWrapper = null;
    		if (mbd.isSingleton()) {
    			instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
    		}
    		if (instanceWrapper == null) {
                // 1
    			instanceWrapper = createBeanInstance(beanName, mbd, args);
    		}
    		final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
    		Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
    
    		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
    				isSingletonCurrentlyInCreation(beanName));
    		if (earlySingletonExposure) {
                // 2
    //			Map<String, Object> earlySingletonObjects = this.getEarlySingletonObjects();
    //			earlySingletonObjects.put(beanName,bean);
    //
    //			Set<String> registeredSingletonObjects = this.getRegisteredSingletonObjects();
    //			registeredSingletonObjects.add(beanName);
    			
                // 3
    			addSingletonFactory(beanName, new ObjectFactory() {
    				public Object getObject() throws BeansException {
    					return getEarlyBeanReference(beanName, mbd, bean);
    				}
    			});
    		}
    
    • 1处,创建bean,单纯new,不注入

    • 2处,revert我们的代码

    • 3处,这里new了一个ObjectFactory,然后会存入到如下的第三级缓存。

      	/** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */
      	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
      

      注意,new一个匿名内部类(假设这个匿名类叫AA)的对象,其中用到的外部类的变量,都会在AA中隐式生成对应的field。

      大家看上图,里面的3个字段,和下面代码1处中的,几个字段,是一一对应的。

      			addSingletonFactory(beanName, new ObjectFactory() {
      				public Object getObject() throws BeansException {
                          // 1
      					return getEarlyBeanReference(beanName, mbd, bean);
      				}
      			});
      

    ok,现在,egg已经把自己存进去了,存在了第三级缓存,1级和2级都没有,那后续chick在使用getSingleton查找egg的时候,就会进入下面的逻辑了(就是文章开头的那段代码,下面已经把我们的修改还原了):

    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    //		Object singletonObject = this.singletonObjects.get(beanName);
    //		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
    //			synchronized (this.singletonObjects) {
    //				singletonObject = this.earlySingletonObjects.get(beanName);
    //				return singletonObject;
    //			}
    //		}
    //		return (singletonObject != NULL_OBJECT ? singletonObject : null);
    
    		Object singletonObject = this.singletonObjects.get(beanName);
    		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
    			synchronized (this.singletonObjects) {
    				singletonObject = this.earlySingletonObjects.get(beanName);
    				if (singletonObject == null && allowEarlyReference) {
    					ObjectFactory singletonFactory = this.singletonFactories.get(beanName);
    					if (singletonFactory != null) {
                            // 1
    						singletonObject = singletonFactory.getObject();
    						this.earlySingletonObjects.put(beanName, singletonObject);
    						this.singletonFactories.remove(beanName);
    					}
    				}
    			}
    		}
    		return (singletonObject != NULL_OBJECT ? singletonObject : null);
    	}
    

    上面就会进入1处,调用singletonFactory.getObject();

    而前面我们知道,这个factory的逻辑是:

    			addSingletonFactory(beanName, new ObjectFactory() {
    				public Object getObject() throws BeansException {
                        // 1
    					return getEarlyBeanReference(beanName, mbd, bean);
    				}
    			});
    

    1处就是这个工厂方法的逻辑,这里面,简单说,就会去调用各个beanPostProcessor的getEarlyBeanReference方法。

    其中,主要就是aop的主力beanPostProcessor,AbstractAutoProxyCreator#getEarlyBeanReference

    其实现如下:

    	public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
    		Object cacheKey = getCacheKey(bean.getClass(), beanName);
    		this.earlyProxyReferences.add(cacheKey);
            // 1
    		return wrapIfNecessary(bean, beanName, cacheKey);
    	}
    

    这里的1处,就会去对egg这个bean,创建代理,此时,返回的对象,就是个代理对象了,那,注入到chick的,自然也是代理后的egg了。

    关于SmartInstantiationAwareBeanPostProcessor

    我们上面说的那个getEarlyBeanReference就在这个接口中。

    这个接口继承了BeanPostProcessor

    而创建代理对象,目前就是在如下两个方法中去创建:

    public interface BeanPostProcessor {
        Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
        
    	Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;    
    }
    

    这两个方法,都是在实例化之后,创建代理。那我们前面创建代理,是在依赖解析过程中:

    public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
        ...
    	Object getEarlyBeanReference(Object bean, String beanName) throws BeansException;
    }
    
    

    所以,spring希望我们,在这几处,要返回同样的对象,即:既然你这几处都要返回代理对象,那就不能返回不一样的代理对象。

    源码

    文章用到的aop循环依赖的demo,自己写一个也可以,很简单:

    https://gitee.com/ckl111/spring-boot-first-version-learn/tree/master/all-demo-in-spring-learning/spring-aop-xml-demo-cycle-reference

    不错的参考资料

    https://blog.csdn.net/f641385712/article/details/92801300

    总结

    如果有问题,欢迎指出;欢迎加群讨论;有帮助的话,请点个赞吧,谢谢

  • 相关阅读:
    Kalman Filters
    基于堆栈实现计算器
    Centos 7创建软连接,硬连接的方法
    Centos 7下对磁盘的分区格式化挂载交换空间的建立
    文件的归档打包压缩解压缩
    文件目录操作命令及权限的修改设置
    用户添加修改文件的操作
    linux今日学习命令 who
    CentOS安装流程
    计算机网络基础
  • 原文地址:https://www.cnblogs.com/grey-wolf/p/13034371.html
Copyright © 2011-2022 走看看