Springboot源碼分析之Spring循環依賴揭祕

摘要：

若你是一個有經驗的程序員，那你在開發中必然碰到過這種現象：事務不生效。或許剛說到這，有的小夥伴就會大驚失色了。Spring不是解決了循環依賴問題嗎，它是怎麼又會發生循環依賴的呢？，接下來就讓咱們一塊兒揭祕Spring循環依賴的最本質緣由。

Spring循環依賴流程圖

Spring循環依賴發生緣由

• 使用了具備代理特性的BeanPostProcessor
• 典型的有 事務註解@Transactional，異步註解@Async等

源碼分析揭祕

protected Object doCreateBean( ... ){
        ...
        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
        }
        ...
    
        // populateBean這一句特別的關鍵，它須要給A的屬性賦值，因此此處會去實例化B~~
        // 而B咱們從上能夠看到它就是個普通的Bean（並不須要建立代理對象），實例化完成以後，繼續給他的屬性A賦值，而此時它會去拿到A的早期引用
        // 也就在此處在給B的屬性a賦值的時候，會執行到上面放進去的Bean A流程中的getEarlyBeanReference()方法  從而拿到A的早期引用~~
        // 執行A的getEarlyBeanReference()方法的時候，會執行自動代理建立器，可是因爲A沒有標註事務，因此最終不會建立代理，so B合格屬性引用會是A的**原始對象**
        // 須要注意的是：@Async的代理對象不是在getEarlyBeanReference()中建立的，是在postProcessAfterInitialization建立的代理
        // 從這咱們也能夠看出@Async的代理它默認並不支持你去循環引用，由於它並無把代理對象的早期引用提供出來~~~（注意這點和自動代理建立器的區別~）
    
        // 結論：此處給A的依賴屬性字段B賦值爲了B的實例(由於B不須要建立代理，因此就是原始對象)
        // 而此處實例B裏面依賴的A注入的仍舊爲Bean A的普通實例對象（注意  是原始對象非代理對象）  注：此時exposedObject也依舊爲原始對象
        populateBean(beanName, mbd, instanceWrapper);
        
        // 標註有@Async的Bean的代理對象在此處會被生成~~~ 參照類：AsyncAnnotationBeanPostProcessor
        // 因此此句執行完成後  exposedObject就會是個代理對象而非原始對象了
        exposedObject = initializeBean(beanName, exposedObject, mbd);
        
        ...
        // 這裏是報錯的重點~~~
        if (earlySingletonExposure) {
            // 上面說了A被B循環依賴進去了，因此此時A是被放進了二級緩存的，因此此處earlySingletonReference 是A的原始對象的引用
            // （這也就解釋了爲什麼我說：若是A沒有被循環依賴，是不會報錯不會有問題的   由於若沒有循環依賴earlySingletonReference =null後面就直接return了）
            Object earlySingletonReference = getSingleton(beanName, false);
            if (earlySingletonReference != null) {
                // 上面分析了exposedObject 是被@Aysnc代理過的對象， 而bean是原始對象 因此此處不相等  走else邏輯
                if (exposedObject == bean) {
                    exposedObject = earlySingletonReference;
                }
                // allowRawInjectionDespiteWrapping 標註是否容許此Bean的原始類型被注入到其它Bean裏面，即便本身最終會被包裝（代理）
                // 默認是false表示不容許，若是改成true表示容許，就不會報錯啦。這是咱們後面講的決方案的其中一個方案~~~
                // 另外dependentBeanMap記錄着每一個Bean它所依賴的Bean的Map~~~~
                else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
                    // 咱們的Bean A依賴於B，so此處值爲["b"]
                    String[] dependentBeans = getDependentBeans(beanName);
                    Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
    
                    // 對全部的依賴進行一一檢查~    好比此處B就會有問題
                    // 「b」它通過removeSingletonIfCreatedForTypeCheckOnly最終返返回false  由於alreadyCreated裏面已經有它了表示B已經徹底建立完成了~~~
                    // 而b都完成了，因此屬性a也賦值完成兒聊 可是B裏面引用的a和主流程我這個A居然不相等，那確定就有問題(說明不是最終的)~~~
                    // so最終會被加入到actualDependentBeans裏面去，表示A真正的依賴~~~
                    for (String dependentBean : dependentBeans) {
                        if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
                            actualDependentBeans.add(dependentBean);
                        }
                    }
        
                    // 若存在這種真正的依賴，那就報錯了~~~  則個異常就是上面看到的異常信息
                    if (!actualDependentBeans.isEmpty()) {
                        throw new BeanCurrentlyInCreationException(beanName,
                                "Bean with name '" + beanName + "' has been injected into other beans [" +
                                StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
                                "] in its raw version as part of a circular reference, but has eventually been " +
                                "wrapped. This means that said other beans do not use the final version of the " +
                                "bean. This is often the result of over-eager type matching - consider using " +
                                "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
                    }
                }
            }
        }
        ...
    }

問題簡化

• 發生循環依賴時候Object earlySingletonReference = getSingleton(beanName, false);確定有值
• 緩存工廠addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));將給實例對象添加SmartInstantiationAwareBeanPostProcessor
• AbstractAutoProxyCreator是SmartInstantiationAwareBeanPostProcessor的子類，必定記住了，必定記住，SmartInstantiationAwareBeanPostProcessor的子類很關鍵！！！！！
• exposedObject = initializeBean(beanName, exposedObject, mbd);進行BeanPostProcessor後置處理，注意是BeanPostProcessor！！！！！

Spring的循環依賴被它的三級緩存給輕易解決了，可是這2個地方的後置處理帶來了 循環依賴的問題。

對比AbstractAdvisorAutoProxyCreator和AsyncAnnotationBeanPostProcessor

因爲SmartInstantiationAwareBeanPostProcessor的子類會在兩處都會執行後置處理，因此先後都會相同的對象引用，不會發生循環依賴問題，異步註解就不行了 ，至於爲何？本身看上面的分析，仔細看哦！

如何解決循環依賴？

• 改變加載順序
• @Lazy註解
• allowRawInjectionDespiteWrapping設置爲true（利用了判斷的那條語句）
• 別使用相關的BeanPostProcessor設計到的註解，，哈哈 這不太現實。

@Lazy

@Lazy通常含義是懶加載，它只會做用於BeanDefinition.setLazyInit()。而此處給它增長了一個能力：延遲處理（代理處理）

// @since 4.0 出現得挺晚，它支持到了@Lazy  是功能最全的AutowireCandidateResolver
    public class ContextAnnotationAutowireCandidateResolver extends QualifierAnnotationAutowireCandidateResolver {
        // 這是此類自己惟一作的事，此處精析    
        // 返回該 lazy proxy 表示延遲初始化，實現過程是查看在 @Autowired 註解處是否使用了 @Lazy = true 註解 
        @Override
        @Nullable
        public Object getLazyResolutionProxyIfNecessary(DependencyDescriptor descriptor, @Nullable String beanName) {
            // 若是isLazy=true  那就返回一個代理，不然返回null
            // 至關於若標註了@Lazy註解，就會返回一個代理（固然@Lazy註解的value值不能是false）
            return (isLazy(descriptor) ? buildLazyResolutionProxy(descriptor, beanName) : null);
        }
    
        // 這個比較簡單，@Lazy註解標註了就行（value屬性默認值是true）
        // @Lazy支持標註在屬性上和方法入參上~~~  這裏都會解析
        protected boolean isLazy(DependencyDescriptor descriptor) {
            for (Annotation ann : descriptor.getAnnotations()) {
                Lazy lazy = AnnotationUtils.getAnnotation(ann, Lazy.class);
                if (lazy != null && lazy.value()) {
                    return true;
                }
            }
            MethodParameter methodParam = descriptor.getMethodParameter();
            if (methodParam != null) {
                Method method = methodParam.getMethod();
                if (method == null || void.class == method.getReturnType()) {
                    Lazy lazy = AnnotationUtils.getAnnotation(methodParam.getAnnotatedElement(), Lazy.class);
                    if (lazy != null && lazy.value()) {
                        return true;
                    }
                }
            }
            return false;
        }
    
        // 核心內容，是本類的靈魂~~~
        protected Object buildLazyResolutionProxy(final DependencyDescriptor descriptor, final @Nullable String beanName) {
            Assert.state(getBeanFactory() instanceof DefaultListableBeanFactory,
                    "BeanFactory needs to be a DefaultListableBeanFactory");
    
            // 這裏絕不客氣的使用了面向實現類編程，使用了DefaultListableBeanFactory.doResolveDependency()方法~~~
            final DefaultListableBeanFactory beanFactory = (DefaultListableBeanFactory) getBeanFactory();
    
            //TargetSource 是它實現懶加載的核心緣由，在AOP那一章節了重點提到過這個接口，此處再也不敘述
            // 它有不少的著名實現如HotSwappableTargetSource、SingletonTargetSource、LazyInitTargetSource、
            //SimpleBeanTargetSource、ThreadLocalTargetSource、PrototypeTargetSource等等很是多
            // 此處由於只須要本身用，因此採用匿名內部類的方式實現~~~ 此處最重要是看getTarget方法，它在被使用的時候（也就是代理對象真正使用的時候執行~~~）
            TargetSource ts = new TargetSource() {
                @Override
                public Class<?> getTargetClass() {
                    return descriptor.getDependencyType();
                }
                @Override
                public boolean isStatic() {
                    return false;
                }
        
                // getTarget是調用代理方法的時候會調用的，因此執行每一個代理方法都會執行此方法，這也是爲什麼doResolveDependency
                // 我我的認爲它在效率上，是存在必定的問題的~~~因此此處建議儘可能少用@Lazy~~~   
                //不過效率上應該還好，對比http、序列化反序列化處理，簡直不值一提  因此仍是無所謂  用吧
                @Override
                public Object getTarget() {
                    Object target = beanFactory.doResolveDependency(descriptor, beanName, null, null);
                    if (target == null) {
                        Class<?> type = getTargetClass();
                        // 對多值注入的空值的友好處理（不要用null）
                        if (Map.class == type) {
                            return Collections.emptyMap();
                        } else if (List.class == type) {
                            return Collections.emptyList();
                        } else if (Set.class == type || Collection.class == type) {
                            return Collections.emptySet();
                        }
                        throw new NoSuchBeanDefinitionException(descriptor.getResolvableType(),
                                "Optional dependency not present for lazy injection point");
                    }
                    return target;
                }
                @Override
                public void releaseTarget(Object target) {
                }
            };   
    
            // 使用ProxyFactory  給ts生成一個代理
            // 因而可知最終生成的代理對象的目標對象實際上是TargetSource,而TargetSource的目標纔是咱們業務的對象
            ProxyFactory pf = new ProxyFactory();
            pf.setTargetSource(ts);
            Class<?> dependencyType = descriptor.getDependencyType();
            
            // 若是注入的語句是這麼寫的private AInterface a;  那這類就是藉口 值是true
            // 把這個接口類型也得放進去（否則這個代理都不屬於這個類型，反射set的時候豈不直接報錯了嗎？？？？）
            if (dependencyType.isInterface()) {
                pf.addInterface(dependencyType);
            }
            return pf.getProxy(beanFactory.getBeanClassLoader());
        }
    }

標註有@Lazy註解完成注入的時候，最終注入只是一個此處臨時生成的代理對象，只有在真正執行目標方法的時候纔會去容器內拿到真是的bean實例來執行目標方法。

利用allowRawInjectionDespiteWrapping屬性來強制改變判斷

@Component
    public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
        @Override
        public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
            ((AbstractAutowireCapableBeanFactory) beanFactory).setAllowRawInjectionDespiteWrapping(true);
        }
    }

這樣會致使容器裏面的是代理對象，暴露給其餘實例的是原始引用，致使不生效了。因爲它只對循環依賴內的Bean受影響，因此影響範圍並非全局，所以當找不到更好辦法的時候，此種這樣也不失是一個不錯的方案。