什麼是迴圈依賴？
就是A物件依賴了B物件，B物件依賴了A物件。
比如：
// A依賴了B class A{ public B b; } // B依賴了A class B{ public A a; }
那麼迴圈依賴是個問題嗎？
如果不考慮Spring，迴圈依賴並不是問題，因為物件之間相互依賴是很正常的事情。
比如
A a = new A(); B b = new B(); a.b = b; b.a = a;
這樣，A,B就依賴上了。
但是，在Spring中迴圈依賴就是一個問題了，為什麼？
因為，在Spring中，一個物件並不是簡單new出來了，而是會經過一系列的Bean的生命週期，就是因為Bean的生命週期所以才會出現迴圈依賴問題。當然，在Spring中，出現迴圈依賴的場景很多，有的場景Spring自動幫我們解決了，而有的場景則需要程式設計師來解決，下文詳細來說。
要明白Spring中的迴圈依賴，得先明白Spring中Bean的生命週期。
Bean的生命週期
這裡不會對Bean的生命週期進行詳細的描述，只描述一下大概的過程。
Bean的生命週期指的就是：在Spring中，Bean是如何生成的？
被Spring管理的物件叫做Bean。Bean的生成步驟如下：
1. Spring掃描class得到BeanDefinition
2. 根據得到的BeanDefinition去生成bean
3. 首先根據class推斷構造方法
4. 根據推斷出來的構造方法，反射，得到一個物件（暫時叫做原始物件）
5. 填充原始物件中的屬性（依賴注入）
6. 如果原始物件中的某個方法被AOP了，那麼則需要根據原始物件生成一個代理物件
7. 把最終生成的代理物件放入單例池（原始碼中叫做singletonObjects）中，下次getBean時就直接從單例池拿即可
可以看到，對於Spring中的Bean的生成過程，步驟還是很多的，並且不僅僅只有上面的7步，還有很多很多，比如Aware回撥、初始化等等，這裡不詳細討論。
可以發現，在Spring中，構造一個Bean，包括了new這個步驟（第4步構造方法反射）。
得到一個原始物件後，Spring需要給物件中的屬性進行依賴注入，那麼這個注入過程是怎樣的？
比如上文說的A類，A類中存在一個B類的b屬性，所以，當A類生成了一個原始物件之後，就會去給b屬性去賦值，此時就會根據b屬性的型別和屬性名去BeanFactory中去獲取B類所對應的單例bean。如果此時BeanFactory中存在B對應的Bean，那麼直接拿來賦值給b屬性；如果此時BeanFactory中不存在B對應的Bean，則需要生成一個B對應的Bean，然後賦值給b屬性。
問題就出現在第二種情況，如果此時B類在BeanFactory中還沒有生成對應的Bean，那麼就需要去生成，就會經過B的Bean的生命週期。
那麼在建立B類的Bean的過程中，如果B類中存在一個A類的a屬性，那麼在建立B的Bean的過程中就需要A類對應的Bean，但是，觸發B類Bean的建立的條件是A類Bean在建立過程中的依賴注入，所以這裡就出現了迴圈依賴：
ABean建立-->依賴了B屬性-->觸發BBean建立--->B依賴了A屬性--->需要ABean（但ABean還在建立過程中）
從而導致ABean建立不出來，BBean也建立不出來。
這是迴圈依賴的場景，但是上文說了，在Spring中，通過某些機制幫開發者解決了部分迴圈依賴的問題，這個機制就是三級快取。
三級快取
三級快取是通用的叫法。
一級快取為：singletonObjects
二級快取為：earlySingletonObjects
三級快取為：singletonFactories
先稍微解釋一下這三個快取的作用，後面詳細分析：
singletonObjects中快取的是已經經歷了完整生命週期的bean物件。
earlySingletonObjects比singletonObjects多了一個early，表示快取的是早期的bean物件。早期是什麼意思？表示Bean的生命週期還沒走完就把這個Bean放入earlySingletonObjects。
singletonFactories中快取的是ObjectFactory，表示物件工廠，用來建立某個物件的。
解決迴圈依賴思路分析
先來分析為什麼快取能解決迴圈依賴。
上文分析得到，之所以產生迴圈依賴的問題，主要是：
A建立時--->需要B---->B去建立--->需要A，從而產生了迴圈
那麼如何打破這個迴圈，加個中間人（快取）
A的Bean在建立過程中，在進行依賴注入之前，先把A的原始Bean放入快取（提早暴露，只要放到快取了，其他Bean需要時就可以從快取中拿了），放入快取後，再進行依賴注入，此時A的Bean依賴了B的Bean，如果B的Bean不存在，則需要建立B的Bean，而建立B的Bean的過程和A一樣，也是先建立一個B的原始物件，然後把B的原始物件提早暴露出來放入快取中，然後在對B的原始物件進行依賴注入A，此時能從快取中拿到A的原始物件（雖然是A的原始物件，還不是最終的Bean），B的原始物件依賴注入完了之後，B的生命週期結束，那麼A的生命週期也能結束。
因為整個過程中，都只有一個A原始物件，所以對於B而言，就算在屬性注入時，注入的是A原始物件，也沒有關係，因為A原始物件在後續的生命週期中在堆中沒有發生變化。
從上面這個分析過程中可以得出，只需要一個快取就能解決迴圈依賴了，那麼為什麼Spring中還需要singletonFactories呢？
這是難點，基於上面的場景想一個問題：如果A的原始物件注入給B的屬性之後，A的原始物件進行了AOP產生了一個代理物件，此時就會出現，對於A而言，它的Bean物件其實應該是AOP之後的代理物件，而B的a屬性對應的並不是AOP之後的代理物件，這就產生了衝突。
B依賴的A和最終的A不是同一個物件。
那麼如何解決這個問題？這個問題可以說沒有辦法解決。
因為在一個Bean的生命週期最後，Spring提供了BeanPostProcessor可以去對Bean進行加工，這個加工不僅僅只是能修改Bean的屬性值，也可以替換掉當前Bean。
舉個例子：
@Component public class User { }
@Component public class TestBeanPostProcessor implements BeanPostProcessor { @Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { // 生成了一個新的User物件 if (beanName.equals("user")) { System.out.println(bean); User user = new User(); return user; } return bean; } }
public class Test { public static void main(String[] args) { AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class); User user = context.getBean("user", User.class); System.out.println(user); } }
執行main方法，得到的列印如下：
com.test.service.User@67gh4rt3
com.test.service.User@56tr75b3
所以在BeanPostProcessor中可以完全替換掉某個beanName對應的bean物件。
而BeanPostProcessor的執行在Bean的生命週期中是處於屬性注入之後的，迴圈依賴是發生在屬性注入過程中的，所以很有可能導致，注入給B物件的A物件和經歷過完整生命週期之後的A物件，不是一個物件。這就是有問題的。
所以在這種情況下的迴圈依賴，Spring是解決不了的，因為在屬性注入時，Spring也不知道A物件後續會經過哪些BeanPostProcessor以及會對A物件做什麼處理。
Spring到底解決了哪種情況下的迴圈依賴
雖然上面的情況可能發生，但是肯定發生得很少，我們通常在開發過程中，不會這樣去做，但是，某個beanName對應的最終物件和原始物件不是一個物件卻會經常出現，這就是AOP。
AOP就是通過一個BeanPostProcessor來實現的，這個BeanPostProcessor就是AnnotationAwareAspectJAutoProxyCreator，它的父類是AbstractAutoProxyCreator，而在Spring中AOP利用的要麼是JDK動態代理，要麼CGLib的動態代理，所以如果給一個類中的某個方法設定了切面，那麼這個類最終就需要生成一個代理物件。
一般過程就是：A類--->生成一個普通物件-->屬性注入-->基於切面生成一個代理物件-->把代理物件放入singletonObjects單例池中。
而AOP可以說是Spring中除開IOC的另外一大功能，而迴圈依賴又是屬於IOC範疇的，所以這兩大功能想要並存，Spring需要特殊處理。
如何處理的，就是利用了第三級快取singletonFactories。
首先，singletonFactories中存的是某個beanName對應的ObjectFactory，在bean的生命週期中，生成完原始物件之後，就會構造一個ObjectFactory存入singletonFactories中。這個ObjectFactory是一個函式式介面，所以支援Lambda表示式：() -> getEarlyBeanReference(beanName, mbd, bean)
上面的Lambda表示式就是一個ObjectFactory，執行該Lambda表示式就會去執行getEarlyBeanReference方法，而該方法如下：
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { Object exposedObject = bean; if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof SmartInstantiationAwareBeanPostProcessor) { SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp; exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName); } } } return exposedObject; }
該方法會去執行SmartInstantiationAwareBeanPostProcessor中的getEarlyBeanReference方法，而這個介面下的實現類中只有兩個類實現了這個方法，一個是AbstractAutoProxyCreator，一個是InstantiationAwareBeanPostProcessorAdapter，它的實現如下：
// InstantiationAwareBeanPostProcessorAdapter @Override public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { return bean; }
// AbstractAutoProxyCreator @Override public Object getEarlyBeanReference(Object bean, String beanName) { Object cacheKey = getCacheKey(bean.getClass(), beanName); this.earlyProxyReferences.put(cacheKey, bean); return wrapIfNecessary(bean, beanName, cacheKey); }
所以很明顯，在整個Spring中，預設就只有AbstractAutoProxyCreator真正意義上實現了getEarlyBeanReference方法，而該類就是用來進行AOP的。上文提到的AnnotationAwareAspectJAutoProxyCreator的父類就是AbstractAutoProxyCreator。
那麼getEarlyBeanReference方法到底在幹什麼？
首先得到一個cachekey，cachekey就是beanName。
然後把beanName和bean（這是原始物件）存入earlyProxyReferences中
呼叫wrapIfNecessary進行AOP，得到一個代理物件。
那麼，什麼時候會呼叫getEarlyBeanReference方法呢？回到迴圈依賴的場景中
左邊文字：
這個ObjectFactory就是上文說的labmda表示式，中間有getEarlyBeanReference方法，注意存入singletonFactories時並不會執行lambda表示式，也就是不會執行getEarlyBeanReference方法
右邊文字：
從singletonFactories根據beanName得到一個ObjectFactory，然後執行ObjectFactory，也就是執行getEarlyBeanReference方法，此時會得到一個A原始物件經過AOP之後的代理物件，然後把該代理物件放入earlySingletonObjects中，注意此時並沒有把代理物件放入singletonObjects中，那什麼時候放入到singletonObjects中呢？
這個時候得來理解一下earlySingletonObjects的作用，此時，我們只得到了A原始物件的代理物件，這個物件還不完整，因為A原始物件還沒有進行屬性填充，所以此時不能直接把A的代理物件放入singletonObjects中，所以只能把代理物件放入earlySingletonObjects，假設現在有其他物件依賴了A，那麼則可以從earlySingletonObjects中得到A原始物件的代理物件了，並且是A的同一個代理物件。
當B建立完了之後，A繼續進行生命週期，而A在完成屬性注入後，會按照它本身的邏輯去進行AOP，而此時我們知道A原始物件已經經歷過了AOP，所以對於A本身而言，不會再去進行AOP了，那麼怎麼判斷一個物件是否經歷過了AOP呢？會利用上文提到的earlyProxyReferences，在AbstractAutoProxyCreator的postProcessAfterInitialization方法中，會去判斷當前beanName是否在earlyProxyReferences，如果在則表示已經提前進行過AOP了，無需再次進行AOP。
對於A而言，進行了AOP的判斷後，以及BeanPostProcessor的執行之後，就需要把A對應的物件放入singletonObjects中了，但是我們知道，應該是要A的代理物件放入singletonObjects中，所以此時需要從earlySingletonObjects中得到代理物件，然後入singletonObjects中。
整個迴圈依賴解決完畢。
總結
總結一下三級快取：
1. singletonObjects：快取某個beanName對應的經過了完整生命週期的bean
2. earlySingletonObjects：快取提前拿原始物件進行了AOP之後得到的代理物件，原始物件還沒有進行屬性注入和後續的BeanPostProcessor等生命週期
3. singletonFactories：快取的是一個ObjectFactory，主要用來去生成原始物件進行了AOP之後得到的代理物件，在每個Bean的生成過程中，都會提前暴露一個工廠，這個工廠可能用到，也可能用不到，如果沒有出現迴圈依賴依賴本bean，那麼這個工廠無用，本bean按照自己的生命週期執行，執行完後直接把本bean放入singletonObjects中即可，如果出現了迴圈依賴依賴了本bean，則另外那個bean執行ObjectFactory提交得到一個AOP之後的代理物件(如果有AOP的話，如果無需AOP，則直接得到一個原始物件)。
4. 其實還要一個快取，就是earlyProxyReferences，它用來記錄某個原始物件是否進行過AOP了