Spring压轴题当循环依赖遇上SpringAOP

　　前言
　　问：Spring如何解决循环依赖？
　　答：Spring通过提前曝光机制，利用三级缓存解决循环依赖（这原理还是挺简单的，参考：三级缓存、图解循环依赖原理）
　　再问：Spring通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？
　　再细问：如果循环依赖的时候，所有类又都需要SpringAOP自动代理，那Spring如何提前曝光？曝光的是原始bean还是代理后的bean？
　　这些问题算是Spring源码的压轴题了，如果这些问题都弄明白，恭喜你顺利结业Spring源码了。就单单对Spring这一块的理解，不夸张的说可以达到阿里水准了源码分析
　　进入正题，在Spring创建Bean的核心代码doGetBean中，在实例化bean之前，会先尝试从三级缓存获取bean，这也是Spring解决循环依赖的开始（一）缓存中获取beanAbstractBeanFactory。javaprotectedTTdoGetBean（finalStringname，NullablefinalClassTrequiredType，NullablefinalObject〔〕args，booleantypeCheckOnly）throwsBeansException｛finalStringbeanNametransformedBeanName（name）；O2。尝试从缓存中获取beanObjectsharedInstancegetSingleton（beanName）；。。。｝protectedObjectgetSingleton（StringbeanName，booleanallowEarlyReference）｛从一级缓存获取，keybeanNamevaluebeanObjectsingletonObjectthis。singletonObjects。get（beanName）；if（singletonObjectnullisSingletonCurrentlyInCreation（beanName））｛synchronized（this。singletonObjects）｛从二级缓存获取，keybeanNamevaluebeansingletonObjectthis。earlySingletonObjects。get（beanName）；是否允许循环引用if（singletonObjectnullallowEarlyReference）｛三级缓存获取，keybeanNamevalueobjectFactory，objectFactory中存储getObject（）方法用于获取提前曝光的实例而为什么不直接将实例缓存到二级缓存，而要多此一举将实例先封装到objectFactory中？主要关键点在getObject（）方法并非直接返回实例，而是对实例又使用SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法对bean进行处理也就是说，当spring中存在该后置处理器，所有的单例bean在实例化后都会被进行提前曝光到三级缓存中，但是并不是所有的bean都存在循环依赖，也就是三级缓存到二级缓存的步骤不一定都会被执行，有可能曝光后直接创建完成，没被提前引用过，就直接被加入到一级缓存中。因此可以确保只有提前曝光且被引用的bean才会进行该后置处理ObjectF？singletonFactorythis。singletonFactories。get（beanName）；if（singletonFactory！null）｛通过getObject（）方法获取bean，通过此方法获取到的实例不单单是提前曝光出来的实例，它还经过了SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法处理过。这也正是三级缓存存在的意义，可以通过重写该后置处理器对提前曝光的实例，在被提前引用时进行一些操作singletonObjectsingletonFactory。getObject（）；将三级缓存生产的bean放入二级缓存中this。earlySingletonObjects。put（beanName，singletonObject）；删除三级缓存this。singletonFactories。remove（beanName）；｝｝｝｝returnsingletonO｝
　　三级缓存分别是：singletonObject：一级缓存，该缓存keybeanName，这里的bean是已经创建完成的，该bean经历过实例化属性填充初始化以及各类的后置处理。因此，一旦需要获取bean时，我们第一时间就会寻找一级缓存earlySingletonObjects：二级缓存，该缓存keybeanName，这里跟一级缓存的区别在于，该缓存所获取到的bean是提前曝光出来的，是还没创建完成的。也就是说获取到的bean只能确保已经进行了实例化，但是属性填充跟初始化肯定还没有做完，因此该bean还没创建完成，仅仅能作为指针提前曝光，被其他bean所引用singletonFactories：三级缓存，该缓存keybeanName，valuebeanF在bean实例化完之后，属性填充以及初始化之前，如果允许提前曝光，spring会将实例化后的bean提前曝光，也就是把该bean转换成beanFactory并加入到三级缓存。
　　在需要引用提前曝光对象时再通过singletonFactory。getObject（）获取。
　　这里抛出问题，如果我们直接将提前曝光的对象放到二级缓存earlySingletonObjects，Spring循环依赖时直接取就可以解决循环依赖了，为什么还要三级缓存singletonFactory然后再通过getObject（）来获取呢？这是不是多此一举？（二）三级缓存的添加
　　我们回到添加三级缓存，添加SingletonFactory的地方，看看getObject（）到底做了什么操作this。addSingletonFactory（beanName，（）｛returnthis。getEarlyBeanReference（beanName，mbd，bean）；｝）；
　　可以看到在返回getObject（）时，多做了一步getEarlyBeanReference操作，这步操作是BeanPostProcess的一种，也就是给子类重写的一个后处理器，目的是用于被提前引用时进行拓展。即：曝光的时候并不调用该后置处理器，只有曝光，且被提前引用的时候才调用，确保了被提前引用这个时机触发。（三）提前曝光代理earlyProxyReferences
　　因此所有的重点都落到了getEarlyBeanReference上，getEarlyBeanReference方法是SmartInstantiationAwareBeanPostProcessor所规定的接口。再通过UML的类图查看实现类，仅有AbstractAutoProxyCreator进行了实现。也就是说，除了用户在子类重写，否则仅有AbstractAutoProxyCreator一种情况AbstractAutoProxyCreator。javapublicObjectgetEarlyBeanReference（Objectbean，StringbeanName）｛缓存当前bean，表示该bean被提前代理了ObjectcacheKeygetCacheKey（bean。getClass（），beanName）；this。earlyProxyReferences。put（cacheKey，bean）；对bean进行提前SpringAOP代理returnwrapIfNecessary（bean，beanName，cacheKey）；｝
　　wrapIfNecessary是用于SpringAOP自动代理的。Spring将当前bean缓存到earlyProxyReferences中标识提前曝光的bean在被提前引用之前，然后进行了SpringAOP代理。
　　但是经过SpringAOP代理后的bean就已经不再是原来的bean了，经过代理后的bean是一个全新的bean，也就是说代理前后的2个bean连内存地址都不一样了。这时将再引出新的问题：B提前引用A将引用到A的代理，这是符合常理的，但是最原始的beanA在B完成创建后将继续创建，那么SpringIoc最后返回的Bean是BeanA呢还是经过代理后的Bean呢？
　　这个问题我们得回到SpringAOP代理，SpringAOP代理时机有2个：当自定义了TargetSource，则在bean实例化前完成SpringAOP代理并且直接发生短路操作，返回bean正常情况下，都是在bean初始化后进行SpringAOP代理如果要加上今天说的提前曝光代理，getEarlyBeanReference可以说3种
　　第一种情况就没什么好探究的了，直接短路了，根本没有后续操作。而我们关心的是第二种情况，在Spring初始化后置处理器中发生的SpringAOP代理publicObjectapplyBeanPostProcessorsAfterInitialization（ObjectexistingBean，StringbeanName）throwsBeansException｛ObjectresultexistingBfor（BeanPostProcessorprocessor：getBeanPostProcessors（））｛调用bean初始化后置处理器处理Objectcurrentprocessor。postProcessAfterInitialization（result，beanName）；if（currentnull）｛｝｝｝AbstractAutoProxyCreator。javapublicObjectpostProcessAfterInitialization（NullableObjectbean，StringbeanName）｛if（bean！null）｛获取缓存keyObjectcacheKeygetCacheKey（bean。getClass（），beanName）；查看该bean是否被SpringAOP提前代理！而缓存的是原始的bean，因此如果bean被提前代理过，这此处会跳过如果bean没有被提前代理过，则进入AOP代理if（this。earlyProxyReferences。remove（cacheKey）！bean）｛returnwrapIfNecessary（bean，beanName，cacheKey）；｝｝｝
　　earlyProxyReferences是不是有点熟悉，是的，这就是我们刚刚提前曝光并且进行SpringAOP提前代理时缓存的原始bean，如果缓存的原始bean跟当前的bean是一致的，那么就不进行SpringAOP代理了！返回原始的beanprotectedObjectdoCreateBean（finalStringbeanName，finalRootBeanDefinitionmbd，finalNullableObject〔〕args）throwsBeanCreationException｛try｛4。填充属性如果Autowired注解属性，则在上方完成解析后，在这里完成注入AutowiredprivateIpopulateBean（beanName，mbd，instanceWrapper）；5。初始化exposedObjectinitializeBean（beanName，exposedObject，mbd）；｝catch（Throwableex）｛if（exinstanceofBeanCreationExceptionbeanName。equals（（（BeanCreationException）ex）。getBeanName（）））｛throw（BeanCreationException）｝else｛thrownewBeanCreationException（mbd。getResourceDescription（），beanName，Initializationofbeanfailed，ex）；｝｝6。存在提前曝光情况下if（earlySingletonExposure）｛earlySingletonReference：二级缓存，缓存的是经过提前曝光提前SpringAOP代理的beanObjectearlySingletonReferencegetSingleton（beanName，false）；if（earlySingletonReference！null）｛exposedObject跟bean一样，说明初始化操作没用应用Initialization后置处理器（指AOP操作）改变exposedObject主要是因为exposedObject如果提前代理过，就会跳过SpringAOP代理，所以exposedObject没被改变，也就等于bean了if（exposedObjectbean）｛将二级缓存中的提前AOP代理的bean赋值给exposedObject，并返回exposedObjectearlySingletonR｝引用都不相等了，也就是现在的bean已经不是当时提前曝光的bean了elseif（！this。allowRawInjectionDespiteWrappinghasDependentBean（beanName））｛dependentBeans也就是B，C，DString〔〕dependentBeansgetDependentBeans（beanName）；SetStringactualDependentBeansnewLinkedHashSet（dependentBeans。length）；for（StringdependentBean：dependentBeans）｛if（！removeSingletonIfCreatedForTypeCheckOnly（dependentBean））｛actualDependentBeans。add（dependentBean）；｝｝被依赖检测异常if（！actualDependentBeans。isEmpty（））｛thrownewBeanCurrentlyInCreationException（beanName，BeanwithnamebeanNamehasbeeninjectedintootherbeans〔StringUtils。collectionToCommaDelimitedString（actualDependentBeans）〕initsrawversionaspartofacircularreference，buthaseventuallybeenwrapped。Thismeansthatsaidotherbeansdonotusethefinalversionofthebean。ThisisoftentheresultofovereagertypematchingconsiderusinggetBeanNamesOfTypewiththeallowEagerInitflagturnedoff，forexample。）；｝｝｝｝
　　这个时候我们需要理清一下3个变量earlySingletonReference：二级缓存，缓存的是经过提前曝光提前AOP代理的beanbean：这个就是经过了实例化、填充、初始化的beanexposedObject：这个是经过了AbstractAutoProxyCreator的postProcessAfterInitialization处理过后的bean，但是在其中因为发现当前bean已经被earlyProxyReferences缓存，所以并没有进行AOP处理，而是直接跳过，因此还是跟第2点一样的bean
　　理清这3个变量以后，就会发现，exposedObjectearlySingletonR
　　AOP代理过的Bean赋值给了exposedObject并返回，这时候用户拿到的bean就是AOP代理过后的bean了，一切皆大欢喜了。
　　但是中间还有一个问题！提前曝光的bean在提前引用时被SpringAOP代理了，但是此时的bean只是经过了实例化的bean，还没有进行Autowire的注入啊！也就是说此时代理的bean里面自动注入的属性是空的！（四）提前AOP代理对象的属性填充、初始化
　　是的，确实在SpringAOP提前代理后没有经过属性填充和初始化。那么这个代理又是如何保证依赖属性的注入的呢？
　　答案回到SpringAOP最早最早讲的JDK动态代理上找，JDK动态代理时，会将目标对象target保存在最后生成的代理中，当调用proxy方法时会回调h。invoke，而h。invoke又会回调目标对象target的原始方法。
　　因此，其实在SpringAOP动态代理时，原始bean已经被保存在提前曝光代理中了。而后原始Bean继续完成属性填充和初始化操作。
　　因为AOP代理proxy中保存着traget也就是是原始bean的引用，因此后续原始bean的完善，也就相当于SpringAOP中的target的完善，这样就保证了SpringAOP的属性填充与初始化了！（五）循环依赖遇上SpringAOP图解
　　为了帮助大家理解，这里灵魂画手画张流程图帮助大家理解
　　在这里插入图片描述
　　首先又beanA，beanB，他们循环依赖注入，同时beanA还需要被SpringAOP代理，例如事务管理或者日志之类的操作。
　　原始beanA，beanB图中用a，b表示，而代理后的beanA我们用aop。a表示
　　最少必要面试题
　　【Java基础】10道不得不会的Java基础面试题
　　【Java并发】10道不得不会的Java并发基础面试题
　　【MySQL】10道不得不会的MySQL基础面试题
　　【ElasticSearch】10道不得不会的ElasticSearch面试题
　　【JVM】10道不得不会的JVM面试题
　　【Spring】10道不得不会的Spring面试题