Spring IOC 容器源碼分析
Spring 最重要的概念是 IOC 和 AOP，本篇文章其實就是要帶領你們來分析下 Spring 的 IOC 容器。既然你們平時都要用到 Spring，怎麼能夠很差好了解 Spring 呢？閱讀本文並不能讓你成爲 Spring 專家，不過必定有助於你們理解 Spring 的不少概念，幫助你們排查應用中和 Spring 相關的一些問題。前端
本文采用的源碼版本是 4.3.11.RELEASE，算是 5.0.x 前比較新的版本了。爲了下降難度，本文所說的全部的內容都是基於 xml 的配置的方式，實際使用已經不多人這麼作了，至少不是純 xml 配置，不過從理解源碼的角度來看用這種方式來講無疑是最合適的。java
閱讀建議：讀者至少須要知道怎麼配置 Spring，瞭解 Spring 中的各類概念，少部份內容我還假設讀者使用過 SpringMVC。本文要說的 IOC 整體來講有兩處地方最重要，一個是建立 Bean 容器，一個是初始化 Bean，若是讀者以爲一次性看完本文壓力有點大，那麼能夠按這個思路分兩次消化。讀者不必定對 Spring 容器的源碼感興趣，也許附錄部分介紹的知識對讀者有些許做用。node
但願經過本文可讓讀者不害怕閱讀 Spring 源碼，也但願你們能反饋表述錯誤或不合理的地方。web
引言
先看下最基本的啓動 Spring 容器的例子：spring
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationfile.xml");
}
複製代碼
以上代碼就能夠利用配置文件來啓動一個 Spring 容器了，請使用 maven 的小夥伴直接在 dependencies 中加上如下依賴便可，我的比較反對那些不知道要添加什麼依賴，而後把 Spring 的全部相關的東西都加進來的方式。sql
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.3.11.RELEASE</version>
</dependency>
複製代碼
spring-context 會自動將 spring-core、spring-beans、spring-aop、spring-expression 這幾個基礎 jar 包帶進來。數據庫
多說一句，不少開發者入門就直接接觸的 SpringMVC，對 Spring 其實不是很瞭解，Spring 是漸進式的工具，並不具備很強的侵入性，它的模塊也劃分得很合理，即便你的應用不是 web 應用，或者以前徹底沒有使用到 Spring，而你就想用 Spring 的依賴注入這個功能，其實徹底是能夠的，它的引入不會對其餘的組件產生衝突。express
廢話說完，咱們繼續。ApplicationContext context = new ClassPathXmlApplicationContext(...) 其實很好理解，從名字上就能夠猜出一二，就是在 ClassPath 中尋找 xml 配置文件，根據 xml 文件內容來構建 ApplicationContext。固然，除了 ClassPathXmlApplicationContext 之外，咱們也還有其餘構建 ApplicationContext 的方案可供選擇，咱們先來看看大致的繼承結構是怎麼樣的：後端
讀者能夠大體看一下類名，源碼分析的時候不至於找不着看哪一個類，由於 Spring 爲了適應各類使用場景，提供的各個接口均可能有不少的實現類。對於咱們來講，就是揪着一個完整的分支看完。設計模式
固然，讀本文的時候讀者也沒必要太擔憂，每一個代碼塊分析的時候，我都會告訴讀者咱們在說哪一個類第幾行。
咱們能夠看到，ClassPathXmlApplicationContext 兜兜轉轉了很久纔到 ApplicationContext 接口，一樣的，咱們也可使用綠顏色的 FileSystemXmlApplicationContext 和 AnnotationConfigApplicationContext 這兩個類。
FileSystemXmlApplicationContext 的構造函數須要一個 xml 配置文件在系統中的路徑，其餘和 ClassPathXmlApplicationContext 基本上同樣。
AnnotationConfigApplicationContext 是基於註解來使用的，它不須要配置文件，採用 java 配置類和各類註解來配置，是比較簡單的方式，也是大勢所趨吧。
不過本文旨在幫助你們理解整個構建流程，因此決定使用 ClassPathXmlApplicationContext 進行分析。
咱們先來一個簡單的例子來看看怎麼實例化 ApplicationContext。
首先，定義一個接口：
public interface MessageService {
String getMessage();
}
複製代碼
定義接口實現類：
public class MessageServiceImpl implements MessageService {
public String getMessage() {
return "hello world";
}
}
複製代碼
接下來，咱們在 resources 目錄新建一個配置文件，文件名隨意，一般叫 application.xml 或 application-xxx.xml 就能夠了：
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">
<bean id="messageService" class="com.javadoop.example.MessageServiceImpl"/>
</beans>
複製代碼
這樣，咱們就能夠跑起來了：
public class App {
public static void main(String[] args) {
// 用咱們的配置文件來啓動一個 ApplicationContext
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");
System.out.println("context 啓動成功");
// 從 context 中取出咱們的 Bean，而不是用 new MessageServiceImpl() 這種方式
MessageService messageService = context.getBean(MessageService.class);
// 這句將輸出: hello world
System.out.println(messageService.getMessage());
}
}
複製代碼
以上例子很簡單，不過也夠引出本文的主題了，就是怎麼樣經過配置文件來啓動 Spring 的 ApplicationContext？也就是咱們今天要分析的 IOC 的核心了。ApplicationContext 啓動過程當中，會負責建立實例 Bean，往各個 Bean 中注入依賴等。
BeanFactory 簡介
BeanFactory，從名字上也很好理解，生產 bean 的工廠，它負責生產和管理各個 bean 實例。
初學者可別覺得我以前說那麼多和 BeanFactory 無關，前面說的 ApplicationContext 其實就是一個 BeanFactory。咱們來看下和 BeanFactory 接口相關的主要的繼承結構：
我想，你們看完這個圖之後，可能就不是很開心了。ApplicationContext 往下的繼承結構前面一張圖說過了，這裏就不重複了。這張圖呢，背下來確定是不須要的，有幾個重點和你們說明下就好。
- ApplicationContext 繼承了 ListableBeanFactory，這個 Listable 的意思就是，經過這個接口，咱們能夠獲取多個 Bean，你們看源碼會發現，最頂層 BeanFactory 接口的方法都是獲取單個 Bean 的。
- ApplicationContext 繼承了 HierarchicalBeanFactory，Hierarchical 單詞自己已經能說明問題了，也就是說咱們能夠在應用中起多個 BeanFactory，而後能夠將各個 BeanFactory 設置爲父子關係。
- AutowireCapableBeanFactory 這個名字中的 Autowire 你們都很是熟悉，它就是用來自動裝配 Bean 用的，可是仔細看上圖，ApplicationContext 並無繼承它，不過不用擔憂，不使用繼承，不表明不可使用組合，若是你看到 ApplicationContext 接口定義中的最後一個方法 getAutowireCapableBeanFactory() 就知道了。
- ConfigurableListableBeanFactory 也是一個特殊的接口，看圖，特殊之處在於它繼承了第二層全部的三個接口，而 ApplicationContext 沒有。這點以後會用到。
- 請先不用花時間在其餘的接口和類上，先理解我說的這幾點就能夠了。
而後，請讀者打開編輯器，翻一下 BeanFactory、ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory、ApplicationContext 這幾個接口的代碼，大概看一下各個接口中的方法，你們內心要有底，限於篇幅，我就不貼代碼介紹了。
啓動過程分析
下面將會是冗長的代碼分析，記住，必定要本身打開源碼來看，否則純看是很累的。
第一步，咱們確定要從 ClassPathXmlApplicationContext 的構造方法提及。
public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {
private Resource[] configResources;
// 若是已經有 ApplicationContext 並須要配置成父子關係，那麼調用這個構造方法
public ClassPathXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
...
public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
throws BeansException {
super(parent);
// 根據提供的路徑，處理成配置文件數組(以分號、逗號、空格、tab、換行符分割)
setConfigLocations(configLocations);
if (refresh) {
refresh(); // 核心方法
}
}
...
}
複製代碼
接下來，就是 refresh()，這裏簡單說下爲何是 refresh()，而不是 init() 這種名字的方法。由於 ApplicationContext 創建起來之後，其實咱們是能夠經過調用 refresh() 這個方法重建的，refresh() 會將原來的 ApplicationContext 銷燬，而後再從新執行一次初始化操做。
往下看，refresh() 方法裏面調用了那麼多方法，就知道確定不簡單了，請讀者先看個大概，細節以後會詳細說。
@Override
public void refresh() throws BeansException, IllegalStateException {
// 來個鎖，否則 refresh() 還沒結束，你又來個啓動或銷燬容器的操做，那不就亂套了嘛
synchronized (this.startupShutdownMonitor) {
// 準備工做，記錄下容器的啓動時間、標記「已啓動」狀態、處理配置文件中的佔位符
prepareRefresh();
// 這步比較關鍵，這步完成後，配置文件就會解析成一個個 Bean 定義，註冊到 BeanFactory 中，
// 固然，這裏說的 Bean 尚未初始化，只是配置信息都提取出來了，
// 註冊也只是將這些信息都保存到了註冊中心(說到底核心是一個 beanName-> beanDefinition 的 map)
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 設置 BeanFactory 的類加載器，添加幾個 BeanPostProcessor，手動註冊幾個特殊的 bean
// 這塊待會會展開說
prepareBeanFactory(beanFactory);
try {
// 【這裏須要知道 BeanFactoryPostProcessor 這個知識點，Bean 若是實現了此接口，
// 那麼在容器初始化之後，Spring 會負責調用裏面的 postProcessBeanFactory 方法。】
// 這裏是提供給子類的擴展點，到這裏的時候，全部的 Bean 都加載、註冊完成了，可是都尚未初始化
// 具體的子類能夠在這步的時候添加一些特殊的 BeanFactoryPostProcessor 的實現類或作點什麼事
postProcessBeanFactory(beanFactory);
// 調用 BeanFactoryPostProcessor 各個實現類的 postProcessBeanFactory(factory) 方法
invokeBeanFactoryPostProcessors(beanFactory);
// 註冊 BeanPostProcessor 的實現類，注意看和 BeanFactoryPostProcessor 的區別
// 此接口兩個方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
// 兩個方法分別在 Bean 初始化以前和初始化以後獲得執行。注意，到這裏 Bean 還沒初始化
registerBeanPostProcessors(beanFactory);
// 初始化當前 ApplicationContext 的 MessageSource，國際化這裏就不展開說了，否則沒完沒了了
initMessageSource();
// 初始化當前 ApplicationContext 的事件廣播器，這裏也不展開了
initApplicationEventMulticaster();
// 從方法名就能夠知道，典型的模板方法(鉤子方法)，
// 具體的子類能夠在這裏初始化一些特殊的 Bean（在初始化 singleton beans 以前）
onRefresh();
// 註冊事件監聽器，監聽器須要實現 ApplicationListener 接口。這也不是咱們的重點，過
registerListeners();
// 重點，重點，重點
// 初始化全部的 singleton beans
//（lazy-init 的除外）
finishBeanFactoryInitialization(beanFactory);
// 最後，廣播事件，ApplicationContext 初始化完成
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
// 銷燬已經初始化的 singleton 的 Beans，以避免有些 bean 會一直佔用資源
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// 把異常往外拋
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } } 複製代碼
下面，咱們開始一步步來肢解這個 refresh() 方法。
建立 Bean 容器前的準備工做
這個比較簡單，直接看代碼中的幾個註釋便可。
protected void prepareRefresh() {
// 記錄啓動時間，
// 將 active 屬性設置爲 true，closed 屬性設置爲 false，它們都是 AtomicBoolean 類型
this.startupDate = System.currentTimeMillis();
this.closed.set(false);
this.active.set(true);
if (logger.isInfoEnabled()) {
logger.info("Refreshing " + this);
}
// Initialize any placeholder property sources in the context environment
initPropertySources();
// 校驗 xml 配置文件
getEnvironment().validateRequiredProperties();
this.earlyApplicationEvents = new LinkedHashSet<ApplicationEvent>();
}
複製代碼
建立 Bean 容器，加載並註冊 Bean
咱們回到 refresh() 方法中的下一行 obtainFreshBeanFactory()。
注意，這個方法是全文最重要的部分之一，這裏將會初始化 BeanFactory、加載 Bean、註冊 Bean 等等。
固然，這步結束後，Bean 並無完成初始化。這裏指的是 Bean 實例並未在這一步生成。
// AbstractApplicationContext.java
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
// 關閉舊的 BeanFactory (若是有)，建立新的 BeanFactory，加載 Bean 定義、註冊 Bean 等等
refreshBeanFactory();
// 返回剛剛建立的 BeanFactory
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (logger.isDebugEnabled()) {
logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}
複製代碼
// AbstractRefreshableApplicationContext.java 120
@Override
protected final void refreshBeanFactory() throws BeansException {
// 若是 ApplicationContext 中已經加載過 BeanFactory 了，銷燬全部 Bean，關閉 BeanFactory
// 注意，應用中 BeanFactory 原本就是能夠多個的，這裏可不是說應用全局是否有 BeanFactory，而是當前
// ApplicationContext 是否有 BeanFactory
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
// 初始化一個 DefaultListableBeanFactory，爲何用這個，咱們立刻說。
DefaultListableBeanFactory beanFactory = createBeanFactory();
// 用於 BeanFactory 的序列化，我想不部分人應該都用不到
beanFactory.setSerializationId(getId());
// 下面這兩個方法很重要，別跟丟了，具體細節以後說
// 設置 BeanFactory 的兩個配置屬性：是否容許 Bean 覆蓋、是否容許循環引用
customizeBeanFactory(beanFactory);
// 加載 Bean 到 BeanFactory 中
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
複製代碼
看到這裏的時候，我以爲讀者就應該站在高處看 ApplicationContext 了，ApplicationContext 繼承自 BeanFactory，可是它不該該被理解爲 BeanFactory 的實現類，而是說其內部持有一個實例化的 BeanFactory（DefaultListableBeanFactory）。之後全部的 BeanFactory 相關的操做實際上是委託給這個實例來處理的。
咱們說說爲何選擇實例化 DefaultListableBeanFactory ？前面咱們說了有個很重要的接口 ConfigurableListableBeanFactory，它實現了 BeanFactory 下面一層的全部三個接口，我把以前的繼承圖再拿過來你們再仔細看一下：
咱們能夠看到 ConfigurableListableBeanFactory 只有一個實現類 DefaultListableBeanFactory，並且實現類 DefaultListableBeanFactory 還經過實現右邊的 AbstractAutowireCapableBeanFactory 通吃了右路。因此結論就是，最底下這個傢伙 DefaultListableBeanFactory 基本上是最牛的 BeanFactory 了，這也是爲何這邊會使用這個類來實例化的緣由。
若是你想要在程序運行的時候動態往 Spring IOC 容器註冊新的 bean，就會使用到這個類。那咱們怎麼在運行時得到這個實例呢？
以前咱們說過 ApplicationContext 接口能獲取到 AutowireCapableBeanFactory，就是最右上角那個，而後它向下轉型就能獲得 DefaultListableBeanFactory 了。
在繼續往下以前，咱們須要先了解 BeanDefinition。咱們說 BeanFactory 是 Bean 容器，那麼 Bean 又是什麼呢？
這裏的 BeanDefinition 就是咱們所說的 Spring 的 Bean，咱們本身定義的各個 Bean 其實會轉換成一個個 BeanDefinition 存在於 Spring 的 BeanFactory 中。
因此，若是有人問你 Bean 是什麼的時候，你要知道 Bean 在代碼層面上能夠認爲是 BeanDefinition 的實例。
BeanDefinition 中保存了咱們的 Bean 信息，好比這個 Bean 指向的是哪一個類、是不是單例的、是否懶加載、這個 Bean 依賴了哪些 Bean 等等。
BeanDefinition 接口定義
咱們來看下 BeanDefinition 的接口定義：
public interface BeanDefinition extends AttributeAccessor, BeanMetadataElement {
// 咱們能夠看到，默認只提供 sington 和 prototype 兩種，
// 不少讀者可能知道還有 request, session, globalSession, application, websocket 這幾種，
// 不過，它們屬於基於 web 的擴展。
String SCOPE_SINGLETON = ConfigurableBeanFactory.SCOPE_SINGLETON;
String SCOPE_PROTOTYPE = ConfigurableBeanFactory.SCOPE_PROTOTYPE;
// 比較不重要，直接跳過吧
int ROLE_APPLICATION = 0;
int ROLE_SUPPORT = 1;
int ROLE_INFRASTRUCTURE = 2;
// 設置父 Bean，這裏涉及到 bean 繼承，不是 java 繼承。請參見附錄的詳細介紹
// 一句話就是：繼承父 Bean 的配置信息而已
void setParentName(String parentName);
// 獲取父 Bean
String getParentName();
// 設置 Bean 的類名稱，未來是要經過反射來生成實例的
void setBeanClassName(String beanClassName);
// 獲取 Bean 的類名稱
String getBeanClassName();
// 設置 bean 的 scope
void setScope(String scope);
String getScope();
// 設置是否懶加載
void setLazyInit(boolean lazyInit);
boolean isLazyInit();
// 設置該 Bean 依賴的全部的 Bean，注意，這裏的依賴不是指屬性依賴(如 @Autowire 標記的)，
// 是 depends-on="" 屬性設置的值。
void setDependsOn(String... dependsOn);
// 返回該 Bean 的全部依賴
String[] getDependsOn();
// 設置該 Bean 是否能夠注入到其餘 Bean 中，只對根據類型注入有效，
// 若是根據名稱注入，即便這邊設置了 false，也是能夠的
void setAutowireCandidate(boolean autowireCandidate);
// 該 Bean 是否能夠注入到其餘 Bean 中
boolean isAutowireCandidate();
// 主要的。同一接口的多個實現，若是不指定名字的話，Spring 會優先選擇設置 primary 爲 true 的 bean
void setPrimary(boolean primary);
// 是不是 primary 的
boolean isPrimary();
// 若是該 Bean 採用工廠方法生成，指定工廠名稱。對工廠不熟悉的讀者，請參加附錄
// 一句話就是：有些實例不是用反射生成的，而是用工廠模式生成的
void setFactoryBeanName(String factoryBeanName);
// 獲取工廠名稱
String getFactoryBeanName();
// 指定工廠類中的 工廠方法名稱
void setFactoryMethodName(String factoryMethodName);
// 獲取工廠類中的 工廠方法名稱
String getFactoryMethodName();
// 構造器參數
ConstructorArgumentValues getConstructorArgumentValues();
// Bean 中的屬性值，後面給 bean 注入屬性值的時候會說到
MutablePropertyValues getPropertyValues();
// 是否 singleton
boolean isSingleton();
// 是否 prototype
boolean isPrototype();
// 若是這個 Bean 是被設置爲 abstract，那麼不能實例化，
// 經常使用於做爲 父bean 用於繼承，其實也不多用......
boolean isAbstract();
int getRole();
String getDescription();
String getResourceDescription();
BeanDefinition getOriginatingBeanDefinition();
}
複製代碼
這個 BeanDefinition 其實已經包含不少的信息了，暫時不清楚全部的方法對應什麼東西不要緊，但願看完本文後讀者能夠完全搞清楚裏面的全部東西。
這裏接口雖然那麼多，可是沒有相似 getInstance() 這種方法來獲取咱們定義的類的實例，真正的咱們定義的類生成的實例到哪裏去了呢？彆着急，這個要很後面才能講到。
有了 BeanDefinition 的概念之後，咱們再往下看 refreshBeanFactory() 方法中的剩餘部分：
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
複製代碼
雖然只有兩個方法，但路還很長啊。。。
customizeBeanFactory
customizeBeanFactory(beanFactory) 比較簡單，就是配置是否容許 BeanDefinition 覆蓋、是否容許循環引用。
protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
if (this.allowBeanDefinitionOverriding != null) {
// 是否容許 Bean 定義覆蓋
beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
}
if (this.allowCircularReferences != null) {
// 是否容許 Bean 間的循環依賴
beanFactory.setAllowCircularReferences(this.allowCircularReferences);
}
}
複製代碼
BeanDefinition 的覆蓋問題可能會有開發者碰到這個坑，就是在配置文件中定義 bean 時使用了相同的 id 或 name，默認狀況下，allowBeanDefinitionOverriding 屬性爲 null，若是在同一配置文件中重複了，會拋錯，可是若是不是同一配置文件中，會發生覆蓋。
循環引用也很好理解：A 依賴 B，而 B 依賴 A。或 A 依賴 B，B 依賴 C，而 C 依賴 A。
默認狀況下，Spring 容許循環依賴，固然若是你在 A 的構造方法中依賴 B，在 B 的構造方法中依賴 A 是不行的。
至於這兩個屬性怎麼配置？我在附錄中進行了介紹，尤爲對於覆蓋問題，不少人都但願禁止出現 Bean 覆蓋，但是 Spring 默認是不一樣文件的時候能夠覆蓋的。
以後的源碼中還會出現這兩個屬性，讀者有個印象就能夠了。
加載 Bean: loadBeanDefinitions
接下來是最重要的 loadBeanDefinitions(beanFactory) 方法了，這個方法將根據配置，加載各個 Bean，而後放到 BeanFactory 中。
讀取配置的操做在 XmlBeanDefinitionReader 中，其負責加載配置、解析。
// AbstractXmlApplicationContext.java 80
/** 咱們能夠看到，此方法將經過一個 XmlBeanDefinitionReader 實例來加載各個 Bean。*/
@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// 給這個 BeanFactory 實例化一個 XmlBeanDefinitionReader
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// Configure the bean definition reader with this context's // resource loading environment. beanDefinitionReader.setEnvironment(this.getEnvironment()); beanDefinitionReader.setResourceLoader(this); beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // 初始化 BeanDefinitionReader，其實這個是提供給子類覆寫的， // 我看了一下，沒有類覆寫這個方法，咱們姑且當作不重要吧 initBeanDefinitionReader(beanDefinitionReader); // 重點來了，繼續往下 loadBeanDefinitions(beanDefinitionReader); } 複製代碼
如今還在這個類中，接下來用剛剛初始化的 Reader 開始來加載 xml 配置，這塊代碼讀者能夠選擇性跳過，不是很重要。也就是說，下面這個代碼塊，讀者能夠很輕鬆地略過。
// AbstractXmlApplicationContext.java 120
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = getConfigResources();
if (configResources != null) {
// 往下看
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = getConfigLocations();
if (configLocations != null) {
// 2
reader.loadBeanDefinitions(configLocations);
}
}
// 上面雖然有兩個分支，不過第二個分支很快經過解析路徑轉換爲 Resource 之後也會進到這裏
@Override
public int loadBeanDefinitions(Resource... resources) throws BeanDefinitionStoreException {
Assert.notNull(resources, "Resource array must not be null");
int counter = 0;
// 注意這裏是個 for 循環，也就是每一個文件是一個 resource
for (Resource resource : resources) {
// 繼續往下看
counter += loadBeanDefinitions(resource);
}
// 最後返回 counter，表示總共加載了多少的 BeanDefinition
return counter;
}
// XmlBeanDefinitionReader 303
@Override
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
return loadBeanDefinitions(new EncodedResource(resource));
}
// XmlBeanDefinitionReader 314
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
Assert.notNull(encodedResource, "EncodedResource must not be null");
if (logger.isInfoEnabled()) {
logger.info("Loading XML bean definitions from " + encodedResource.getResource());
}
// 用一個 ThreadLocal 來存放配置文件資源
Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
if (currentResources == null) {
currentResources = new HashSet<EncodedResource>(4);
this.resourcesCurrentlyBeingLoaded.set(currentResources);
}
if (!currentResources.add(encodedResource)) {
throw new BeanDefinitionStoreException(
"Detected cyclic loading of " + encodedResource + " - check your import definitions!");
}
try {
InputStream inputStream = encodedResource.getResource().getInputStream();
try {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
// 核心部分是這裏，往下面看
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
inputStream.close();
}
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.getResource(), ex);
}
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
// 還在這個文件中，第 388 行
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
// 這裏就不看了，將 xml 文件轉換爲 Document 對象
Document doc = doLoadDocument(inputSource, resource);
// 繼續
return registerBeanDefinitions(doc, resource);
}
catch (...
}
// 還在這個文件中，第 505 行
// 返回值：返回從當前配置文件加載了多少數量的 Bean
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
int countBefore = getRegistry().getBeanDefinitionCount();
// 這裏
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
// DefaultBeanDefinitionDocumentReader 90
@Override
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
this.readerContext = readerContext;
logger.debug("Loading bean definitions");
Element root = doc.getDocumentElement();
// 從 xml 根節點開始解析文件
doRegisterBeanDefinitions(root);
}
複製代碼
通過漫長的鏈路，一個配置文件終於轉換爲一顆 DOM 樹了，注意，這裏指的是其中一個配置文件，不是全部的，讀者能夠看到上面有個 for 循環的。下面開始從根節點開始解析：
doRegisterBeanDefinitions：
// DefaultBeanDefinitionDocumentReader 116
protected void doRegisterBeanDefinitions(Element root) {
// 咱們看名字就知道，BeanDefinitionParserDelegate 一定是一個重要的類，它負責解析 Bean 定義，
// 這裏爲何要定義一個 parent? 看到後面就知道了，是遞歸問題，
// 由於 <beans /> 內部是能夠定義 <beans /> 的，因此這個方法的 root 其實不必定就是 xml 的根節點，也能夠是嵌套在裏面的 <beans /> 節點，從源碼分析的角度，咱們當作根節點就行了
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(getReaderContext(), root, parent);
if (this.delegate.isDefaultNamespace(root)) {
// 這塊說的是根節點 <beans ... profile="dev" /> 中的 profile 是不是當前環境須要的，
// 若是當前環境配置的 profile 不包含此 profile，那就直接 return 了，不對此 <beans /> 解析
// 不熟悉 profile 爲什麼物，不熟悉怎麼配置 profile 讀者的請移步附錄區
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
if (StringUtils.hasText(profileSpec)) {
String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
if (logger.isInfoEnabled()) {
logger.info("Skipped XML bean definition file due to specified profiles [" + profileSpec +
"] not matching: " + getReaderContext().getResource());
}
return;
}
}
}
preProcessXml(root); // 鉤子
// 往下看
parseBeanDefinitions(root, this.delegate);
postProcessXml(root); // 鉤子
this.delegate = parent;
}
複製代碼
preProcessXml(root) 和 postProcessXml(root) 是給子類用的鉤子方法，鑑於沒有被使用到，也不是咱們的重點，咱們直接跳過。
這裏涉及到了 profile 的問題，對於不瞭解的讀者，我在附錄中對 profile 作了簡單的解釋，讀者能夠參考一下。
接下來，看核心解析方法 parseBeanDefinitions(root, this.delegate) :
// default namespace 涉及到的就四個標籤 <import />、<alias />、<bean /> 和 <beans />，
// 其餘的屬於 custom 的
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
if (delegate.isDefaultNamespace(ele)) {
// 解析 default namespace 下面的幾個元素
parseDefaultElement(ele, delegate);
}
else {
// 解析其餘 namespace 的元素
delegate.parseCustomElement(ele);
}
}
}
}
else {
delegate.parseCustomElement(root);
}
}
複製代碼
從上面的代碼，咱們能夠看到，對於每一個配置來講，分別進入到 parseDefaultElement(ele, delegate); 和 delegate.parseCustomElement(ele); 這兩個分支了。
parseDefaultElement(ele, delegate) 表明解析的節點是 <import />、<alias />、<bean />、<beans /> 這幾個。
這裏的四個標籤之因此是 default 的，是由於它們是處於這個 namespace 下定義的：
http://www.springframework.org/schema/beans 複製代碼又到初學者科普時間，不熟悉 namespace 的讀者請看下面貼出來的 xml，這裏的第二行 xmlns 就是咯。
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName"> 複製代碼而對於其餘的標籤，將進入到 delegate.parseCustomElement(element) 這個分支。如咱們常常會使用到的
<mvc />、<task />、<context />、<aop />等。這些屬於擴展，若是須要使用上面這些 」非 default「 標籤，那麼上面的 xml 頭部的地方也要引入相應的 namespace 和 .xsd 文件的路徑，以下所示。同時代碼中須要提供相應的 parser 來解析，如 MvcNamespaceHandler、TaskNamespaceHandler、ContextNamespaceHandler、AopNamespaceHandler 等。
假如讀者想分析
<context:property-placeholder location="classpath:xx.properties" />的實現原理，就應該到 ContextNamespaceHandler 中找答案。<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:mvc="http://www.springframework.org/schema/mvc" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd " default-autowire="byName"> 複製代碼
回過神來，看看處理 default 標籤的方法：
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
// 處理 <import /> 標籤
importBeanDefinitionResource(ele);
}
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
// 處理 <alias /> 標籤訂義
// <alias name="fromName" alias="toName"/>
processAliasRegistration(ele);
}
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
// 處理 <bean /> 標籤訂義，這也算是咱們的重點吧
processBeanDefinition(ele, delegate);
}
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// 若是碰到的是嵌套的 <beans /> 標籤，須要遞歸
doRegisterBeanDefinitions(ele);
}
}
複製代碼
若是每一個標籤都說，那我不吐血，大家都要吐血了。咱們挑咱們的重點 <bean /> 標籤出來講。
processBeanDefinition 解析 bean 標籤
下面是 processBeanDefinition 解析 <bean /> 標籤：
// DefaultBeanDefinitionDocumentReader 298
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// 將 <bean /> 節點中的信息提取出來，而後封裝到一個 BeanDefinitionHolder 中，細節往下看
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
// 下面的幾行先不要看，跳過先，跳過先，跳過先，後面會繼續說的
if (bdHolder != null) {
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// Register the final decorated instance.
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// Send registration event.
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
複製代碼
繼續往下看怎麼解析以前，咱們先看下 <bean /> 標籤中能夠定義哪些屬性：
| Property | |
|---|---|
| class | 類的全限定名 |
| name | 可指定 id、name(用逗號、分號、空格分隔) |
| scope | 做用域 |
| constructor arguments | 指定構造參數 |
| properties | 設置屬性的值 |
| autowiring mode | no(默認值)、byName、byType、 constructor |
| lazy-initialization mode | 是否懶加載(若是被非懶加載的bean依賴了那麼其實也就不能懶加載了) |
| initialization method | bean 屬性設置完成後，會調用這個方法 |
| destruction method | bean 銷燬後的回調方法 |
上面表格中的內容我想你們都很是熟悉吧，若是不熟悉，那就是你不夠了解 Spring 的配置了。
簡單地說就是像下面這樣子：
<bean id="exampleBean" name="name1, name2, name3" class="com.javadoop.ExampleBean"
scope="singleton" lazy-init="true" init-method="init" destroy-method="cleanup">
<!-- 能夠用下面三種形式指定構造參數 -->
<constructor-arg type="int" value="7500000"/>
<constructor-arg name="years" value="7500000"/>
<constructor-arg index="0" value="7500000"/>
<!-- property 的幾種狀況 -->
<property name="beanOne">
<ref bean="anotherExampleBean"/>
</property>
<property name="beanTwo" ref="yetAnotherBean"/>
<property name="integerProperty" value="1"/>
</bean>
複製代碼
固然，除了上面舉例出來的這些，還有 factory-bean、factory-method、<lockup-method />、<replaced-method />、<meta />、<qualifier /> 這幾個，你們是否是熟悉呢？本身檢驗一下本身對 Spring 中 bean 的瞭解程度。
有了以上這些知識之後，咱們再繼續往裏看怎麼解析 bean 元素，是怎麼轉換到 BeanDefinitionHolder 的。
// BeanDefinitionParserDelegate 428
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
return parseBeanDefinitionElement(ele, null);
}
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {
String id = ele.getAttribute(ID_ATTRIBUTE);
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
List<String> aliases = new ArrayList<String>();
// 將 name 屬性的定義按照 「逗號、分號、空格」 切分，造成一個 別名列表數組，
// 固然，若是你不定義 name 屬性的話，就是空的了
// 我在附錄中簡單介紹了一下 id 和 name 的配置，你們能夠看一眼，有個20秒就能夠了
if (StringUtils.hasLength(nameAttr)) {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
}
String beanName = id;
// 若是沒有指定id, 那麼用別名列表的第一個名字做爲beanName
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove(0);
if (logger.isDebugEnabled()) {
logger.debug("No XML 'id' specified - using '" + beanName +
"' as bean name and " + aliases + " as aliases");
}
}
if (containingBean == null) {
checkNameUniqueness(beanName, aliases, ele);
}
// 根據 <bean ...>...</bean> 中的配置建立 BeanDefinition，而後把配置中的信息都設置到實例中,
// 細節後面細說，先知道下面這行結束後，一個 BeanDefinition 實例就出來了。
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
// 到這裏，整個 <bean /> 標籤就算解析結束了，一個 BeanDefinition 就造成了。
if (beanDefinition != null) {
// 若是都沒有設置 id 和 name，那麼此時的 beanName 就會爲 null，進入下面這塊代碼產生
// 若是讀者不感興趣的話，我以爲不須要關心這塊代碼，對本文源碼分析來講，這些東西不重要
if (!StringUtils.hasText(beanName)) {
try {
if (containingBean != null) {// 按照咱們的思路，這裏 containingBean 是 null 的
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
}
else {
// 若是咱們不定義 id 和 name，那麼咱們引言裏的那個例子：
// 1. beanName 爲：com.javadoop.example.MessageServiceImpl#0
// 2. beanClassName 爲：com.javadoop.example.MessageServiceImpl
beanName = this.readerContext.generateBeanName(beanDefinition);
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
!this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
// 把 beanClassName 設置爲 Bean 的別名
aliases.add(beanClassName);
}
}
if (logger.isDebugEnabled()) {
logger.debug("Neither XML 'id' nor 'name' specified - " +
"using generated bean name [" + beanName + "]");
}
}
catch (Exception ex) {
error(ex.getMessage(), ele);
return null;
}
}
String[] aliasesArray = StringUtils.toStringArray(aliases);
// 返回 BeanDefinitionHolder
return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
}
return null;
}
複製代碼
而後，咱們再看看怎麼根據配置建立 BeanDefinition 實例的：
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, BeanDefinition containingBean) {
this.parseState.push(new BeanEntry(beanName));
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
}
try {
String parent = null;
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
}
// 建立 BeanDefinition，而後設置類信息而已，很簡單，就不貼代碼了
AbstractBeanDefinition bd = createBeanDefinition(className, parent);
// 設置 BeanDefinition 的一堆屬性，這些屬性定義在 AbstractBeanDefinition 中
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
/**
* 下面的一堆是解析 <bean>......</bean> 內部的子元素，
* 解析出來之後的信息都放到 bd 的屬性中
*/
// 解析 <meta />
parseMetaElements(ele, bd);
// 解析 <lookup-method />
parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
// 解析 <replaced-method />
parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
// 解析 <constructor-arg />
parseConstructorArgElements(ele, bd);
// 解析 <property />
parsePropertyElements(ele, bd);
// 解析 <qualifier />
parseQualifierElements(ele, bd);
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele));
return bd;
}
catch (ClassNotFoundException ex) {
error("Bean class [" + className + "] not found", ele, ex);
}
catch (NoClassDefFoundError err) {
error("Class that bean class [" + className + "] depends on not found", ele, err);
}
catch (Throwable ex) {
error("Unexpected failure during bean definition parsing", ele, ex);
}
finally {
this.parseState.pop();
}
return null;
}
複製代碼
到這裏，咱們已經完成了根據 <bean /> 配置建立了一個 BeanDefinitionHolder 實例。注意，是一個。
咱們回到解析 <bean /> 的入口方法:
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// 將 <bean /> 節點轉換爲 BeanDefinitionHolder，就是上面說的一堆
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
// 若是有自定義屬性的話，進行相應的解析，先忽略
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// 咱們把這步叫作 註冊Bean 吧
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// 註冊完成後，發送事件，本文不展開說這個
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
複製代碼
你們再仔細看一下這塊吧，咱們後面就不回來講這個了。這裏已經根據一個 <bean /> 標籤產生了一個 BeanDefinitionHolder 的實例，這個實例裏面也就是一個 BeanDefinition 的實例和它的 beanName、aliases 這三個信息，注意，咱們的關注點始終在 BeanDefinition 上：
public class BeanDefinitionHolder implements BeanMetadataElement {
private final BeanDefinition beanDefinition;
private final String beanName;
private final String[] aliases;
...
複製代碼
而後咱們準備註冊這個 BeanDefinition，最後，把這個註冊事件發送出去。
下面，咱們開始說說註冊 Bean 吧。
註冊 Bean
// BeanDefinitionReaderUtils 143
public static void registerBeanDefinition(
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
throws BeanDefinitionStoreException {
String beanName = definitionHolder.getBeanName();
// 註冊這個 Bean
registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());
// 若是還有別名的話，也要根據別名所有註冊一遍，否則根據別名就會找不到 Bean 了
String[] aliases = definitionHolder.getAliases();
if (aliases != null) {
for (String alias : aliases) {
// alias -> beanName 保存它們的別名信息，這個很簡單，用一個 map 保存一下就能夠了，
// 獲取的時候，會先將 alias 轉換爲 beanName，而後再查找
registry.registerAlias(beanName, alias);
}
}
}
複製代碼
別名註冊的放一邊，畢竟它很簡單，咱們看看怎麼註冊 Bean。
// DefaultListableBeanFactory 793
@Override
public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
throws BeanDefinitionStoreException {
Assert.hasText(beanName, "Bean name must not be empty");
Assert.notNull(beanDefinition, "BeanDefinition must not be null");
if (beanDefinition instanceof AbstractBeanDefinition) {
try {
((AbstractBeanDefinition) beanDefinition).validate();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(...);
}
}
// old? 還記得 「容許 bean 覆蓋」 這個配置嗎？allowBeanDefinitionOverriding
BeanDefinition oldBeanDefinition;
// 以後會看到，全部的 Bean 註冊後會放入這個 beanDefinitionMap 中
oldBeanDefinition = this.beanDefinitionMap.get(beanName);
// 處理重複名稱的 Bean 定義的狀況
if (oldBeanDefinition != null) {
if (!isAllowBeanDefinitionOverriding()) {
// 若是不容許覆蓋的話，拋異常
throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription()...
}
else if (oldBeanDefinition.getRole() < beanDefinition.getRole()) {
// log...用框架定義的 Bean 覆蓋用戶自定義的 Bean
}
else if (!beanDefinition.equals(oldBeanDefinition)) {
// log...用新的 Bean 覆蓋舊的 Bean
}
else {
// log...用同等的 Bean 覆蓋舊的 Bean，這裏指的是 equals 方法返回 true 的 Bean
}
// 覆蓋
this.beanDefinitionMap.put(beanName, beanDefinition);
}
else {
// 判斷是否已經有其餘的 Bean 開始初始化了.
// 注意，"註冊Bean" 這個動做結束，Bean 依然尚未初始化，咱們後面會有大篇幅說初始化過程，
// 在 Spring 容器啓動的最後，會 預初始化 全部的 singleton beans
if (hasBeanCreationStarted()) {
// Cannot modify startup-time collection elements anymore (for stable iteration)
synchronized (this.beanDefinitionMap) {
this.beanDefinitionMap.put(beanName, beanDefinition);
List<String> updatedDefinitions = new ArrayList<String>(this.beanDefinitionNames.size() + 1);
updatedDefinitions.addAll(this.beanDefinitionNames);
updatedDefinitions.add(beanName);
this.beanDefinitionNames = updatedDefinitions;
if (this.manualSingletonNames.contains(beanName)) {
Set<String> updatedSingletons = new LinkedHashSet<String>(this.manualSingletonNames);
updatedSingletons.remove(beanName);
this.manualSingletonNames = updatedSingletons;
}
}
}
else {
// 最正常的應該是進到這個分支。
// 將 BeanDefinition 放到這個 map 中，這個 map 保存了全部的 BeanDefinition
this.beanDefinitionMap.put(beanName, beanDefinition);
// 這是個 ArrayList，因此會按照 bean 配置的順序保存每個註冊的 Bean 的名字
this.beanDefinitionNames.add(beanName);
// 這是個 LinkedHashSet，表明的是手動註冊的 singleton bean，
// 注意這裏是 remove 方法，到這裏的 Bean 固然不是手動註冊的
// 手動指的是經過調用如下方法註冊的 bean ：
// registerSingleton(String beanName, Object singletonObject)
// 這不是重點，解釋只是爲了避免讓你們疑惑。Spring 會在後面"手動"註冊一些 Bean，
// 如 "environment"、"systemProperties" 等 bean，咱們本身也能夠在運行時註冊 Bean 到容器中的
this.manualSingletonNames.remove(beanName);
}
// 這個不重要，在預初始化的時候會用到，沒必要管它。
this.frozenBeanDefinitionNames = null;
}
if (oldBeanDefinition != null || containsSingleton(beanName)) {
resetBeanDefinition(beanName);
}
}
複製代碼
總結一下，到這裏已經初始化了 Bean 容器，<bean /> 配置也相應的轉換爲了一個個 BeanDefinition，而後註冊了各個 BeanDefinition 到註冊中心，而且發送了註冊事件。
到這裏是一個分水嶺，前面的內容都還算比較簡單，你們要清楚地知道前面都作了哪些事情。
Bean 容器實例化完成後
說到這裏，咱們回到 refresh() 方法，我從新貼了一遍代碼，看看咱們說到哪了。是的，咱們才說完 obtainFreshBeanFactory() 方法。
考慮到篇幅，這裏開始大幅縮減掉不必詳細介紹的部分，你們直接看下面的代碼中的註釋就行了。
@Override
public void refresh() throws BeansException, IllegalStateException {
// 來個鎖，否則 refresh() 還沒結束，你又來個啓動或銷燬容器的操做，那不就亂套了嘛
synchronized (this.startupShutdownMonitor) {
// 準備工做，記錄下容器的啓動時間、標記「已啓動」狀態、處理配置文件中的佔位符
prepareRefresh();
// 這步比較關鍵，這步完成後，配置文件就會解析成一個個 Bean 定義，註冊到 BeanFactory 中，
// 固然，這裏說的 Bean 尚未初始化，只是配置信息都提取出來了，
// 註冊也只是將這些信息都保存到了註冊中心(說到底核心是一個 beanName-> beanDefinition 的 map)
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 設置 BeanFactory 的類加載器，添加幾個 BeanPostProcessor，手動註冊幾個特殊的 bean
// 這塊待會會展開說
prepareBeanFactory(beanFactory);
try {
// 【這裏須要知道 BeanFactoryPostProcessor 這個知識點，Bean 若是實現了此接口，
// 那麼在容器初始化之後，Spring 會負責調用裏面的 postProcessBeanFactory 方法。】
// 這裏是提供給子類的擴展點，到這裏的時候，全部的 Bean 都加載、註冊完成了，可是都尚未初始化
// 具體的子類能夠在這步的時候添加一些特殊的 BeanFactoryPostProcessor 的實現類或作點什麼事
postProcessBeanFactory(beanFactory);
// 調用 BeanFactoryPostProcessor 各個實現類的 postProcessBeanFactory(factory) 回調方法
invokeBeanFactoryPostProcessors(beanFactory);
// 註冊 BeanPostProcessor 的實現類，注意看和 BeanFactoryPostProcessor 的區別
// 此接口兩個方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
// 兩個方法分別在 Bean 初始化以前和初始化以後獲得執行。這裏僅僅是註冊，以後會看到回調這兩方法的時機
registerBeanPostProcessors(beanFactory);
// 初始化當前 ApplicationContext 的 MessageSource，國際化這裏就不展開說了，否則沒完沒了了
initMessageSource();
// 初始化當前 ApplicationContext 的事件廣播器，這裏也不展開了
initApplicationEventMulticaster();
// 從方法名就能夠知道，典型的模板方法(鉤子方法)，不展開說
// 具體的子類能夠在這裏初始化一些特殊的 Bean（在初始化 singleton beans 以前）
onRefresh();
// 註冊事件監聽器，監聽器須要實現 ApplicationListener 接口。這也不是咱們的重點，過
registerListeners();
// 重點，重點，重點
// 初始化全部的 singleton beans
//（lazy-init 的除外）
finishBeanFactoryInitialization(beanFactory);
// 最後，廣播事件，ApplicationContext 初始化完成，不展開
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
// 銷燬已經初始化的 singleton 的 Beans，以避免有些 bean 會一直佔用資源
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// 把異常往外拋
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } } 複製代碼
準備 Bean 容器: prepareBeanFactory
以前咱們說過，Spring 把咱們在 xml 配置的 bean 都註冊之後，會"手動"註冊一些特殊的 bean。
這裏簡單介紹下 prepareBeanFactory(factory) 方法：
/**
* Configure the factory's standard context characteristics, * such as the context's ClassLoader and post-processors.
* @param beanFactory the BeanFactory to configure
*/
protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
// 設置 BeanFactory 的類加載器，咱們知道 BeanFactory 須要加載類，也就須要類加載器，
// 這裏設置爲加載當前 ApplicationContext 類的類加載器
beanFactory.setBeanClassLoader(getClassLoader());
// 設置 BeanExpressionResolver
beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
//
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
// 添加一個 BeanPostProcessor，這個 processor 比較簡單：
// 實現了 Aware 接口的 beans 在初始化的時候，這個 processor 負責回調，
// 這個咱們很經常使用，如咱們會爲了獲取 ApplicationContext 而 implement ApplicationContextAware
// 注意：它不只僅回調 ApplicationContextAware，
// 還會負責回調 EnvironmentAware、ResourceLoaderAware 等，看下源碼就清楚了
beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
// 下面幾行的意思就是，若是某個 bean 依賴於如下幾個接口的實現類，在自動裝配的時候忽略它們，
// Spring 會經過其餘方式來處理這些依賴。
beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);
/**
* 下面幾行就是爲特殊的幾個 bean 賦值，若是有 bean 依賴瞭如下幾個，會注入這邊相應的值，
* 以前咱們說過，"當前 ApplicationContext 持有一個 BeanFactory"，這裏解釋了第一行
* ApplicationContext 還繼承了 ResourceLoader、ApplicationEventPublisher、MessageSource
* 因此對於這幾個依賴，能夠賦值爲 this，注意 this 是一個 ApplicationContext
* 那這裏怎麼沒看到爲 MessageSource 賦值呢？那是由於 MessageSource 被註冊成爲了一個普通的 bean
*/
beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
beanFactory.registerResolvableDependency(ResourceLoader.class, this);
beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
beanFactory.registerResolvableDependency(ApplicationContext.class, this);
// 這個 BeanPostProcessor 也很簡單，在 bean 實例化後，若是是 ApplicationListener 的子類，
// 那麼將其添加到 listener 列表中，能夠理解成：註冊 事件監聽器
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
// 這裏涉及到特殊的 bean，名爲：loadTimeWeaver，這不是咱們的重點，忽略它
// tips: ltw 是 AspectJ 的概念，指的是在運行期進行織入，這個和 Spring AOP 不同，
// 感興趣的讀者請參考我寫的關於 AspectJ 的另外一篇文章 https://www.javadoop.com/post/aspectj
if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
// Set a temporary ClassLoader for type matching.
beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
}
/**
* 從下面幾行代碼咱們能夠知道，Spring 每每很 "智能" 就是由於它會幫咱們默認註冊一些有用的 bean，
* 咱們也能夠選擇覆蓋
*/
// 若是沒有定義 "environment" 這個 bean，那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
}
// 若是沒有定義 "systemProperties" 這個 bean，那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
}
// 若是沒有定義 "systemEnvironment" 這個 bean，那麼 Spring 會 "手動" 註冊一個
if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
}
}
複製代碼
在上面這塊代碼中，Spring 對一些特殊的 bean 進行了處理，讀者若是暫時還不能消化它們也沒有關係，慢慢往下看。
初始化全部的 singleton beans
咱們的重點固然是 finishBeanFactoryInitialization(beanFactory); 這個巨頭了，這裏會負責初始化全部的 singleton beans。
注意，後面的描述中，我都會使用初始化或預初始化來表明這個階段，Spring 會在這個階段完成全部的 singleton beans 的實例化。
咱們來總結一下，到目前爲止，應該說 BeanFactory 已經建立完成，而且全部的實現了 BeanFactoryPostProcessor 接口的 Bean 都已經初始化而且其中的 postProcessBeanFactory(factory) 方法已經獲得回調執行了。並且 Spring 已經「手動」註冊了一些特殊的 Bean，如 ‘environment’、‘systemProperties’ 等。
剩下的就是初始化 singleton beans 了，咱們知道它們是單例的，若是沒有設置懶加載，那麼 Spring 會在接下來初始化全部的 singleton beans。
// AbstractApplicationContext.java 834
// 初始化剩餘的 singleton beans
protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
// 首先，初始化名字爲 conversionService 的 Bean。本着送佛送到西的精神，我在附錄中簡單介紹了一下 ConversionService，由於這實在太實用了
// 什麼，看代碼這裏沒有初始化 Bean 啊！
// 注意了，初始化的動做包裝在 beanFactory.getBean(...) 中，這裏先不說細節，先往下看吧
if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
beanFactory.setConversionService(
beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
}
// Register a default embedded value resolver if no bean post-processor
// (such as a PropertyPlaceholderConfigurer bean) registered any before:
// at this point, primarily for resolution in annotation attribute values.
if (!beanFactory.hasEmbeddedValueResolver()) {
beanFactory.addEmbeddedValueResolver(new StringValueResolver() {
@Override
public String resolveStringValue(String strVal) {
return getEnvironment().resolvePlaceholders(strVal);
}
});
}
// 先初始化 LoadTimeWeaverAware 類型的 Bean
// 以前也說過，這是 AspectJ 相關的內容，放心跳過吧
String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
for (String weaverAwareName : weaverAwareNames) {
getBean(weaverAwareName);
}
// Stop using the temporary ClassLoader for type matching.
beanFactory.setTempClassLoader(null);
// 沒什麼別的目的，由於到這一步的時候，Spring 已經開始預初始化 singleton beans 了，
// 確定不但願這個時候還出現 bean 定義解析、加載、註冊。
beanFactory.freezeConfiguration();
// 開始初始化
beanFactory.preInstantiateSingletons();
}
複製代碼
從上面最後一行往裏看，咱們就又回到 DefaultListableBeanFactory 這個類了，這個類你們應該都不陌生了吧。
preInstantiateSingletons
// DefaultListableBeanFactory 728
@Override
public void preInstantiateSingletons() throws BeansException {
if (this.logger.isDebugEnabled()) {
this.logger.debug("Pre-instantiating singletons in " + this);
}
// this.beanDefinitionNames 保存了全部的 beanNames
List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);
// 觸發全部的非懶加載的 singleton beans 的初始化操做
for (String beanName : beanNames) {
// 合併父 Bean 中的配置，注意 <bean id="" class="" parent="" /> 中的 parent，用的很少吧，
// 考慮到這可能會影響你們的理解，我在附錄中解釋了一下 "Bean 繼承"，不瞭解的請到附錄中看一下
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
// 非抽象、非懶加載的 singletons。若是配置了 'abstract = true'，那是不須要初始化的
if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
// 處理 FactoryBean(讀者若是不熟悉 FactoryBean，請移步附錄區瞭解)
if (isFactoryBean(beanName)) {
// FactoryBean 的話，在 beanName 前面加上 ‘&’ 符號。再調用 getBean，getBean 方法別急
final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX + beanName);
// 判斷當前 FactoryBean 是不是 SmartFactoryBean 的實現，此處忽略，直接跳過
boolean isEagerInit;
if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
isEagerInit = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
@Override
public Boolean run() {
return ((SmartFactoryBean<?>) factory).isEagerInit();
}
}, getAccessControlContext());
}
else {
isEagerInit = (factory instanceof SmartFactoryBean &&
((SmartFactoryBean<?>) factory).isEagerInit());
}
if (isEagerInit) {
getBean(beanName);
}
}
else {
// 對於普通的 Bean，只要調用 getBean(beanName) 這個方法就能夠進行初始化了
getBean(beanName);
}
}
}
// 到這裏說明全部的非懶加載的 singleton beans 已經完成了初始化
// 若是咱們定義的 bean 是實現了 SmartInitializingSingleton 接口的，那麼在這裏獲得回調，忽略
for (String beanName : beanNames) {
Object singletonInstance = getSingleton(beanName);
if (singletonInstance instanceof SmartInitializingSingleton) {
final SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;
if (System.getSecurityManager() != null) {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
smartSingleton.afterSingletonsInstantiated();
return null;
}
}, getAccessControlContext());
}
else {
smartSingleton.afterSingletonsInstantiated();
}
}
}
}
複製代碼
接下來，咱們就進入到 getBean(beanName) 方法了，這個方法咱們常常用來從 BeanFactory 中獲取一個 Bean，而初始化的過程也封裝到了這個方法裏。
getBean
在繼續前進以前，讀者應該具有 FactoryBean 的知識，若是讀者還不熟悉，請移步附錄部分了解 FactoryBean。
// AbstractBeanFactory 196
@Override
public Object getBean(String name) throws BeansException {
return doGetBean(name, null, null, false);
}
// 咱們在剖析初始化 Bean 的過程，可是 getBean 方法咱們常常是用來從容器中獲取 Bean 用的，注意切換思路，
// 已經初始化過了就從容器中直接返回，不然就先初始化再返回
@SuppressWarnings("unchecked")
protected <T> T doGetBean(
final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
throws BeansException {
// 獲取一個 「正統的」 beanName，處理兩種狀況，一個是前面說的 FactoryBean(前面帶 ‘&’)，
// 一個是別名問題，由於這個方法是 getBean，獲取 Bean 用的，你要是傳一個別名進來，是徹底能夠的
final String beanName = transformedBeanName(name);
// 注意跟着這個，這個是返回值
Object bean;
// 檢查下是否是已經建立過了
Object sharedInstance = getSingleton(beanName);
// 這裏說下 args 唄，雖然看上去一點不重要。前面咱們一路進來的時候都是 getBean(beanName)，
// 因此 args 傳參實際上是 null 的，可是若是 args 不爲空的時候，那麼意味着調用方不是但願獲取 Bean，而是建立 Bean
if (sharedInstance != null && args == null) {
if (logger.isDebugEnabled()) {
if (isSingletonCurrentlyInCreation(beanName)) {
logger.debug("...");
}
else {
logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
}
}
// 下面這個方法：若是是普通 Bean 的話，直接返回 sharedInstance，
// 若是是 FactoryBean 的話，返回它建立的那個實例對象
// (FactoryBean 知識，讀者若不清楚請移步附錄)
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
else {
if (isPrototypeCurrentlyInCreation(beanName)) {
// 建立過了此 beanName 的 prototype 類型的 bean，那麼拋異常，
// 每每是由於陷入了循環引用
throw new BeanCurrentlyInCreationException(beanName);
}
// 檢查一下這個 BeanDefinition 在容器中是否存在
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
// 若是當前容器不存在這個 BeanDefinition，試試父容器中有沒有
String nameToLookup = originalBeanName(name);
if (args != null) {
// 返回父容器的查詢結果
return (T) parentBeanFactory.getBean(nameToLookup, args);
}
else {
// No args -> delegate to standard getBean method.
return parentBeanFactory.getBean(nameToLookup, requiredType);
}
}
if (!typeCheckOnly) {
// typeCheckOnly 爲 false，將當前 beanName 放入一個 alreadyCreated 的 Set 集合中。
markBeanAsCreated(beanName);
}
/*
* 稍稍總結一下：
* 到這裏的話，要準備建立 Bean 了，對於 singleton 的 Bean 來講，容器中還沒建立過此 Bean；
* 對於 prototype 的 Bean 來講，原本就是要建立一個新的 Bean。
*/
try {
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
// 先初始化依賴的全部 Bean，這個很好理解。
// 注意，這裏的依賴指的是 depends-on 中定義的依賴
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
for (String dep : dependsOn) {
// 檢查是否是有循環依賴，這裏的循環依賴和咱們前面說的循環依賴又不同，這裏確定是不容許出現的，否則要亂套了，讀者想一下就知道了
if (isDependent(beanName, dep)) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
}
// 註冊一下依賴關係
registerDependentBean(dep, beanName);
// 先初始化被依賴項
getBean(dep);
}
}
// 若是是 singleton scope 的，建立 singleton 的實例
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
try {
// 執行建立 Bean，詳情後面再說
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
// 若是是 prototype scope 的，建立 prototype 的實例
else if (mbd.isPrototype()) {
// It's a prototype -> create a new instance. Object prototypeInstance = null; try { beforePrototypeCreation(beanName); // 執行建立 Bean prototypeInstance = createBean(beanName, mbd, args); } finally { afterPrototypeCreation(beanName); } bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd); } // 若是不是 singleton 和 prototype 的話，須要委託給相應的實現類來處理 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>() { @Override public Object getObject() throws BeansException { beforePrototypeCreation(beanName); try { // 執行建立 Bean 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()); } } return (T) bean; } 複製代碼
你們應該也猜到了，接下來固然是分析 createBean 方法：
protected abstract Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException;
複製代碼
第三個參數 args 數組表明建立實例須要的參數，不就是給構造方法用的參數，或者是工廠 Bean 的參數嘛，不過要注意，在咱們的初始化階段，args 是 null。
這回咱們要到一個新的類了 AbstractAutowireCapableBeanFactory，看類名，AutowireCapable？類名是否是也說明了點問題了。
主要是爲了如下場景，採用 @Autowired 註解注入屬性值：
public class MessageServiceImpl implements MessageService {
@Autowired
private UserService userService;
public String getMessage() {
return userService.getMessage();
}
}
複製代碼
<bean id="messageService" class="com.javadoop.example.MessageServiceImpl" />
複製代碼
以上這種屬於混用了 xml 和 註解 兩種方式的配置方式，Spring 會處理這種狀況。
好了，讀者要知道這麼回事就能夠了，繼續向前。
// AbstractAutowireCapableBeanFactory 447
/**
* Central method of this class: creates a bean instance,
* populates the bean instance, applies post-processors, etc.
* @see #doCreateBean
*/
@Override
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
if (logger.isDebugEnabled()) {
logger.debug("Creating instance of bean '" + beanName + "'");
}
RootBeanDefinition mbdToUse = mbd;
// 確保 BeanDefinition 中的 Class 被加載
Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
mbdToUse = new RootBeanDefinition(mbd);
mbdToUse.setBeanClass(resolvedClass);
}
// 準備方法覆寫，這裏又涉及到一個概念：MethodOverrides，它來自於 bean 定義中的 <lookup-method />
// 和 <replaced-method />，若是讀者感興趣，回到 bean 解析的地方看看對這兩個標籤的解析。
// 我在附錄中也對這兩個標籤的相關知識點進行了介紹，讀者能夠移步去看看
try {
mbdToUse.prepareMethodOverrides();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
beanName, "Validation of method overrides failed", ex);
}
try {
// 讓 InstantiationAwareBeanPostProcessor 在這一步有機會返回代理，
// 在 《Spring AOP 源碼分析》那篇文章中有解釋，這裏先跳過
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
if (bean != null) {
return bean;
}
}
catch (Throwable ex) {
throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
"BeanPostProcessor before instantiation of bean failed", ex);
}
// 重頭戲，建立 bean
Object beanInstance = doCreateBean(beanName, mbdToUse, args);
if (logger.isDebugEnabled()) {
logger.debug("Finished creating instance of bean '" + beanName + "'");
}
return beanInstance;
}
複製代碼
建立 Bean
咱們繼續往裏看 doCreateBean 這個方法：
/**
* Actually create the specified bean. Pre-creation processing has already happened
* at this point, e.g. checking {@code postProcessBeforeInstantiation} callbacks.
* <p>Differentiates between default bean instantiation, use of a
* factory method, and autowiring a constructor.
* @param beanName the name of the bean
* @param mbd the merged bean definition for the bean
* @param args explicit arguments to use for constructor or factory method invocation
* @return a new instance of the bean
* @throws BeanCreationException if the bean could not be created
* @see #instantiateBean
* @see #instantiateUsingFactoryMethod
* @see #autowireConstructor
*/
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
throws BeanCreationException {
// Instantiate the bean.
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 說明不是 FactoryBean，這裏實例化 Bean，這裏很是關鍵，細節以後再說
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
// 這個就是 Bean 裏面的 咱們定義的類 的實例，不少地方我直接描述成 "bean 實例"
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
// 類型
Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
mbd.resolvedTargetType = beanType;
// 建議跳過吧，涉及接口：MergedBeanDefinitionPostProcessor
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
try {
// MergedBeanDefinitionPostProcessor，這個我真不展開說了，直接跳過吧，不多用的
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
}
catch (Throwable ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Post-processing of merged bean definition failed", ex);
}
mbd.postProcessed = true;
}
}
// Eagerly cache singletons to be able to resolve circular references
// even when triggered by lifecycle interfaces like BeanFactoryAware.
// 下面這塊代碼是爲了解決循環依賴的問題，之後有時間，我再對循環依賴這個問題進行解析吧
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isDebugEnabled()) {
logger.debug("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
// Initialize the bean instance.
Object exposedObject = bean;
try {
// 這一步也是很是關鍵的，這一步負責屬性裝配，由於前面的實例只是實例化了，並無設值，這裏就是設值
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
// 還記得 init-method 嗎？還有 InitializingBean 接口？還有 BeanPostProcessor 接口？
// 這裏就是處理 bean 初始化完成後的各類回調
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
catch (Throwable ex) {
if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
throw (BeanCreationException) ex;
}
else {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
}
}
if (earlySingletonExposure) {
//
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
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.");
}
}
}
}
// Register bean as disposable.
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);
}
catch (BeanDefinitionValidationException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
}
return exposedObject;
}
複製代碼
到這裏，咱們已經分析完了 doCreateBean 方法，總的來講，咱們已經說完了整個初始化流程。
接下來咱們挑 doCreateBean 中的三個細節出來講說。一個是建立 Bean 實例的 createBeanInstance 方法，一個是依賴注入的 populateBean 方法，還有就是回調方法 initializeBean。
注意了，接下來的這三個方法要認真說那也是極其複雜的，不少地方我就點到爲止了，感興趣的讀者能夠本身往裏看，最好就是碰到不懂的，本身寫代碼去調試它。
建立 Bean 實例
咱們先看看 createBeanInstance 方法。須要說明的是，這個方法若是每一個分支都分析下去，必然也是極其複雜冗長的，咱們挑重點說。此方法的目的就是實例化咱們指定的類。
protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
// 確保已經加載了此 class
Class<?> beanClass = resolveBeanClass(mbd, beanName);
// 校驗一下這個類的訪問權限
if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
}
if (mbd.getFactoryMethodName() != null) {
// 採用工廠方法實例化，不熟悉這個概念的讀者請看附錄，注意，不是 FactoryBean
return instantiateUsingFactoryMethod(beanName, mbd, args);
}
// 若是不是第一次建立，好比第二次建立 prototype bean。
// 這種狀況下，咱們能夠從第一次建立知道，採用無參構造函數，仍是構造函數依賴注入 來完成實例化
boolean resolved = false;
boolean autowireNecessary = false;
if (args == null) {
synchronized (mbd.constructorArgumentLock) {
if (mbd.resolvedConstructorOrFactoryMethod != null) {
resolved = true;
autowireNecessary = mbd.constructorArgumentsResolved;
}
}
}
if (resolved) {
if (autowireNecessary) {
// 構造函數依賴注入
return autowireConstructor(beanName, mbd, null, null);
}
else {
// 無參構造函數
return instantiateBean(beanName, mbd);
}
}
// 判斷是否採用有參構造函數
Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
if (ctors != null ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) {
// 構造函數依賴注入
return autowireConstructor(beanName, mbd, ctors, args);
}
// 調用無參構造函數
return instantiateBean(beanName, mbd);
}
複製代碼
挑個簡單的無參構造函數構造實例來看看：
protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
try {
Object beanInstance;
final BeanFactory parent = this;
if (System.getSecurityManager() != null) {
beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
return getInstantiationStrategy().instantiate(mbd, beanName, parent);
}
}, getAccessControlContext());
}
else {
// 實例化
beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
}
// 包裝一下，返回
BeanWrapper bw = new BeanWrapperImpl(beanInstance);
initBeanWrapper(bw);
return bw;
}
catch (Throwable ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
}
}
複製代碼
咱們能夠看到，關鍵的地方在於：
beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
複製代碼
這裏會進行實際的實例化過程，咱們進去看看:
// SimpleInstantiationStrategy 59
@Override
public Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {
// 若是不存在方法覆寫，那就使用 java 反射進行實例化，不然使用 CGLIB,
// 方法覆寫 請參見附錄"方法注入"中對 lookup-method 和 replaced-method 的介紹
if (bd.getMethodOverrides().isEmpty()) {
Constructor<?> constructorToUse;
synchronized (bd.constructorArgumentLock) {
constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
if (constructorToUse == null) {
final Class<?> clazz = bd.getBeanClass();
if (clazz.isInterface()) {
throw new BeanInstantiationException(clazz, "Specified class is an interface");
}
try {
if (System.getSecurityManager() != null) {
constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {
@Override
public Constructor<?> run() throws Exception {
return clazz.getDeclaredConstructor((Class[]) null);
}
});
}
else {
constructorToUse = clazz.getDeclaredConstructor((Class[]) null);
}
bd.resolvedConstructorOrFactoryMethod = constructorToUse;
}
catch (Throwable ex) {
throw new BeanInstantiationException(clazz, "No default constructor found", ex);
}
}
}
// 利用構造方法進行實例化
return BeanUtils.instantiateClass(constructorToUse);
}
else {
// 存在方法覆寫，利用 CGLIB 來完成實例化，須要依賴於 CGLIB 生成子類，這裏就不展開了。
// tips: 由於若是不使用 CGLIB 的話，存在 override 的狀況 JDK 並無提供相應的實例化支持
return instantiateWithMethodInjection(bd, beanName, owner);
}
}
複製代碼
到這裏，咱們就算實例化完成了。咱們開始說怎麼進行屬性注入。
bean 屬性注入
看完了 createBeanInstance(...) 方法，咱們來看看 populateBean(...) 方法，該方法負責進行屬性設值，處理依賴。
// AbstractAutowireCapableBeanFactory 1203
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
// bean 實例的全部屬性都在這裏了
PropertyValues pvs = mbd.getPropertyValues();
if (bw == null) {
if (!pvs.isEmpty()) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
}
else {
// Skip property population phase for null instance.
return;
}
}
// 到這步的時候，bean 實例化完成（經過工廠方法或構造方法），可是還沒開始屬性設值，
// InstantiationAwareBeanPostProcessor 的實現類能夠在這裏對 bean 進行狀態修改，
// 我也沒找到有實際的使用，因此咱們暫且忽略這塊吧
boolean continueWithPropertyPopulation = true;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// 若是返回 false，表明不須要進行後續的屬性設值，也不須要再通過其餘的 BeanPostProcessor 的處理
if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
continueWithPropertyPopulation = false;
break;
}
}
}
}
if (!continueWithPropertyPopulation) {
return;
}
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
// 經過名字找到全部屬性值，若是是 bean 依賴，先初始化依賴的 bean。記錄依賴關係
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
autowireByName(beanName, mbd, bw, newPvs);
}
// 經過類型裝配。複雜一些
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
autowireByType(beanName, mbd, bw, newPvs);
}
pvs = newPvs;
}
boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
if (hasInstAwareBpps || needsDepCheck) {
PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
if (hasInstAwareBpps) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// 這裏有個很是有用的 BeanPostProcessor 進到這裏: AutowiredAnnotationBeanPostProcessor
// 對採用 @Autowired、@Value 註解的依賴進行設值，這裏的內容也是很是豐富的，不過本文不會展開說了，感興趣的讀者請自行研究
pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
if (pvs == null) {
return;
}
}
}
}
if (needsDepCheck) {
checkDependencies(beanName, mbd, filteredPds, pvs);
}
}
// 設置 bean 實例的屬性值
applyPropertyValues(beanName, mbd, bw, pvs);
}
複製代碼
initializeBean
屬性注入完成後，這一步其實就是處理各類回調了，這塊代碼比較簡單。
protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
if (System.getSecurityManager() != null) {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
invokeAwareMethods(beanName, bean);
return null;
}
}, getAccessControlContext());
}
else {
// 若是 bean 實現了 BeanNameAware、BeanClassLoaderAware 或 BeanFactoryAware 接口，回調
invokeAwareMethods(beanName, bean);
}
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
// BeanPostProcessor 的 postProcessBeforeInitialization 回調
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try {
// 處理 bean 中定義的 init-method，
// 或者若是 bean 實現了 InitializingBean 接口，調用 afterPropertiesSet() 方法
invokeInitMethods(beanName, wrappedBean, mbd);
}
catch (Throwable ex) {
throw new BeanCreationException(
(mbd != null ? mbd.getResourceDescription() : null),
beanName, "Invocation of init method failed", ex);
}
if (mbd == null || !mbd.isSynthetic()) {
// BeanPostProcessor 的 postProcessAfterInitialization 回調
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
}
複製代碼
你們發現沒有，BeanPostProcessor 的兩個回調都發生在這邊，只不過中間處理了 init-method，是否是和讀者原來的認知有點不同了？
附錄
id 和 name
每一個 Bean 在 Spring 容器中都有一個惟一的名字（beanName）和 0 個或多個別名（aliases）。
咱們從 Spring 容器中獲取 Bean 的時候，能夠根據 beanName，也能夠經過別名。
beanFactory.getBean("beanName or alias");
複製代碼
在配置 <bean /> 的過程當中，咱們能夠配置 id 和 name，看幾個例子就知道是怎麼回事了。
<bean id="messageService" name="m1, m2, m3" class="com.javadoop.example.MessageServiceImpl">
複製代碼
以上配置的結果就是：beanName 爲 messageService，別名有 3 個，分別爲 m一、m二、m3。
<bean name="m1, m2, m3" class="com.javadoop.example.MessageServiceImpl" />
複製代碼
以上配置的結果就是：beanName 爲 m1，別名有 2 個，分別爲 m二、m3。
<bean class="com.javadoop.example.MessageServiceImpl">
複製代碼
beanName 爲：com.javadoop.example.MessageServiceImpl#0，
別名 1 個，爲： com.javadoop.example.MessageServiceImpl
<bean id="messageService" class="com.javadoop.example.MessageServiceImpl">
複製代碼
以上配置的結果就是：beanName 爲 messageService，沒有別名。
配置是否容許 Bean 覆蓋、是否容許循環依賴
咱們說過，默認狀況下，allowBeanDefinitionOverriding 屬性爲 null。若是在同一配置文件中 Bean id 或 name 重複了，會拋錯，可是若是不是同一配置文件中，會發生覆蓋。
但是有些時候咱們但願在系統啓動的過程當中就嚴格杜絕發生 Bean 覆蓋，由於萬一出現這種狀況，會增長咱們排查問題的成本。
循環依賴說的是 A 依賴 B，而 B 又依賴 A。或者是 A 依賴 B，B 依賴 C，而 C 卻依賴 A。默認 allowCircularReferences 也是 null。
它們兩個屬性是一塊兒出現的，必然能夠在同一個地方一塊兒進行配置。
添加這兩個屬性的做者 Juergen Hoeller 在這個 jira 的討論中說明了怎麼配置這兩個屬性。
public class NoBeanOverridingContextLoader extends ContextLoader {
@Override
protected void customizeContext(ServletContext servletContext, ConfigurableWebApplicationContext applicationContext) {
super.customizeContext(servletContext, applicationContext);
AbstractRefreshableApplicationContext arac = (AbstractRefreshableApplicationContext) applicationContext;
arac.setAllowBeanDefinitionOverriding(false);
}
}
複製代碼
public class MyContextLoaderListener extends org.springframework.web.context.ContextLoaderListener {
@Override
protected ContextLoader createContextLoader() {
return new NoBeanOverridingContextLoader();
}
}
複製代碼
<listener>
<listener-class>com.javadoop.MyContextLoaderListener</listener-class>
</listener>
複製代碼
若是以上方式不能知足你的需求，請參考這個連接：解決spring中不一樣配置文件中存在name或者id相同的bean可能引發的問題
profile
咱們能夠把不一樣環境的配置分別配置到單獨的文件中，舉個例子：
<beans profile="development"
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xsi:schemaLocation="...">
<jdbc:embedded-database id="dataSource">
<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
</jdbc:embedded-database>
</beans>
複製代碼
<beans profile="production"
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="...">
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
複製代碼
應該沒必要作過多解釋了吧，看每一個文件第一行的 profile=""。
固然，咱們也能夠在一個配置文件中使用：
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="...">
<beans profile="development">
<jdbc:embedded-database id="dataSource">
<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
</jdbc:embedded-database>
</beans>
<beans profile="production">
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
</beans>
複製代碼
理解起來也很簡單吧。
接下來的問題是，怎麼使用特定的 profile 呢？Spring 在啓動的過程當中，會去尋找 「spring.profiles.active」 的屬性值，根據這個屬性值來的。那怎麼配置這個值呢？
Spring 會在這幾個地方尋找 spring.profiles.active 的屬性值：操做系統環境變量、JVM 系統變量、web.xml 中定義的參數、JNDI。
最簡單的方式莫過於在程序啓動的時候指定：
-Dspring.profiles.active="profile1,profile2"
複製代碼
profile 能夠激活多個
固然，咱們也能夠經過代碼的形式從 Environment 中設置 profile：
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("development");
ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
ctx.refresh(); // 重啓
複製代碼
若是是 Spring Boot 的話更簡單，咱們通常會建立 application.properties、application-dev.properties、application-prod.properties 等文件，其中 application.properties 配置各個環境通用的配置，application-{profile}.properties 中配置特定環境的配置，而後在啓動的時候指定 profile：
java -Dspring.profiles.active=prod -jar JavaDoop.jar
複製代碼
若是是單元測試中使用的話，在測試類中使用 @ActiveProfiles 指定，這裏就不展開了。
工廠模式生成 Bean
請讀者注意 factory-bean 和 FactoryBean 的區別。這節說的是前者，是說靜態工廠或實例工廠，然後者是 Spring 中的特殊接口，表明一類特殊的 Bean，附錄的下面一節會介紹 FactoryBean。
設計模式裏，工廠方法模式分靜態工廠和實例工廠，咱們分別看看 Spring 中怎麼配置這兩個，來個代碼示例就什麼都清楚了。
靜態工廠：
<bean id="clientService"
class="examples.ClientService"
factory-method="createInstance"/>
複製代碼
public class ClientService {
private static ClientService clientService = new ClientService();
private ClientService() {}
// 靜態方法
public static ClientService createInstance() {
return clientService;
}
}
複製代碼
實例工廠：
<bean id="serviceLocator" class="examples.DefaultServiceLocator">
<!-- inject any dependencies required by this locator bean -->
</bean>
<bean id="clientService"
factory-bean="serviceLocator"
factory-method="createClientServiceInstance"/>
<bean id="accountService"
factory-bean="serviceLocator"
factory-method="createAccountServiceInstance"/>
複製代碼
public class DefaultServiceLocator {
private static ClientService clientService = new ClientServiceImpl();
private static AccountService accountService = new AccountServiceImpl();
public ClientService createClientServiceInstance() {
return clientService;
}
public AccountService createAccountServiceInstance() {
return accountService;
}
}
複製代碼
FactoryBean
FactoryBean 適用於 Bean 的建立過程比較複雜的場景，好比數據庫鏈接池的建立。
public interface FactoryBean<T> {
T getObject() throws Exception;
Class<T> getObjectType();
boolean isSingleton();
}
複製代碼
public class Person {
private Car car ;
private void setCar(Car car){ this.car = car; }
}
複製代碼
咱們假設如今須要建立一個 Person 的 Bean，首先咱們須要一個 Car 的實例，咱們這裏假設 Car 的實例建立很麻煩，那麼咱們能夠把建立 Car 的複雜過程包裝起來：
public class MyCarFactoryBean implements FactoryBean<Car>{
private String make;
private int year ;
public void setMake(String m){ this.make =m ; }
public void setYear(int y){ this.year = y; }
public Car getObject(){
// 這裏咱們假設 Car 的實例化過程很是複雜，反正就不是幾行代碼能夠寫完的那種
CarBuilder cb = CarBuilder.car();
if(year!=0) cb.setYear(this.year);
if(StringUtils.hasText(this.make)) cb.setMake( this.make );
return cb.factory();
}
public Class<Car> getObjectType() { return Car.class ; }
public boolean isSingleton() { return false; }
}
複製代碼
咱們看看裝配的時候是怎麼配置的：
<bean class = "com.javadoop.MyCarFactoryBean" id = "car">
<property name = "make" value ="Honda"/>
<property name = "year" value ="1984"/>
</bean>
<bean class = "com.javadoop.Person" id = "josh">
<property name = "car" ref = "car"/>
</bean>
複製代碼
看到不同了嗎？id 爲 「car」 的 bean 其實指定的是一個 FactoryBean，不過配置的時候，咱們直接讓配置 Person 的 Bean 直接依賴於這個 FactoryBean 就能夠了。中間的過程 Spring 已經封裝好了。
說到這裏，咱們再來點乾貨。咱們知道，如今還用 xml 配置 Bean 依賴的愈來愈少了，更多時候，咱們可能會採用 java config 的方式來配置，這裏有什麼不同呢？
@Configuration
public class CarConfiguration {
@Bean
public MyCarFactoryBean carFactoryBean(){
MyCarFactoryBean cfb = new MyCarFactoryBean();
cfb.setMake("Honda");
cfb.setYear(1984);
return cfb;
}
@Bean
public Person aPerson(){
Person person = new Person();
// 注意這裏的不一樣
person.setCar(carFactoryBean().getObject());
return person;
}
}
複製代碼
這個時候，其實咱們的思路也很簡單，把 MyCarFactoryBean 當作是一個簡單的 Bean 就能夠了，沒必要理會什麼 FactoryBean，它是否是 FactoryBean 和咱們不要緊。
初始化 Bean 的回調
有如下四種方案：
<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>
複製代碼
public class AnotherExampleBean implements InitializingBean {
public void afterPropertiesSet() {
// do some initialization work
}
}
複製代碼
@Bean(initMethod = "init")
public Foo foo() {
return new Foo();
}
複製代碼
@PostConstruct
public void init() {
}
複製代碼
銷燬 Bean 的回調
<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>
複製代碼
public class AnotherExampleBean implements DisposableBean {
public void destroy() {
// do some destruction work (like releasing pooled connections)
}
}
複製代碼
@Bean(destroyMethod = "cleanup")
public Bar bar() {
return new Bar();
}
複製代碼
@PreDestroy
public void cleanup() {
}
複製代碼
ConversionService
既然文中說到了這個，順便提一下好了。
最有用的場景就是，它用來將前端傳過來的參數和後端的 controller 方法上的參數進行綁定的時候用。
像前端傳過來的字符串、整數要轉換爲後端的 String、Integer 很容易，可是若是 controller 方法須要的是一個枚舉值，或者是 Date 這些非基礎類型（含基礎類型包裝類）值的時候，咱們就能夠考慮採用 ConversionService 來進行轉換。
<bean id="conversionService"
class="org.springframework.context.support.ConversionServiceFactoryBean">
<property name="converters">
<list>
<bean class="com.javadoop.learning.utils.StringToEnumConverterFactory"/>
</list>
</property>
</bean>
複製代碼
ConversionService 接口很簡單，因此要自定義一個 convert 的話也很簡單。
下面再說一個實現這種轉換很簡單的方式，那就是實現 Converter 接口。
來看一個很簡單的例子，這樣比什麼都管用。
public class StringToDateConverter implements Converter<String, Date> {
@Override
public Date convert(String source) {
try {
return DateUtils.parseDate(source, "yyyy-MM-dd", "yyyy-MM-dd HH:mm:ss", "yyyy-MM-dd HH:mm", "HH:mm:ss", "HH:mm");
} catch (ParseException e) {
return null;
}
}
}
複製代碼
只要註冊這個 Bean 就能夠了。這樣，前端日後端傳的時間描述字符串就很容易綁定成 Date 類型了，不須要其餘任何操做。
Bean 繼承
在初始化 Bean 的地方，咱們說過了這個：
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
複製代碼
這裏涉及到的就是 <bean parent="" /> 中的 parent 屬性，咱們來看看 Spring 中是用這個來幹什麼的。
首先，咱們要明白，這裏的繼承和 java 語法中的繼承沒有任何關係，不過思路是相通的。child bean 會繼承 parent bean 的全部配置，也能夠覆蓋一些配置，固然也能夠新增額外的配置。
Spring 中提供了繼承自 AbstractBeanDefinition 的 ChildBeanDefinition 來表示 child bean。
看以下一個例子:
<bean id="inheritedTestBean" abstract="true" class="org.springframework.beans.TestBean">
<property name="name" value="parent"/>
<property name="age" value="1"/>
</bean>
<bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean"
parent="inheritedTestBean" init-method="initialize">
<property name="name" value="override"/>
</bean>
複製代碼
parent bean 設置了 abstract="true" 因此它不會被實例化，child bean 繼承了 parent bean 的兩個屬性，可是對 name 屬性進行了覆寫。
child bean 會繼承 scope、構造器參數值、屬性值、init-method、destroy-method 等等。
固然，我不是說 parent bean 中的 abstract = true 在這裏是必須的，只是說若是加上了之後 Spring 在實例化 singleton beans 的時候會忽略這個 bean。
好比下面這個極端 parent bean，它沒有指定 class，因此毫無疑問，這個 bean 的做用就是用來充當模板用的 parent bean，此處就必須加上 abstract = true。
<bean id="inheritedTestBeanWithoutClass" abstract="true">
<property name="name" value="parent"/>
<property name="age" value="1"/>
</bean>
複製代碼
方法注入
通常來講，咱們的應用中大多數的 Bean 都是 singleton 的。singleton 依賴 singleton，或者 prototype 依賴 prototype 都很好解決，直接設置屬性依賴就能夠了。
可是，若是是 singleton 依賴 prototype 呢？這個時候不能用屬性依賴，由於若是用屬性依賴的話，咱們每次其實拿到的仍是第一次初始化時候的 bean。
一種解決方案就是不要用屬性依賴，每次獲取依賴的 bean 的時候從 BeanFactory 中取。這個也是你們最經常使用的方式了吧。怎麼取，我就不介紹了，大部分 Spring 項目你們都會定義那麼個工具類的。
另外一種解決方案就是這裏要介紹的經過使用 Lookup method。
lookup-method
咱們來看一下 Spring Reference 中提供的一個例子：
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
複製代碼
xml 配置 <lookup-method />：
<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
<!-- inject dependencies here as required -->
</bean>
<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
<lookup-method name="createCommand" bean="myCommand"/>
</bean>
複製代碼
Spring 採用 CGLIB 生成字節碼的方式來生成一個子類。咱們定義的類不能定義爲 final class，抽象方法上也不能加 final。
lookup-method 上的配置也能夠採用註解來完成，這樣就能夠不用配置 <lookup-method /> 了，其餘不變：
public abstract class CommandManager {
public Object process(Object commandState) {
MyCommand command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup("myCommand")
protected abstract Command createCommand();
}
複製代碼
注意，既然用了註解，要配置註解掃描：
<context:component-scan base-package="com.javadoop" />
甚至，咱們能夠像下面這樣：
public abstract class CommandManager {
public Object process(Object commandState) {
MyCommand command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup
protected abstract MyCommand createCommand();
}
複製代碼
上面的返回值用了 MyCommand，固然，若是 Command 只有一個實現類，那返回值也能夠寫 Command。
replaced-method
記住它的功能，就是替換掉 bean 中的一些方法。
public class MyValueCalculator {
public String computeValue(String input) {
// some real code...
}
// some other methods...
}
複製代碼
方法覆寫，注意要實現 MethodReplacer 接口：
public class ReplacementComputeValue implements org.springframework.beans.factory.support.MethodReplacer {
public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
// get the input value, work with it, and return a computed result
String input = (String) args[0];
...
return ...;
}
}
複製代碼
配置也很簡單：
<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
<!-- 定義 computeValue 這個方法要被替換掉 -->
<replaced-method name="computeValue" replacer="replacementComputeValue">
<arg-type>String</arg-type>
</replaced-method>
</bean>
<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>
複製代碼
arg-type 明顯不是必須的，除非存在方法重載，這樣必須經過參數類型列表來判斷這裏要覆蓋哪一個方法。
BeanPostProcessor
應該說 BeanPostProcessor 概念在 Spring 中也是比較重要的。咱們看下接口定義：
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
複製代碼
看這個接口中的兩個方法名字咱們大致上能夠猜想 bean 在初始化以前會執行 postProcessBeforeInitialization 這個方法，初始化完成以後會執行 postProcessAfterInitialization 這個方法。可是，這麼理解是很是片面的。
首先，咱們要明白，除了咱們本身定義的 BeanPostProcessor 實現外，Spring 容器在啓動時自動給咱們也加了幾個。如在獲取 BeanFactory 的 obtainFactory() 方法結束後的 prepareBeanFactory(factory)，你們仔細看會發現，Spring 往容器中添加了這兩個 BeanPostProcessor：ApplicationContextAwareProcessor、ApplicationListenerDetector。
咱們回到這個接口自己，讀者請看第一個方法，這個方法接受的第一個參數是 bean 實例，第二個參數是 bean 的名字，重點在返回值將會做爲新的 bean 實例，因此，沒事的話這裏不能隨便返回個 null。
那意味着什麼呢？咱們很容易想到的就是，咱們這裏能夠對一些咱們想要修飾的 bean 實例作一些事情。可是對於 Spring 框架來講，它會決定是否是要在這個方法中返回 bean 實例的代理，這樣就有更大的想象空間了。
最後，咱們說說若是咱們本身定義一個 bean 實現 BeanPostProcessor 的話，它的執行時機是何時？
若是仔細看了代碼分析的話，其實很容易知道了，在 bean 實例化完成、屬性注入完成以後，會執行回調方法，具體請參見類 AbstractAutowireCapableBeanFactory#initBean 方法。
首先會回調幾個實現了 Aware 接口的 bean，而後就開始回調 BeanPostProcessor 的 postProcessBeforeInitialization 方法，以後是回調 init-method，而後再回調 BeanPostProcessor 的 postProcessAfterInitialization 方法。
總結
按理說，總結應該寫在附錄前面，我就不講究了。
在花了那麼多時間後，這篇文章終於算是基本寫完了，你們在驚歎 Spring 給咱們作了那麼多的事的時候，應該透過現象看本質，去理解 Spring 寫得好的地方，去理解它的設計思想。
本文的缺陷在於對 Spring 預初始化 singleton beans 的過程分析不夠，主要是代碼量真的比較大，分支旁路衆多。同時，雖然附錄條目很多，可是龐大的 Spring 真的引出了不少的概念，但願往後有精力能夠慢慢補充一些。
（全文完）
相關文章
- 1. Spring 源碼分析（二）之 Spring IOC 容器源碼分析
- 2. 最簡 Spring IOC 容器源碼分析
- 3. Spring IOC 容器源碼分析
- 4. 一 spring源碼分析--- IOC容器
- 5. 轉載-Spring IOC 容器源碼分析
- 6. Spring IOC 容器源碼分析圖解
- 7. Spring源碼閱讀-IOC 容器解析
- 8. Spring源碼閱讀-IoC容器解析
- 9. Spring源碼-IOC容器(十)-@Autowired解析
- 10. spring源碼解析之IOC容器（一）
- 更多相關文章...
- • Spring IoC容器：BeanFactory和ApplicationContext - Spring教程
- • XML DOM 解析器 - XML DOM 教程
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • Docker容器實戰(六) - 容器的隔離與限制
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. Duang!超快Wi-Fi來襲
- 2. 機器學習-補充03 神經網絡之**函數(Activation Function)
- 3. git上開源maven項目部署 多module maven項目（多module maven+redis+tomcat+mysql）後臺部署流程學習記錄
- 4. ecliple-tomcat部署maven項目方式之一
- 5. eclipse新導入的項目經常可以看到「XX cannot be resolved to a type」的報錯信息
- 6. Spark RDD的依賴於DAG的工作原理
- 7. VMware安裝CentOS-8教程詳解
- 8. YDOOK：Java 項目 Spring 項目導入基本四大 jar 包 導入依賴，怎樣在 IDEA 的項目結構中導入 jar 包 導入依賴
- 9. 簡單方法使得putty（windows10上）可以免密登錄樹莓派
- 10. idea怎麼用本地maven
歡迎關注本站公眾號,獲取更多信息
