徹底理解SpringIOC、DI-這篇文章就夠了
本文已收錄在公眾號：https://mp.weixin.qq.com/s/FIm84EGVV21phajCaLjgaA
前言
你可能會有如下問題：
1、想看Spring原始碼，但是不知道應當如何入手去看，對整個Bean的流程沒有概念，碰到相關問題也沒有頭緒如何下手
2、看過幾遍原始碼，沒辦法徹底理解，沒什麼感覺，沒過一陣子又忘了
本文將結合實際問題，由問題引出原始碼，並在解釋時會盡量以圖表的形式讓你一步一步徹底理解Spring Bean的IOC/">IOC、DI、生命週期、作用域等。
先看一個迴圈依賴問題
現象
迴圈依賴其實就是迴圈引用，也就是兩個或則兩個以上的bean互相持有對方，最終形成閉環。比如A依賴於B，B依賴於C，C又依賴於A。如下圖：
如何理解“依賴”呢，在Spring中有：
- 構造器迴圈依賴
- field屬性注入迴圈依賴
直接上程式碼：
構造器迴圈依賴
@Service
public class A {
public A(B b) {}
}
複製程式碼
@Service
public class B {
public B(C c) {
}
}
複製程式碼
@Service
public class C {
public C(A a) {}
}複製程式碼
結果：專案啟動失敗，發現了一個cycle。
2.field屬性注入迴圈依賴
@Service
public class A1 {
@Autowired
private B1 b1;
}複製程式碼
@Service
public class B1 {
@Autowired
public C1 c1;
}複製程式碼
@Service
public class C1 {
@Autowiredpublic A1 a1;
}複製程式碼
結果：專案啟動成功
3.field屬性注入迴圈依賴（prototype）
@Service
@Scope("prototype")
public class A1 {
@Autowired
private B1 b1;
}複製程式碼
@Service
@Scope("prototype")
public class B1 {
@Autowired
public C1 c1;
}複製程式碼
@Service
@Scope("prototype")
public class C1 {
@Autowiredpublic A1 a1;
}複製程式碼
結果：專案啟動失敗，發現了一個cycle。
現象總結：同樣對於迴圈依賴的場景，構造器注入和prototype型別的屬性注入都會初始化Bean失敗。因為@Service預設是單例的，所以單例的屬性注入是可以成功的。
分析原因
分析原因也就是在發現SpringIOC的過程，如果對原始碼不感興趣可以關注每段原始碼分析之後的 總結和迴圈依賴問題的分析 即可。
SpringBean的載入流程（原始碼分析）
簡單一段程式碼作為入口
ApplicationContext ac = new ClassPathXmlApplicationContext("spring.xml"); ac.getBean(XXX.class);複製程式碼
ClassPathXmlApplicationContext是一個載入XML配置檔案的類，與之相對的還有AnnotationConfigWebApplicationContext，這兩個類大差不差的，只是ClassPathXmlApplicationContext的Resource是XML檔案而AnnotationConfigWebApplicationContext是Scan註解獲得的。
看到第二行就已經可以直接獲取bean的例項了，所以第一行構造方法時，就已經完成了對所有bean的載入。
ClassPathXmlApplicationContext舉例，他裡面儲存的東西如下：
| 物件名 | 類 型 | 作 用 | 歸屬類 |
| configResources | Resource[] | 配置檔案資源物件陣列 | ClassPathXmlApplicationContext |
| configLocations | String[] | 配置檔案字串陣列，儲存配置檔案路徑 | AbstractRefreshableConfigApplicationContext |
| beanFactory | DefaultListableBeanFactory | 上下文使用的Bean工廠 | AbstractRefreshableApplicationContext |
| beanFactoryMonitor | Object | Bean工廠使用的同步監視器 | AbstractRefreshableApplicationContext |
| id | String | 上下文使用的唯一Id，標識此ApplicationContext | AbstractApplicationContext |
| parent | ApplicationContext | 父級ApplicationContext | AbstractApplicationContext |
| beanFactoryPostProcessors | List<BeanFactoryPostProcessor> | 儲存BeanFactoryPostProcessor介面，Spring提供的一個擴充套件點 | AbstractApplicationContext |
| startupShutdownMonitor | Object | refresh方法和destory方法公用的一個監視器，避免兩個方法同時執行 | AbstractApplicationContext |
| shutdownHook | Thread | Spring提供的一個鉤子，JVM停止執行時會執行Thread裡面的方法 | AbstractApplicationContext |
| resourcePatternResolver | ResourcePatternResolver | 上下文使用的資源格式解析器 | AbstractApplicationContext |
| lifecycleProcessor | LifecycleProcessor | 用於管理Bean生命週期的生命週期處理器介面 | AbstractApplicationContext |
| messageSource | MessageSource | 用於實現國際化的一個介面 | AbstractApplicationContext |
| applicationEventMulticaster | ApplicationEventMulticaster | Spring提供的事件管理機制中的事件多播器介面 | AbstractApplicationContext |
| applicationListeners | Set<ApplicationListener> | Spring提供的事件管理機制中的應用監聽器 | AbstractApplicationContext |
構造方法如下：
接下來大概看看refresh方法：
子方法先不看，先看看refresh方法的結構，其實就有幾點值得學習：
1、方法為什麼加鎖？ 是為了避免多執行緒的場景下同時重新整理Spring上下文
2、雖然整個方法是加鎖的，但是卻用了Synchronized關鍵字的物件鎖startUpShutdownMonitor，這樣做有兩個好處：
（1）關閉資源的時候會呼叫close()方法，close()方法也使用了同樣的物件鎖，而關閉資源的close和refresh的兩個衝突的方法，這樣可以避免衝突
（2）此處物件鎖相對於整個方法加鎖的話，同步的範圍更小了，鎖的粒度更小，效率更高
3、這個方法refresh定義了整個Spring IOC的流程，每一個方法名字都清晰易懂，可維護性、可讀性很強
總結：看原始碼需要找准入口，看的時候多思考，學習Spring的巧妙的設計。ApplicationContext的構造方法中最關鍵是方法是refresh，其中有一些比價好的設計。
obtainFreshBeanFactory方法
這個方法作用是獲取重新整理Spring上下文的Bean工廠：
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
this.refreshBeanFactory();
return this.getBeanFactory();
}複製程式碼
protected final void refreshBeanFactory() throws BeansException {
if (this.hasBeanFactory()) {
this.destroyBeans();
this.closeBeanFactory();
}
try {
DefaultListableBeanFactory beanFactory = this.createBeanFactory();
beanFactory.setSerializationId(this.getId());
this.customizeBeanFactory(beanFactory);
this.loadBeanDefinitions(beanFactory);
synchronized(this.beanFactoryMonitor) {
this.beanFactory = beanFactory;}
} catch (IOException var5) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + this.getDisplayName(), var5);
}
}複製程式碼
這斷程式碼的核心是 DefaultListableBeanFactory， 核心類我們再整理一下，以圖表格式：
下面有三個加粗的Map，這些個Map是解決問題的關鍵。。。我們之後詳細分析
| 物件名 | 類 型 | 作 用 | 歸屬類 |
| aliasMap | Map<String, String> | 儲存Bean名稱->Bean別名對映關係 | SimpleAliasRegistry |
| singletonObjects | Map<String, Object> | 儲存單例Bean名稱->單例Bean實現對映關係 | DefaultSingletonBeanRegistry |
| singletonFactories | Map<String, ObjectFactory> | 儲存Bean名稱->ObjectFactory實現對映關係 | DefaultSingletonBeanRegistry |
| earlySingletonObjects | Map<String, Object> | 儲存Bean名稱->預載入Bean實現對映關係 | DefaultSingletonBeanRegistry |
| registeredSingletons | Set<String> | 儲存註冊過的Bean名 | DefaultSingletonBeanRegistry |
| singletonsCurrentlyInCreation | Set<String> | 儲存當前正在建立的Bean名 | DefaultSingletonBeanRegistry |
| disposableBeans | Map<String, Object> | 儲存Bean名稱->Disposable介面實現Bean實現對映關係 |
DefaultSingletonBeanRegistry |
| factoryBeanObjectCache | Map<String, Object> | 儲存Bean名稱->FactoryBean介面Bean實現對映關係 | FactoryBeanRegistrySupport |
| propertyEditorRegistrars | Set<PropertyEditorRegistrar> | 儲存PropertyEditorRegistrar介面實現集合 | AbstractBeanFactory |
| embeddedValueResolvers | List<StringValueResolver> | 儲存StringValueResolver（字串解析器）介面實現列表 | AbstractBeanFactory |
| beanPostProcessors | List<BeanPostProcessor> | 儲存 BeanPostProcessor介面實現列表 | AbstractBeanFactory |
| mergedBeanDefinitions | Map<String, RootBeanDefinition> | 儲存Bean名稱->合併過的根Bean定義對映關係 | AbstractBeanFactory |
| alreadyCreated | Set<String> | 儲存至少被建立過一次的Bean名集合 | AbstractBeanFactory |
| ignoredDependencyInterfaces | Set<Class> | 儲存不自動裝配的介面Class物件集合 | AbstractAutowireCapableBeanFactory |
| resolvableDependencies | Map<Class, Object> | 儲存修正過的依賴對映關係 | DefaultListableBeanFactory |
| beanDefinitionMap | Map<String, BeanDefinition> | 儲存Bean名稱-->Bean定義對映關係 | DefaultListableBeanFactory |
| beanDefinitionNames | List<String> | 儲存Bean定義名稱列表 | DefaultListableBeanFactory |
BeanDefinition在IOC容器中的註冊
接下來簡要分析一下 loadBeanDefinitions。
對於這個BeanDefinition，我是這麼理解的: 它是SpringIOC過程中間的一個產物，可以看成是對Bean定義的抽象，裡面封裝的資料都是與Bean定義相關的，封裝了一些基本的bean的Property、initi-method、destroy-method等。
這裡的主要方法是 loadBeanDefinitions， 這裡不詳細展開說，它主要做了幾件事：
1、初始化了BeanDefinitionReader
2、通過BeanDefinitionReader獲取Resource，也就是xml配置檔案的位置，並且把檔案轉換成一個叫Document的物件
3、接下來需要將Document物件轉化成容器內部的資料結構（也就是BeanDefinition），也即是將Bean定義的List、Map、Set等各種元素進行解析，轉換成Managed類（Spring對BeanDefinition資料的封裝)放在BeanDefinition中；這個方法是RegisterBeanDefinition()，也就是解析的過程。
4、解析完成後，會把解析的結果放到BeanDefinition物件中並設定到一個Map中
以上這個過程就是BeanDefinition在IOC容器中的註冊。
再回到Refresh方法，總結每一步如下圖：
總結：這一部分步驟主要是Spring如何載入Xml檔案或者註解，並把它解析成BeanDefinition。
Spring建立Bean的過程
先回到之前的refresh方法(也就是在構造ApplicationContext時的方法)，我們跳過不重要的部分：
我們直接看 finishBeanFactoryInitialization 裡面的preInstantiateSingletons方法，顧名思義初始化所有的單例bean，擷取部分如下：
現在來看核心的getBean方法，對於所有獲取Bean物件是例項，都是用這個getBean方法，這個方法最終呼叫的是doGetBean方法，這個方法就是所謂的DI（依賴注入）發生的地方。
程式=資料+演算法，之前的BeanDefinition就是“資料”，依賴注入也就是在BeanDefinition準備好情況下進行進行的，這個過程不簡單，因為Spring提供了很多引數配置，每一個引數都代表了IOC容器的特性，這些特性的實現需要在Bean的生命週期中完成。
程式碼比較多，就不貼了，大家可以自行檢視AbstractBeanFactory裡面的doGetBean方法,這裡直接上圖，這個圖就是依賴注入的整個過程：
總結：Spring建立好了BeanDefinition之後呢，會開始例項化Bean，並且對Bean的依賴屬性進行填充。例項化時底層使用了CGLIB或Java反射技術。上圖中instantiateBean核PupulateBean方法很重要！
迴圈依賴問題分析
我們先總結一下之前的結論：
1、構造器注入和prototype型別的field注入發生迴圈依賴時都無法初始化
2、field注入單例的bean時，儘管有迴圈依賴，但bean仍然可以被成功初始化
針對這幾個結論，提出問題
- 單例的設值注入bean是如何解決迴圈依賴問題呢？如果A中注入了B，那麼他們初始化的順序是什麼樣子的？
- 為什麼prototype型別的和構造器型別的Spring無法解決迴圈依賴呢？
之前在DefaultListableBeanFactory類中，列出了一個表格；現在我把關鍵的精華屬性列出來：
一級快取： /** 儲存所有的singletonBean的例項 */ private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64); 二級快取： /** 儲存所有早期建立的Bean物件，這個Bean還沒有完成依賴注入 */ private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16); 三級快取： /** singletonBean的生產工廠*/ private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16); /** 儲存所有已經完成初始化的Bean的名字（name） */ private final Set<String> registeredSingletons = new LinkedHashSet<String>(64); /** 標識指定name的Bean物件是否處於建立狀態這個狀態非常重要 */ private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16)); 複製程式碼
前面三個Map，我們稱為單例初始化的三級快取，理解這個問題， 我們目前只需關注“三級”，也就是 singletonFactories
分析：
對於問題1，單例的設值注入，如果A中注入了B，B應該是A中的一個屬性，那麼猜想應該是A已經被instantiate（例項化）之後，在populateBean（填充A中的屬性）時，對B進行初始化。
對於問題2，instantiate（例項化）其實就是理解成new一個物件的過程，而new的時候肯定要執行構造方法，所以猜想對於應該是A在instantiate（例項化）時，進行B的初始化。
有了分析和猜想之後呢，圍繞關鍵的屬性，根據從上圖的doGetBean方法開始到populateBean所有的程式碼，我整理了如下圖：
上圖是整個過程中關鍵的程式碼路徑，感興趣的可以自己debug幾回，最關鍵的解決迴圈依賴的是如上的兩個標紅的方法，第一個方法getSingleton會從singletonFactories裡面拿Singleton，而addSingletonFactory會把Singleton放入singletonFactories。
對於問題1：單例的設值注入bean是如何解決迴圈依賴問題呢？如果A中注入了B，那麼他們初始化的順序是什麼樣子的？
假設迴圈注入是A-B-A：A依賴B(A中autowire了B)，B又依賴A（B中又autowire了A）：
本質就是三級快取發揮作用，解決了迴圈。
對於當時問題2，instantiate（例項化）其實就是理解成new一個物件的過程，而new的時候肯定要執行構造方法，所以猜想對於應該是A在instantiate（例項化）時，進行B的初始化。
答案也很簡單，因為A中構造器注入了B，那麼A在關鍵的方法addSingletonFactory()之前就去初始化了B，導致三級快取中根本沒有A，所以會發生死迴圈，Spring發現之後就丟擲異常了。至於Spring是如何發現異常的呢，本質上是根據Bean的狀態給Bean進行mark，如果遞迴呼叫時發現bean當時正在建立中，那麼久丟擲迴圈依賴的異常即可。
那麼prototype的Bean是如何初始化的呢？
prototypeBean有一個關鍵的屬性：
/** Names of beans that are currently in creation */ private final ThreadLocal<Object> prototypesCurrentlyInCreation = new NamedThreadLocal<Object>("Prototype beans currently in creation"); 複製程式碼
儲存著正在建立的prototype的beanName，在流程上並沒有暴露任何factory之類的快取。並且在 beforePrototypeCreation(String beanName) 方法時，把每個正在建立的prototype的BeanName放入一個set中：
protected void beforePrototypeCreation(String beanName) {
Object curVal = this.prototypesCurrentlyInCreation.get();
if (curVal == null) {
this.prototypesCurrentlyInCreation.set(beanName);
}
else if (curVal instanceof String) {
Set<String> beanNameSet = new HashSet<String>(2);
beanNameSet.add((String) curVal);
beanNameSet.add(beanName);
this.prototypesCurrentlyInCreation.set(beanNameSet);
}
else {
Set<String> beanNameSet = (Set<String>) curVal;
beanNameSet.add(beanName);
}
}複製程式碼
並且會迴圈依賴時檢查beanName是否處於建立狀態，如果是就丟擲異常：
protected boolean isPrototypeCurrentlyInCreation(String beanName) {
Object curVal = this.prototypesCurrentlyInCreation.get();
return (curVal != null &&
(curVal.equals(beanName) || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName))));
}複製程式碼
從流程上就可以檢視，無論是構造注入還是設值注入，第二次進入同一個Bean的getBean方法是，一定會在校驗部分丟擲異常，因此不能完成注入，也就不能實現迴圈引用。
總結：Spring在InstantiateBean時執行構造器方法，構造出例項，如果是單例的話，會將它放入一個 singletonBeanFactory 的快取中，再進行populateBean方法，設定屬性。通過一個singletonBeanFactory的快取解決了迴圈依賴的問題。
再解決一個問題
現在大家已經對Spring整個流程有點感覺了，我們再來解決一個簡單的常見的問題：
考慮一下如下的singleton程式碼：
@Service
public class SingletonBean{
@Autowired
private PrototypeBean prototypeBean;
public void doSomething(){
System.out.println(prototypeBean.toString());}
}複製程式碼
@Component
@Scope(value="prototype")
public class PrototypeBean{
}複製程式碼
一個Singleton的Bean中Autowired了一個prototype的Bean，那麼問題來了，每次呼叫 SingletonBean.doSomething() 時列印的物件是不是同一個呢？
有了之前的知識儲備，我們簡單分析一下：因為Singleton是單例的，所以在專案啟動時就會初始化， prototypeBean 本質上只是它的一個Property，那麼ApplicationContex中只存在一個SingletonBean和一個初始化SingletonBean時建立的一個prototype型別的PrototypeBean。
那麼每次呼叫SingletonBean.doSomething()時，Spring會從ApplicationContex中獲取SingletonBean，每次獲取的SingletonBean是同一個，所以即便PrototypeBean是prototype的，但PrototypeBean仍然是同一個。每次打印出來的記憶體地址肯定是同一個。
那這個問題如何解決呢？
解決辦法也很簡單，這種情況我們不能通過注入的方式注入一個prototypeBean，只能在程式執行時手動呼叫getBean("prototypeBean")方法，我寫了一個簡單的工具類：
@Service
public class SpringBeanUtils implements ApplicationContextAware {
private static ApplicationContext appContext;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
SpringBeanUtils.appContext=applicationContext;
}
public static ApplicationContext getAppContext() {
return appContext;
}
public static Object getBean(String beanName) {
checkApplicationContext();
return appContext.getBean(beanName);
}
private static void checkApplicationContext() {
if (null == appContext) {
throw new IllegalStateException("applicaitonContext未注入");
}
}
@SuppressWarnings("unchecked")
public static <T> T getBean(Class<T> clazz) {
checkApplicationContext();
Map<?, ?> map = appContext.getBeansOfType(clazz);
return map.isEmpty() ? null : (T) map.values().iterator().next();
}
}複製程式碼
對於這個ApplicationContextAware介面：
在某些特殊的情況下，Bean需要實現某個功能，但該功能必須藉助於Spring容器才能實現，此時就必須讓該Bean先獲取Spring容器，然後藉助於Spring容器實現該功能。為了讓Bean獲取它所在的Spring容器，可以讓該Bean實現ApplicationContextAware介面。
感興趣的讀者自己可以試試。
總結：
回到迴圈依賴的問題，有的人可能會問singletonBeanFactory只是一個三級快取，那麼一級快取和二級快取有什麼用呢？
其實大家只要理解整個流程就可以切入了，Spring在初始化Singleton的時候大致可以分幾步，初始化——設值——銷燬，迴圈依賴的場景下只有A——B——A這樣的順序，但在併發的場景下，每一步在執行時，都有可能呼叫getBean方法，而單例的Bean需要保證只有一個instance，那麼Spring就是通過這些個快取外加物件鎖去解決這類問題，同時也可以省去不必要的重複操作。Spring的鎖的粒度選取也是很吊的，這裡暫時不深入研究了。
解決此類問題的關鍵是要對SpringIOC和DI的整個流程做到心中有數，看原始碼一般情況下不要求每一行程式碼都瞭解透徹，但是對於整個的流程和每個流程中在做什麼事需要了然，這樣實際遇到問題時才可以很快的切入進行分析解決。
希望這篇文章可以幫助你對Spring的IOC和DI的流程有一個更深刻的認識！