前言

你可能會(huì)有如下問題：

1、想看Spring源碼，但是不知道應(yīng)當(dāng)如何入手去看，對(duì)整個(gè)Bean的流程沒有概念，碰到相關(guān)問題也沒有頭緒如何下手

2、看過幾遍源碼，沒辦法徹底理解，沒什么感覺，沒過一陣子又忘了

本文將結(jié)合實(shí)際問題，由問題引出源碼，并在解釋時(shí)會(huì)盡量以圖表的形式讓你一步一步徹底理解Spring Bean的IOC、DI、生命周期、作用域等。

先看一個(gè)循環(huán)依賴問題

現(xiàn)象

循環(huán)依賴其實(shí)就是循環(huán)引用，也就是兩個(gè)或則兩個(gè)以上的bean互相持有對(duì)方，最終形成閉環(huán)。比如A依賴于B，B依賴于C，C又依賴于A。如下圖：

如何理解“依賴”呢，在Spring中有：

• 構(gòu)造器循環(huán)依賴
• field屬性注入循環(huán)依賴

直接上代碼：

1.構(gòu)造器循環(huán)依賴

@Service
public class A { 
 public A(B b) { }
}

@Service
public class B { 
 public B(C c) { 
 }
}

@Service
public class C { 
 public C(A a) { }
}

結(jié)果：項(xiàng)目啟動(dòng)失敗，發(fā)現(xiàn)了一個(gè)cycle。

 2.field屬性注入循環(huán)依賴

@Service
public class A1 { 
 @Autowired 
 private B1 b1;
}

@Service
public class B1 { 
 @Autowired 
 public C1 c1;
}

@Service
public class C1 { 
 @Autowired public A1 a1;
}

結(jié)果：項(xiàng)目啟動(dòng)成功

3.field屬性注入循環(huán)依賴（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 { 
 @Autowired public A1 a1;
}

結(jié)果：項(xiàng)目啟動(dòng)失敗，發(fā)現(xiàn)了一個(gè)cycle。

現(xiàn)象總結(jié)：同樣對(duì)于循環(huán)依賴的場(chǎng)景，構(gòu)造器注入和prototype類型的屬性注入都會(huì)初始化Bean失敗。因?yàn)锧Service默認(rèn)是單例的，所以單例的屬性注入是可以成功的。

更多關(guān)于 Spring 相關(guān)的文章，我已經(jīng)整理成了 PDF ，關(guān)注微信公眾號(hào)：Java后端，回復(fù) 666 獲取。

分析原因

分析原因也就是在發(fā)現(xiàn)SpringIOC的過程，如果對(duì)源碼不感興趣可以關(guān)注每段源碼分析之后的總結(jié)和循環(huán)依賴問題的分析即可。 

SpringBean的加載流程（源碼分析）

簡(jiǎn)單一段代碼作為入口

ApplicationContext ac = new ClassPathXmlApplicationContext("spring.xml");
ac.getBean(XXX.class);

ClassPathXmlApplicationContext是一個(gè)加載XML配置文件的類，與之相對(duì)的還有AnnotationConfigWebApplicationContext，這兩個(gè)類大差不差的，只是ClassPathXmlApplicationContext的Resource是XML文件而AnnotationConfigWebApplicationContext是Scan注解獲得的。

 看到第二行就已經(jīng)可以直接獲取bean的實(shí)例了，所以第一行構(gòu)造方法時(shí)，就已經(jīng)完成了對(duì)所有bean的加載。

ClassPathXmlApplicationContext舉例，他里面儲(chǔ)存的東西如下：

構(gòu)造方法如下：

接下來大概看看refresh方法：

子方法先不看，先看看refresh方法的結(jié)構(gòu)，其實(shí)就有幾點(diǎn)值得學(xué)習(xí)：

1、方法為什么加鎖？是為了避免多線程的場(chǎng)景下同時(shí)刷新Spring上下文

2、雖然整個(gè)方法是加鎖的，但是卻用了Synchronized關(guān)鍵字的對(duì)象鎖startUpShutdownMonitor，這樣做有兩個(gè)好處：

（1）關(guān)閉資源的時(shí)候會(huì)調(diào)用close()方法，close()方法也使用了同樣的對(duì)象鎖，而關(guān)閉資源的close和refresh的兩個(gè)沖突的方法，這樣可以避免沖突

（2）此處對(duì)象鎖相對(duì)于整個(gè)方法加鎖的話，同步的范圍更小了，鎖的粒度更小，效率更高

3、這個(gè)方法refresh定義了整個(gè)Spring IOC的流程，每一個(gè)方法名字都清晰易懂，可維護(hù)性、可讀性很強(qiáng)

總結(jié)：看源碼需要找準(zhǔn)入口，看的時(shí)候多思考，學(xué)習(xí)Spring的巧妙的設(shè)計(jì)。ApplicationContext的構(gòu)造方法中最關(guān)鍵是方法是refresh，其中有一些比價(jià)好的設(shè)計(jì)。

obtainFreshBeanFactory方法

這個(gè)方法作用是獲取刷新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，核心類我們?cè)僬硪幌拢詧D表格式：

下面有三個(gè)加粗的Map，這些個(gè)Map是解決問題的關(guān)鍵。。。我們之后詳細(xì)分析

BeanDefinition在IOC容器中的注冊(cè)

接下來簡(jiǎn)要分析一下loadBeanDefinitions。

對(duì)于這個(gè)BeanDefinition，我是這么理解的: 它是SpringIOC過程中間的一個(gè)產(chǎn)物，可以看成是對(duì)Bean定義的抽象，里面封裝的數(shù)據(jù)都是與Bean定義相關(guān)的，封裝了一些基本的bean的Property、initi-method、destroy-method等。

這里的主要方法是loadBeanDefinitions，這里不詳細(xì)展開說，它主要做了幾件事：

1、初始化了BeanDefinitionReader

2、通過BeanDefinitionReader獲取Resource，也就是xml配置文件的位置，并且把文件轉(zhuǎn)換成一個(gè)叫Document的對(duì)象

3、接下來需要將Document對(duì)象轉(zhuǎn)化成容器內(nèi)部的數(shù)據(jù)結(jié)構(gòu)（也就是BeanDefinition），也即是將Bean定義的List、Map、Set等各種元素進(jìn)行解析，轉(zhuǎn)換成Managed類（Spring對(duì)BeanDefinition數(shù)據(jù)的封裝)放在BeanDefinition中；這個(gè)方法是RegisterBeanDefinition()，也就是解析的過程。

4、解析完成后，會(huì)把解析的結(jié)果放到BeanDefinition對(duì)象中并設(shè)置到一個(gè)Map中

以上這個(gè)過程就是BeanDefinition在IOC容器中的注冊(cè)。

再回到Refresh方法，總結(jié)每一步如下圖：

總結(jié)：這一部分步驟主要是Spring如何加載Xml文件或者注解，并把它解析成BeanDefinition。

Spring創(chuàng)建Bean的過程

先回到之前的refresh方法(也就是在構(gòu)造ApplicationContext時(shí)的方法)，我們跳過不重要的部分：

我們直接看finishBeanFactoryInitialization里面的preInstantiateSingletons方法，顧名思義初始化所有的單例bean，截取部分如下：

現(xiàn)在來看核心的getBean方法，對(duì)于所有獲取Bean對(duì)象是實(shí)例，都是用這個(gè)getBean方法，這個(gè)方法最終調(diào)用的是doGetBean方法，這個(gè)方法就是所謂的DI（依賴注入）發(fā)生的地方。

程序=數(shù)據(jù)+算法，之前的BeanDefinition就是“數(shù)據(jù)”，依賴注入也就是在BeanDefinition準(zhǔn)備好情況下進(jìn)行進(jìn)行的，這個(gè)過程不簡(jiǎn)單，因?yàn)镾pring提供了很多參數(shù)配置，每一個(gè)參數(shù)都代表了IOC容器的特性，這些特性的實(shí)現(xiàn)需要在Bean的生命周期中完成。

代碼比較多，就不貼了，大家可以自行查看AbstractBeanFactory里面的doGetBean方法,這里直接上圖，這個(gè)圖就是依賴注入的整個(gè)過程：

總結(jié)：Spring創(chuàng)建好了BeanDefinition之后呢，會(huì)開始實(shí)例化Bean，并且對(duì)Bean的依賴屬性進(jìn)行填充。實(shí)例化時(shí)底層使用了CGLIB或Java反射技術(shù)。上圖中instantiateBean核PupulateBean方法很重要！

循環(huán)依賴問題分析

我們先總結(jié)一下之前的結(jié)論：

1、構(gòu)造器注入和prototype類型的field注入發(fā)生循環(huán)依賴時(shí)都無法初始化

2、field注入單例的bean時(shí)，盡管有循環(huán)依賴，但bean仍然可以被成功初始化

針對(duì)這幾個(gè)結(jié)論，提出問題

單例的設(shè)值注入bean是如何解決循環(huán)依賴問題呢？如果A中注入了B，那么他們初始化的順序是什么樣子的？

為什么prototype類型的和構(gòu)造器類型的Spring無法解決循環(huán)依賴呢？

之前在DefaultListableBeanFactory類中，列出了一個(gè)表格；現(xiàn)在我把關(guān)鍵的精華屬性列出來：

一級(jí)緩存：
/** 保存所有的singletonBean的實(shí)例 */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);

二級(jí)緩存：
/** 保存所有早期創(chuàng)建的Bean對(duì)象，這個(gè)Bean還沒有完成依賴注入 */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
三級(jí)緩存：
/** singletonBean的生產(chǎn)工廠*/
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
 
/** 保存所有已經(jīng)完成初始化的Bean的名字（name） */
private final Set<String> registeredSingletons = new LinkedHashSet<String>(64);
 
/** 標(biāo)識(shí)指定name的Bean對(duì)象是否處于創(chuàng)建狀態(tài) 這個(gè)狀態(tài)非常重要 */
private final Set<String> singletonsCurrentlyInCreation =
	Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16));

前面三個(gè)Map，我們稱為單例初始化的三級(jí)緩存，理解這個(gè)問題，我們目前只需關(guān)注“三級(jí)”，也就是singletonFactories

分析：

對(duì)于問題1，單例的設(shè)值注入，如果A中注入了B，B應(yīng)該是A中的一個(gè)屬性，那么猜想應(yīng)該是A已經(jīng)被instantiate（實(shí)例化）之后，在populateBean（填充A中的屬性）時(shí)，對(duì)B進(jìn)行初始化。

對(duì)于問題2，instantiate（實(shí)例化）其實(shí)就是理解成new一個(gè)對(duì)象的過程，而new的時(shí)候肯定要執(zhí)行構(gòu)造方法，所以猜想對(duì)于應(yīng)該是A在instantiate（實(shí)例化）時(shí)，進(jìn)行B的初始化。

有了分析和猜想之后呢，圍繞關(guān)鍵的屬性，根據(jù)從上圖的doGetBean方法開始到populateBean所有的代碼，我整理了如下圖：

上圖是整個(gè)過程中關(guān)鍵的代碼路徑，感興趣的可以自己debug幾回，最關(guān)鍵的解決循環(huán)依賴的是如上的兩個(gè)標(biāo)紅的方法，第一個(gè)方法getSingleton會(huì)從singletonFactories里面拿Singleton，而addSingletonFactory會(huì)把Singleton放入singletonFactories。

對(duì)于問題1：?jiǎn)卫脑O(shè)值注入bean是如何解決循環(huán)依賴問題呢？如果A中注入了B，那么他們初始化的順序是什么樣子的？

假設(shè)循環(huán)注入是A-B-A：A依賴B(A中autowire了B)，B又依賴A（B中又autowire了A）：

本質(zhì)就是三級(jí)緩存發(fā)揮作用，解決了循環(huán)。

對(duì)于當(dāng)時(shí)問題2，instantiate（實(shí)例化）其實(shí)就是理解成new一個(gè)對(duì)象的過程，而new的時(shí)候肯定要執(zhí)行構(gòu)造方法，所以猜想對(duì)于應(yīng)該是A在instantiate（實(shí)例化）時(shí)，進(jìn)行B的初始化。

答案也很簡(jiǎn)單，因?yàn)锳中構(gòu)造器注入了B，那么A在關(guān)鍵的方法addSingletonFactory()之前就去初始化了B，導(dǎo)致三級(jí)緩存中根本沒有A，所以會(huì)發(fā)生死循環(huán)，Spring發(fā)現(xiàn)之后就拋出異常了。至于Spring是如何發(fā)現(xiàn)異常的呢，本質(zhì)上是根據(jù)Bean的狀態(tài)給Bean進(jìn)行mark，如果遞歸調(diào)用時(shí)發(fā)現(xiàn)bean當(dāng)時(shí)正在創(chuàng)建中，那么久拋出循環(huán)依賴的異常即可。

那么prototype的Bean是如何初始化的呢？

prototypeBean有一個(gè)關(guān)鍵的屬性：

/** Names of beans that are currently in creation */
private final ThreadLocal<Object> prototypesCurrentlyInCreation =
	new NamedThreadLocal<Object>("Prototype beans currently in creation");

保存著正在創(chuàng)建的prototype的beanName，在流程上并沒有暴露任何factory之類的緩存。并且在beforePrototypeCreation(String beanName)方法時(shí)，把每個(gè)正在創(chuàng)建的prototype的BeanName放入一個(gè)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);
		}
}

并且會(huì)循環(huán)依賴時(shí)檢查beanName是否處于創(chuàng)建狀態(tài)，如果是就拋出異常：

protected boolean isPrototypeCurrentlyInCreation(String beanName) {
 Object curVal = this.prototypesCurrentlyInCreation.get();
 return (curVal != null &&
 (curVal.equals(beanName) || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName))));
}

從流程上就可以查看，無論是構(gòu)造注入還是設(shè)值注入，第二次進(jìn)入同一個(gè)Bean的getBean方法是，一定會(huì)在校驗(yàn)部分拋出異常，因此不能完成注入，也就不能實(shí)現(xiàn)循環(huán)引用。

總結(jié)：Spring在InstantiateBean時(shí)執(zhí)行構(gòu)造器方法，構(gòu)造出實(shí)例，如果是單例的話，會(huì)將它放入一個(gè)singletonBeanFactory的緩存中，再進(jìn)行populateBean方法，設(shè)置屬性。通過一個(gè)singletonBeanFactory的緩存解決了循環(huán)依賴的問題。

再解決一個(gè)問題

現(xiàn)在大家已經(jīng)對(duì)Spring整個(gè)流程有點(diǎn)感覺了，我們?cè)賮斫鉀Q一個(gè)簡(jiǎn)單的常見的問題：

考慮一下如下的singleton代碼：

 @Service
 public class SingletonBean{

  @Autowired 
  private PrototypeBean prototypeBean;

  public void doSomething(){
   System.out.println(prototypeBean.toString());  }

 }

  @Component 
  @Scope(value="prototype")
  public class PrototypeBean{
  }

一個(gè)Singleton的Bean中Autowired了一個(gè)prototype的Bean，那么問題來了，每次調(diào)用SingletonBean.doSomething()時(shí)打印的對(duì)象是不是同一個(gè)呢？

有了之前的知識(shí)儲(chǔ)備，我們簡(jiǎn)單分析一下：因?yàn)镾ingleton是單例的，所以在項(xiàng)目啟動(dòng)時(shí)就會(huì)初始化，prototypeBean本質(zhì)上只是它的一個(gè)Property，那么ApplicationContex中只存在一個(gè)SingletonBean和一個(gè)初始化SingletonBean時(shí)創(chuàng)建的一個(gè)prototype類型的PrototypeBean。

那么每次調(diào)用SingletonBean.doSomething()時(shí)，Spring會(huì)從ApplicationContex中獲取SingletonBean，每次獲取的SingletonBean是同一個(gè)，所以即便PrototypeBean是prototype的，但PrototypeBean仍然是同一個(gè)。每次打印出來的內(nèi)存地址肯定是同一個(gè)。

 那這個(gè)問題如何解決呢？

解決辦法也很簡(jiǎn)單，這種情況我們不能通過注入的方式注入一個(gè)prototypeBean，只能在程序運(yùn)行時(shí)手動(dòng)調(diào)用getBean("prototypeBean")方法，我寫了一個(gè)簡(jiǎn)單的工具類：

@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(); 
 }
 }

對(duì)于這個(gè)ApplicationContextAware接口：

在某些特殊的情況下，Bean需要實(shí)現(xiàn)某個(gè)功能，但該功能必須借助于Spring容器才能實(shí)現(xiàn)，此時(shí)就必須讓該Bean先獲取Spring容器，然后借助于Spring容器實(shí)現(xiàn)該功能。為了讓Bean獲取它所在的Spring容器，可以讓該Bean實(shí)現(xiàn)ApplicationContextAware接口。

感興趣的讀者自己可以試試。

總結(jié)：

回到循環(huán)依賴的問題，有的人可能會(huì)問singletonBeanFactory只是一個(gè)三級(jí)緩存，那么一級(jí)緩存和二級(jí)緩存有什么用呢？

其實(shí)大家只要理解整個(gè)流程就可以切入了，Spring在初始化Singleton的時(shí)候大致可以分幾步，初始化——設(shè)值——銷毀，循環(huán)依賴的場(chǎng)景下只有A——B——A這樣的順序，但在并發(fā)的場(chǎng)景下，每一步在執(zhí)行時(shí)，都有可能調(diào)用getBean方法，而單例的Bean需要保證只有一個(gè)instance，那么Spring就是通過這些個(gè)緩存外加對(duì)象鎖去解決這類問題，同時(shí)也可以省去不必要的重復(fù)操作。Spring的鎖的粒度選取也是很吊的，這里暫時(shí)不深入研究了。

解決此類問題的關(guān)鍵是要對(duì)SpringIOC和DI的整個(gè)流程做到心中有數(shù)，看源碼一般情況下不要求每一行代碼都了解透徹，但是對(duì)于整個(gè)的流程和每個(gè)流程中在做什么事需要了然，這樣實(shí)際遇到問題時(shí)才可以很快的切入進(jìn)行分析解決。

希望這篇文章可以幫助你對(duì)Spring的IOC和DI的流程有一個(gè)更深刻的認(rèn)識(shí)！

到此這篇關(guān)于理解SpringIOC、DI的文章就介紹到這了,更多相關(guān)理解SpringIOC、DI內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論