1. 簡介

為了寫 Spring IOC 容器源碼分析系列的文章，我特地寫了一篇 Spring IOC 容器的導讀文章。在導讀一文中，我介紹了 Spring 的一些特性以及閱讀 Spring 源碼的一些建議。在做完必要的準備工作后，從本文開始，正式開始進入源碼分析的階段。

在本篇文章中，我將會詳細分析BeanFactory的getBean(String)方法實現細節，getBean(String)?及所調用的方法總體來說實現上較為復雜，代碼長度比較長。作為源碼分析文章，本文的文章長度也會比較長，希望大家耐心讀下去。

好了，其他的不多說了，進入主題環節吧。

?2. 源碼分析

簡單說一下本章的內容安排吧，在本章的開始，也就是2.1節，我將會分析getBean(String)方法整體的實現邏輯。但不會分析它所調用的方法，這些方法將會在后續幾節中依次進行分析。那接下來，我們就先來看看 getBean(String) 方法是如何實現的吧。

?2.1 俯瞰 getBean(String) 源碼

在本小節，我們先從戰略上俯瞰 getBean(String) 方法的實現源碼。代碼如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213

public Object getBean(String name) throws BeansException {// getBean 是一個空殼方法，所有的邏輯都封裝在 doGetBean 方法中return doGetBean(name, null, null, false); }protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)throws BeansException {/** 通過 name 獲取 beanName。這里不使用 name 直接作為 beanName 有兩點原因：* 1. name 可能會以 & 字符開頭，表明調用者想獲取 FactoryBean 本身，而非 FactoryBean * 實現類所創建的 bean。在 BeanFactory 中，FactoryBean 的實現類和其他的 bean 存儲* 方式是一致的，即 <beanName, bean>，beanName 中是沒有 & 這個字符的。所以我們需要* 將 name 的首字符 & 移除，這樣才能從緩存里取到 FactoryBean 實例。* 2. 若 name 是一個別名，則應將別名轉換為具體的實例名，也就是 beanName。*/final String beanName = transformedBeanName(name);Object bean;/** 從緩存中獲取單例 bean。Spring 是使用 Map 作為 beanName 和 bean 實例的緩存的，所以這* 里暫時可以把 getSingleton(beanName) 等價于 beanMap.get(beanName)。當然，實際的* 邏輯并非如此簡單，后面再細說。*/Object sharedInstance = getSingleton(beanName);/** 如果 sharedInstance = null，則說明緩存里沒有對應的實例，表明這個實例還沒創建。* BeanFactory 并不會在一開始就將所有的單例 bean 實例化好，而是在調用 getBean 獲取 * bean 時再實例化，也就是懶加載。* getBean 方法有很多重載，比如 getBean(String name, Object... args)，我們在首次獲取* 某個 bean 時，可以傳入用于初始化 bean 的參數數組（args），BeanFactory 會根據這些參數* 去匹配合適的構造方法構造 bean 實例。當然，如果單例 bean 早已創建好，這里的 args 就沒有* 用了，BeanFactory 不會多次實例化單例 bean。*/if (sharedInstance != null && args == null) {if (logger.isDebugEnabled()) {if (isSingletonCurrentlyInCreation(beanName)) {logger.debug("Returning eagerly cached instance of singleton bean '" + beanName +"' that is not fully initialized yet - a consequence of a circular reference");}else {logger.debug("Returning cached instance of singleton bean '" + beanName + "'");}}/** 如果 sharedInstance 是普通的單例 bean，下面的方法會直接返回。但如果 * sharedInstance 是 FactoryBean 類型的，則需調用 getObject 工廠方法獲取真正的 * bean 實例。如果用戶想獲取 FactoryBean 本身，這里也不會做特別的處理，直接返回* 即可。畢竟 FactoryBean 的實現類本身也是一種 bean，只不過具有一點特殊的功能而已。*/bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);}/** 如果上面的條件不滿足，則表明 sharedInstance 可能為空，此時 beanName 對應的 bean * 實例可能還未創建。這里還存在另一種可能，如果當前容器有父容器，beanName 對應的 bean 實例* 可能是在父容器中被創建了，所以在創建實例前，需要先去父容器里檢查一下。*/else {// BeanFactory 不緩存 Prototype 類型的 bean，無法處理該類型 bean 的循環依賴問題if (isPrototypeCurrentlyInCreation(beanName)) {throw new BeanCurrentlyInCreationException(beanName);}// 如果 sharedInstance = null，則到父容器中查找 bean 實例BeanFactory parentBeanFactory = getParentBeanFactory();if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {// 獲取 name 對應的 beanName，如果 name 是以 & 字符開頭，則返回 & + beanNameString nameToLookup = originalBeanName(name);// 根據 args 是否為空，以決定調用父容器哪個方法獲取 beanif (args != null) {return (T) parentBeanFactory.getBean(nameToLookup, args);} else {return parentBeanFactory.getBean(nameToLookup, requiredType);}}if (!typeCheckOnly) {markBeanAsCreated(beanName);}try {// 合并父 BeanDefinition 與子 BeanDefinition，后面會單獨分析這個方法final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);checkMergedBeanDefinition(mbd, beanName, args);// 檢查是否有 dependsOn 依賴，如果有則先初始化所依賴的 beanString[] dependsOn = mbd.getDependsOn();if (dependsOn != null) {for (String dep : dependsOn) {/** 檢測是否存在 depends-on 循環依賴，若存在則拋異常。比如 A 依賴 B，* B 又依賴 A，他們的配置如下：* <bean id="beanA" class="BeanA" depends-on="beanB">* <bean id="beanB" class="BeanB" depends-on="beanA">* * beanA 要求 beanB 在其之前被創建，但 beanB 又要求 beanA 先于它* 創建。這個時候形成了循環，對于 depends-on 循環，Spring 會直接* 拋出異常*/if (isDependent(beanName, dep)) {throw new BeanCreationException(mbd.getResourceDescription(), beanName,"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");}// 注冊依賴記錄registerDependentBean(dep, beanName);try {// 加載 depends-on 依賴getBean(dep);} catch (NoSuchBeanDefinitionException ex) {throw new BeanCreationException(mbd.getResourceDescription(), beanName,"'" + beanName + "' depends on missing bean '" + dep + "'", ex);}}}// 創建 bean 實例if (mbd.isSingleton()) {/** 這里并沒有直接調用 createBean 方法創建 bean 實例，而是通過 * getSingleton(String, ObjectFactory) 方法獲取 bean 實例。* getSingleton(String, ObjectFactory) 方法會在內部調用 * ObjectFactory 的 getObject() 方法創建 bean，并會在創建完成后，* 將 bean 放入緩存中。關于 getSingleton 方法的分析，本文先不展開，我會在* 后面的文章中進行分析*/sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {@Overridepublic Object getObject() throws BeansException {try {// 創建 bean 實例return createBean(beanName, mbd, args);}catch (BeansException ex) {destroySingleton(beanName);throw ex;}}});// 如果 bean 是 FactoryBean 類型，則調用工廠方法獲取真正的 bean 實例。否則直接返回 bean 實例bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);}// 創建 prototype 類型的 bean 實例else if (mbd.isPrototype()) {Object prototypeInstance = null;try {beforePrototypeCreation(beanName);prototypeInstance = createBean(beanName, mbd, args);}finally {afterPrototypeCreation(beanName);}bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);}// 創建其他類型的 bean 實例else {String scopeName = mbd.getScope();final Scope scope = this.scopes.get(scopeName);if (scope == null) {throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");}try {Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {@Overridepublic Object getObject() throws BeansException {beforePrototypeCreation(beanName);try {return createBean(beanName, mbd, args);}finally {afterPrototypeCreation(beanName);}}});bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);}catch (IllegalStateException ex) {throw new BeanCreationException(beanName,"Scope '" + scopeName + "' is not active for the current thread; consider " +"defining a scoped proxy for this bean if you intend to refer to it from a singleton",ex);}}}catch (BeansException ex) {cleanupAfterBeanCreationFailure(beanName);throw ex;}}// 如果需要進行類型轉換，則在此處進行轉換。類型轉換這一塊我沒細看，就不多說了。if (requiredType != null && bean != null && !requiredType.isInstance(bean)) {try {return getTypeConverter().convertIfNecessary(bean, requiredType);}catch (TypeMismatchException ex) {if (logger.isDebugEnabled()) {logger.debug("Failed to convert bean '" + name + "' to required type '" +ClassUtils.getQualifiedName(requiredType) + "'", ex);}throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());}}// 返回 beanreturn (T) bean; }

以上就是getBean(String)和doGetBean(String, Class, Object[], boolean)兩個方法的分析。代碼很長，需要一點耐心閱讀。為了凸顯方法的主邏輯，大家可以對代碼進行一定的刪減，刪除一些日志和異常代碼，也可以刪除一些不是很重要的邏輯。另外由于 doGetBean 方法調用了其他的很多方法，在看代碼的話，經常會忘掉 doGetBean 所調用的方法是怎么實現的。比如 getSingleton 方法出現了兩次，但兩個方法并不同，在看第二個的 getSingleton 方法時，可能會忘掉第一個 getSingleton 是怎么實現的。另外，如果你想對比兩個重載方法的異同，在 IDEA 里跳來跳去也是很不方便。為此，我使用了 sublime 進行分屏，左屏是刪減后的 doGetBean 方法，右屏是 doGetBean 調用的一些方法，這樣看起來會方便一點。忘了某個方法的實現邏輯后，可以到右屏查看，也可進行對比。分屏效果如下：

這里我為了演示，刪除了不少東西。大家可以按需進行刪減，并配上注釋，輔助理解。

看完了源碼，下面我來簡單總結一下 doGetBean 的執行流程。如下：

轉換 beanName

從緩存中獲取實例

如果實例不為空，且 args = null。調用 getObjectForBeanInstance 方法，并按 name 規則返回相應的 bean 實例

若上面的條件不成立，則到父容器中查找 beanName 對有的 bean 實例，存在則直接返回

若父容器中不存在，則進行下一步操作 – 合并 BeanDefinition

處理 depends-on 依賴

創建并緩存 bean

調用 getObjectForBeanInstance 方法，并按 name 規則返回相應的 bean 實例

按需轉換 bean 類型，并返回轉換后的 bean 實例。

以上步驟對應的流程圖如下：

?2.2 beanName 轉換

在獲取 bean 實例之前，Spring 第一件要做的事情是對參數 name 進行轉換。轉換的目的主要是為了解決兩個問題，第一個是處理以字符 & 開頭的 name，防止 BeanFactory 無法找到與 name 對應的 bean 實例。第二個是處理別名問題，Spring 不會存儲 <別名, bean 實例> 這種映射，僅會存儲 <beanName, bean>。所以，同樣是為了避免 BeanFactory 找不到 name 對應的 bean 的實例，對于別名也要進行轉換。接下來，我們來簡單分析一下轉換的過程，如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

protected String transformedBeanName(String name) {// 這里調用了兩個方法：BeanFactoryUtils.transformedBeanName(name) 和 canonicalNamereturn canonicalName(BeanFactoryUtils.transformedBeanName(name)); }/** 該方法用于處理 & 字符 */ public static String transformedBeanName(String name) {Assert.notNull(name, "'name' must not be null");String beanName = name;// 循環處理 & 字符。比如 name = "&&&&&helloService"，最終會被轉成 helloServicewhile (beanName.startsWith(BeanFactory.FACTORY_BEAN_PREFIX)) {beanName = beanName.substring(BeanFactory.FACTORY_BEAN_PREFIX.length());}return beanName; }/** 該方法用于轉換別名 */ public String canonicalName(String name) {String canonicalName = name;String resolvedName;/** 這里使用 while 循環進行處理，原因是：可能會存在多重別名的問題，即別名指向別名。比如下面* 的配置：* <bean id="hello" class="service.Hello"/>* <alias name="hello" alias="aliasA"/>* <alias name="aliasA" alias="aliasB"/>** 上面的別名指向關系為 aliasB -> aliasA -> hello，對于上面的別名配置，aliasMap 中數據* 視圖為：aliasMap = [<aliasB, aliasA>, <aliasA, hello>]。通過下面的循環解析別名* aliasB 最終指向的 beanName*/do {resolvedName = this.aliasMap.get(canonicalName);if (resolvedName != null) {canonicalName = resolvedName;}}while (resolvedName != null);return canonicalName; }

?2.3 從緩存中獲取 bean 實例

對于單例 bean，Spring 容器只會實例化一次。后續再次獲取時，只需直接從緩存里獲取即可，無需且不能再次實例化（否則單例就沒意義了）。從緩存中取 bean 實例的方法是getSingleton(String)，下面我們就來看看這個方法實現方式吧。如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

public Object getSingleton(String beanName) {return getSingleton(beanName, true); }/*** 這里解釋一下 allowEarlyReference 參數，allowEarlyReference 表示是否允許其他 bean 引用* 正在創建中的 bean，用于處理循環引用的問題。關于循環引用，這里先簡單介紹一下。先看下面的配置：** <bean id="hello" class="xyz.coolblog.service.Hello">* <property name="world" ref="world"/>* </bean>* <bean id="world" class="xyz.coolblog.service.World">* <property name="hello" ref="hello"/>* </bean>* * 如上所示，hello 依賴 world，world 又依賴于 hello，他們之間形成了循環依賴。Spring 在構建 * hello 這個 bean 時，會檢測到它依賴于 world，于是先去實例化 world。實例化 world 時，發現 * world 依賴 hello。這個時候容器又要去初始化 hello。由于 hello 已經在初始化進程中了，為了讓 * world 能完成初始化，這里先讓 world 引用正在初始化中的 hello。world 初始化完成后，hello * 就可引用到 world 實例，這樣 hello 也就能完成初始了。關于循環依賴，我后面會專門寫一篇文章講* 解，這里先說這么多。*/ protected Object getSingleton(String beanName, boolean allowEarlyReference) {// 從 singletonObjects 獲取實例，singletonObjects 中緩存的實例都是完全實例化好的 bean，可以直接使用Object singletonObject = this.singletonObjects.get(beanName);/** 如果 singletonObject = null，表明還沒創建，或者還沒完全創建好。* 這里判斷 beanName 對應的 bean 是否正在創建中*/if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {synchronized (this.singletonObjects) {// 從 earlySingletonObjects 中獲取提前曝光的 bean，用于處理循環引用singletonObject = this.earlySingletonObjects.get(beanName);// 如果如果 singletonObject = null，且允許提前曝光 bean 實例，則從相應的 ObjectFactory 獲取一個原始的（raw）bean（尚未填充屬性）if (singletonObject == null && allowEarlyReference) {// 獲取相應的工廠類ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);if (singletonFactory != null) {// 提前曝光 bean 實例，用于解決循環依賴singletonObject = singletonFactory.getObject();// 放入緩存中，如果還有其他 bean 依賴當前 bean，其他 bean 可以直接從 earlySingletonObjects 取結果this.earlySingletonObjects.put(beanName, singletonObject);this.singletonFactories.remove(beanName);}}}}return (singletonObject != NULL_OBJECT ? singletonObject : null); }

上面的代碼雖然不長，但是涉及到了好幾個緩存集合。如果不知道這些緩存的用途是什么，上面源碼可能就很難弄懂了。這幾個緩存集合用的很頻繁，在后面的代碼中還會出現，所以這里介紹一下。如下：

緩存用途

singletonObjects	用于存放完全初始化好的 bean，從該緩存中取出的 bean 可以直接使用
earlySingletonObjects	用于存放還在初始化中的 bean，用于解決循環依賴
singletonFactories	用于存放 bean 工廠。bean 工廠所產生的 bean 是還未完成初始化的 bean。如代碼所示，bean 工廠所生成的對象最終會被緩存到?earlySingletonObjects 中

關于 getSingleton 先說到這里，getSingleton 源碼并不多。但涉及到了循環依賴的相關邏輯，如果對這一塊不理解可能不知道代碼所云。等后面分析循環依賴的時候，我會再次分析這個方法，所以暫時不理解也沒關系。

?2.4 合并父 BeanDefinition 與子 BeanDefinition

Spring 支持配置繼承，在標簽中可以使用parent屬性配置父類 bean。這樣子類 bean 可以繼承父類 bean 的配置信息，同時也可覆蓋父類中的配置。比如下面的配置：

1 2 3 4 5 6 7

<bean id="hello" class="xyz.coolblog.innerbean.Hello"><property name="content" value="hello"/> </bean><bean id="hello-child" parent="hello"><property name="content" value="I`m hello-child"/> </bean>

如上所示，hello-child 配置繼承自 hello。hello-child 未配置 class 屬性，這里我們讓它繼承父配置中的 class 屬性。然后我們寫點代碼測試一下，如下：

1 2 3 4

String configLocation = "application-parent-bean.xml"; ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation); System.out.println("hello -> " + applicationContext.getBean("hello")); System.out.println("hello-child -> " + applicationContext.getBean("hello-child"));

測試結果如下：

由測試結果可以看出，hello-child 在未配置 class 的屬性下也實例化成功了，表明它成功繼承了父配置的 class 屬性。

看完代碼演示，接下來我們來看看源碼吧。如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

protected RootBeanDefinition getMergedLocalBeanDefinition(String beanName) throws BeansException {// 檢查緩存中是否存在“已合并的 BeanDefinition”，若有直接返回即可RootBeanDefinition mbd = this.mergedBeanDefinitions.get(beanName);if (mbd != null) {return mbd;}// 調用重載方法return getMergedBeanDefinition(beanName, getBeanDefinition(beanName)); }protected RootBeanDefinition getMergedBeanDefinition(String beanName, BeanDefinition bd)throws BeanDefinitionStoreException {// 繼續調用重載方法return getMergedBeanDefinition(beanName, bd, null); }protected RootBeanDefinition getMergedBeanDefinition(String beanName, BeanDefinition bd, BeanDefinition containingBd)throws BeanDefinitionStoreException {synchronized (this.mergedBeanDefinitions) {RootBeanDefinition mbd = null;// 我暫時還沒去詳細了解 containingBd 的用途，盡管從方法的注釋上可以知道 containingBd 的大致用途，但沒經過詳細分析，就不多說了。見諒if (containingBd == null) {mbd = this.mergedBeanDefinitions.get(beanName);}if (mbd == null) {// bd.getParentName() == null，表明無父配置，這時直接將當前的 BeanDefinition 升級為 RootBeanDefinitionif (bd.getParentName() == null) {if (bd instanceof RootBeanDefinition) {mbd = ((RootBeanDefinition) bd).cloneBeanDefinition();}else {mbd = new RootBeanDefinition(bd);}}else {BeanDefinition pbd;try {String parentBeanName = transformedBeanName(bd.getParentName());/** 判斷父類 beanName 與子類 beanName 名稱是否相同。若相同，則父類 bean 一定* 在父容器中。原因也很簡單，容器底層是用 Map 緩存 <beanName, bean> 鍵值對* 的。同一個容器下，使用同一個 beanName 映射兩個 bean 實例顯然是不合適的。* 有的朋友可能會覺得可以這樣存儲：<beanName, [bean1, bean2]> ，似乎解決了* 一對多的問題。但是也有問題，調用 getName(beanName) 時，到底返回哪個 bean * 實例好呢？*/if (!beanName.equals(parentBeanName)) {/** 這里再次調用 getMergedBeanDefinition，只不過參數值變為了 * parentBeanName，用于合并父 BeanDefinition 和爺爺輩的 * BeanDefinition。如果爺爺輩的 BeanDefinition 仍有父 * BeanDefinition，則繼續合并*/pbd = getMergedBeanDefinition(parentBeanName);}else {// 獲取父容器，并判斷，父容器的類型，若不是 ConfigurableBeanFactory 則判拋出異常BeanFactory parent = getParentBeanFactory();if (parent instanceof ConfigurableBeanFactory) {pbd = ((ConfigurableBeanFactory) parent).getMergedBeanDefinition(parentBeanName);}else {throw new NoSuchBeanDefinitionException(parentBeanName,"Parent name '" + parentBeanName + "' is equal to bean name '" + beanName +"': cannot be resolved without an AbstractBeanFactory parent");}}}catch (NoSuchBeanDefinitionException ex) {throw new BeanDefinitionStoreException(bd.getResourceDescription(), beanName,"Could not resolve parent bean definition '" + bd.getParentName() + "'", ex);}// 以父 BeanDefinition 的配置信息為藍本創建 RootBeanDefinition，也就是“已合并的 BeanDefinition”mbd = new RootBeanDefinition(pbd);// 用子 BeanDefinition 中的屬性覆蓋父 BeanDefinition 中的屬性mbd.overrideFrom(bd);}// 如果用戶未配置 scope 屬性，則默認將該屬性配置為 singletonif (!StringUtils.hasLength(mbd.getScope())) {mbd.setScope(RootBeanDefinition.SCOPE_SINGLETON);}if (containingBd != null && !containingBd.isSingleton() && mbd.isSingleton()) {mbd.setScope(containingBd.getScope());}if (containingBd == null && isCacheBeanMetadata()) {// 緩存合并后的 BeanDefinitionthis.mergedBeanDefinitions.put(beanName, mbd);}}return mbd;} }

上面的源碼雖然有點長，但好在邏輯不是很復雜。加上我在源碼里進行了比較詳細的注解，我想耐心看一下還是可以看懂的，這里就不多說了。

?2.5 從 FactoryBean 中獲取 bean 實例

在經過前面這么多的步驟處理后，到這里差不多就接近 doGetBean 方法的尾聲了。在本節中，我們來看看從 FactoryBean 實現類中獲取 bean 實例的過程。關于 FactoryBean 的用法，我在導讀那篇文章中已經演示過，這里就不再次說明了。那接下來，我們直入主題吧，相關的源碼如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145

protected Object getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd) {// 如果 name 以 & 開頭，但 beanInstance 卻不是 FactoryBean，則認為有問題。if (BeanFactoryUtils.isFactoryDereference(name) && !(beanInstance instanceof FactoryBean)) {throw new BeanIsNotAFactoryException(transformedBeanName(name), beanInstance.getClass());}/* * 如果上面的判斷通過了，表明 beanInstance 可能是一個普通的 bean，也可能是一個 * FactoryBean。如果是一個普通的 bean，這里直接返回 beanInstance 即可。如果是 * FactoryBean，則要調用工廠方法生成一個 bean 實例。*/if (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils.isFactoryDereference(name)) {return beanInstance;}Object object = null;if (mbd == null) {/** 如果 mbd 為空，則從緩存中加載 bean。FactoryBean 生成的單例 bean 會被緩存* 在 factoryBeanObjectCache 集合中，不用每次都創建*/object = getCachedObjectForFactoryBean(beanName);}if (object == null) {// 經過前面的判斷，到這里可以保證 beanInstance 是 FactoryBean 類型的，所以可以進行類型轉換FactoryBean<?> factory = (FactoryBean<?>) beanInstance;// 如果 mbd 為空，則判斷是否存在名字為 beanName 的 BeanDefinitionif (mbd == null && containsBeanDefinition(beanName)) {// 合并 BeanDefinitionmbd = getMergedLocalBeanDefinition(beanName);}// synthetic 字面意思是"合成的"。通過全局查找，我發現在 AOP 相關的類中會將該屬性設為 true。// 所以我覺得該字段可能表示某個 bean 是不是被 AOP 增強過，也就是 AOP 基于原始類合成了一個新的代理類。// 不過目前只是猜測，沒有深究。如果有朋友知道這個字段的具體意義，還望不吝賜教boolean synthetic = (mbd != null && mbd.isSynthetic());// 調用 getObjectFromFactoryBean 方法繼續獲取實例object = getObjectFromFactoryBean(factory, beanName, !synthetic);}return object; }protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {/** FactoryBean 也有單例和非單例之分，針對不同類型的 FactoryBean，這里有兩種處理方式：* 1. 單例 FactoryBean 生成的 bean 實例也認為是單例類型。需放入緩存中，供后續重復使用* 2. 非單例 FactoryBean 生成的 bean 實例則不會被放入緩存中，每次都會創建新的實例*/if (factory.isSingleton() && containsSingleton(beanName)) {synchronized (getSingletonMutex()) {// 從緩存中取 bean 實例，避免多次創建 bean 實例Object object = this.factoryBeanObjectCache.get(beanName);if (object == null) {// 使用工廠對象中創建實例object = doGetObjectFromFactoryBean(factory, beanName);Object alreadyThere = this.factoryBeanObjectCache.get(beanName);if (alreadyThere != null) {object = alreadyThere;}else {// shouldPostProcess 等價于上一個方法中的 !synthetic，用于表示是否應用后置處理if (object != null && shouldPostProcess) {if (isSingletonCurrentlyInCreation(beanName)) {return object;}beforeSingletonCreation(beanName);try {// 應用后置處理object = postProcessObjectFromFactoryBean(object, beanName);}catch (Throwable ex) {throw new BeanCreationException(beanName,"Post-processing of FactoryBean's singleton object failed", ex);}finally {afterSingletonCreation(beanName);}}// 這里的 beanName 對應于 FactoryBean 的實現類， FactoryBean 的實現類也會被實例化，并被緩存在 singletonObjects 中if (containsSingleton(beanName)) {// FactoryBean 所創建的實例會被緩存在 factoryBeanObjectCache 中，供后續調用使用this.factoryBeanObjectCache.put(beanName, (object != null ? object : NULL_OBJECT));}}}return (object != NULL_OBJECT ? object : null);}}// 獲取非單例實例else {// 從工廠類中獲取實例Object object = doGetObjectFromFactoryBean(factory, beanName);if (object != null && shouldPostProcess) {try {// 應用后置處理object = postProcessObjectFromFactoryBean(object, beanName);}catch (Throwable ex) {throw new BeanCreationException(beanName, "Post-processing of FactoryBean's object failed", ex);}}return object;} }private Object doGetObjectFromFactoryBean(final FactoryBean<?> factory, final String beanName)throws BeanCreationException {Object object;try {// if 分支的邏輯是 Java 安全方面的代碼，可以忽略，直接看 else 分支的代碼if (System.getSecurityManager() != null) {AccessControlContext acc = getAccessControlContext();try {object = AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {@Overridepublic Object run() throws Exception {return factory.getObject();}}, acc);}catch (PrivilegedActionException pae) {throw pae.getException();}}else {// 調用工廠方法生成 bean 實例object = factory.getObject();}}catch (FactoryBeanNotInitializedException ex) {throw new BeanCurrentlyInCreationException(beanName, ex.toString());}catch (Throwable ex) {throw new BeanCreationException(beanName, "FactoryBean threw exception on object creation", ex);}if (object == null && isSingletonCurrentlyInCreation(beanName)) {throw new BeanCurrentlyInCreationException(beanName, "FactoryBean which is currently in creation returned null from getObject");}return object; }

上面的源碼分析完了，代碼雖長，但整體邏輯不是很復雜，這里簡單總結一下。getObjectForBeanInstance 及它所調用的方法主要做了如下幾件事情：

檢測參數 beanInstance 的類型，如果是非 FactoryBean 類型的 bean，直接返回

檢測 FactoryBean 實現類是否單例類型，針對單例和非單例類型進行不同處理

對于單例 FactoryBean，先從緩存里獲取 FactoryBean 生成的實例

若緩存未命中，則調用 FactoryBean.getObject() 方法生成實例，并放入緩存中

對于非單例的 FactoryBean，每次直接創建新的實例即可，無需緩存

如果 shouldPostProcess = true，不管是單例還是非單例 FactoryBean 生成的實例，都要進行后置處理

本節涉及到了 FactoryBean 和后置處理兩個特性，關于這兩個特性，不熟悉的同學可以參考我在導讀一文中的說明，這里就不過多解釋了。

?3. 總結

到這里，Spring IOC 容器獲取 bean 實例這一塊的內容就分析完了。如果大家是初次閱讀 Spring 的源碼，看不懂也沒關系。多看幾遍，認證思考一下，相信是能看得懂的。另外由于本人水平有限，以上的源碼分析有誤的地方，還望多指教，謝了。

好了，本文先到這里。又到周五了，祝大家在即將到來的周末玩的開心。over.

?參考

• 《Spring 源碼深度解析》- 郝佳著

?附錄：Spring 源碼分析文章列表

?Ⅰ. IOC

更新時間標題

2018-05-30	Spring IOC 容器源碼分析系列文章導讀
2018-06-01	Spring IOC 容器源碼分析 - 獲取單例 bean
2018-06-04	Spring IOC 容器源碼分析 - 創建單例 bean 的過程
2018-06-06	Spring IOC 容器源碼分析 - 創建原始 bean 對象
2018-06-08	Spring IOC 容器源碼分析 - 循環依賴的解決辦法
2018-06-11	Spring IOC 容器源碼分析 - 填充屬性到 bean 原始對象
2018-06-11	Spring IOC 容器源碼分析 - 余下的初始化工作

?Ⅱ. AOP

更新時間標題

2018-06-17	Spring AOP 源碼分析系列文章導讀
2018-06-20	Spring AOP 源碼分析 - 篩選合適的通知器
2018-06-20	Spring AOP 源碼分析 - 創建代理對象
2018-06-22	Spring AOP 源碼分析 - 攔截器鏈的執行過程

?Ⅲ. MVC

更新時間標題

2018-06-29	Spring MVC 原理探秘 - 一個請求的旅行過程
2018-06-30	Spring MVC 原理探秘 - 容器的創建過程

• 本文鏈接：?https://www.tianxiaobo.com/2018/06/01/Spring-IOC-容器源碼分析-獲取單例-bean/

from:http://www.tianxiaobo.com/2018/06/01/Spring-IOC-%E5%AE%B9%E5%99%A8%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-%E8%8E%B7%E5%8F%96%E5%8D%95%E4%BE%8B-bean/?

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Spring IOC 容器源码分析 - 获取单例 bean的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。