摘要：本文是容器源碼分析系列文章的第一篇文章，將會(huì)著重介紹的一些使用方法和特性，為后續(xù)的源碼分析文章做鋪墊。我們可以通過這兩個(gè)別名獲取到這個(gè)實(shí)例，比如下面的測(cè)試代碼測(cè)試結(jié)果如下本小節(jié)，我們來了解一下這個(gè)特性。

Spring 是一個(gè)輕量級(jí)的企業(yè)級(jí)應(yīng)用開發(fā)框架，于 2004 年由 Rod Johnson 發(fā)布了 1.0 版本。經(jīng)過十幾年的迭代，現(xiàn)在的 Spring 框架已經(jīng)非常成熟了。Spring 包含了眾多模塊，包括但不限于 Core、Bean、Context、AOP 和 Web 等。在今天，我們完全可以使用 Spring 所提供的一站式解決方案開發(fā)出我們所需要的應(yīng)用。作為 Java 程序員，我們會(huì)經(jīng)常和 Spring 框架打交道，所以還是很有必要弄懂 Spring 的原理。

本文是 Spring IOC 容器源碼分析系列文章的第一篇文章，將會(huì)著重介紹 Spring 的一些使用方法和特性，為后續(xù)的源碼分析文章做鋪墊。另外需要特別說明一下，本系列的源碼分析文章是基于Spring 4.3.17.RELEASE版本編寫的，而非最新的5.0.6.RELEASE版本。好了，關(guān)于簡(jiǎn)介先說到這里，繼續(xù)來說說下面的內(nèi)容。

寫 Spring IOC 這一塊的文章，挺讓我糾結(jié)的。我原本是打算在一篇文章中分析所有的源碼，但是后來發(fā)現(xiàn)文章實(shí)在太長(zhǎng)。主要是因?yàn)?Spring IOC 部分的源碼實(shí)在太長(zhǎng)，將這一部分的源碼貼在一篇文章中還是很壯觀的。當(dāng)然估計(jì)大家也沒興趣讀下去，所以決定對(duì)文章進(jìn)行拆分。這里先貼一張文章切分前的目錄結(jié)構(gòu)：

如上圖，由目錄可以看出，假使在一篇文章中寫完所有內(nèi)容，文章的長(zhǎng)度將會(huì)非常長(zhǎng)。所以在經(jīng)過思考后，我會(huì)將文章拆分成一系列的文章，如下：

Spring IOC 容器源碼分析 - 獲取單例 bean - ?已更新

Spring IOC 容器源碼分析 - 創(chuàng)建單例 bean 的過程 - ?已更新

Spring IOC 容器源碼分析 - 創(chuàng)建原始 bean 對(duì)象 - ? 已更新

Spring IOC 容器源碼分析 - 循環(huán)依賴的解決辦法 - ? 已更新

Spring IOC 容器源碼分析 - 填充屬性到原始 bean 對(duì)象中 - ? 已更新

Spring IOC 容器源碼分析 - 余下的初始化工作 - ? 已更新

上面文章對(duì)應(yīng)的源碼分析工作均已經(jīng)完成，所有的文章將會(huì)在近期內(nèi)進(jìn)行更新。

Spring 是分模塊開發(fā)的，Spring 包含了很多模塊，其中最為核心的是 bean 容器相關(guān)模塊。像 AOP、MVC、Data 等模塊都要依賴 bean 容器。這里先看一下 Spring 框架的結(jié)構(gòu)圖：

圖片來源：Spring 官方文檔

從上圖中可以看出Core Container處于整個(gè)框架的最底層（忽略 Test 模塊），在其之上有 AOP、Data、Web 等模塊。既然 Spring 容器是最核心的部分，那么大家如果要讀 Spring 的源碼，容器部分必須先弄懂。本篇文章作為 Spring IOC 容器的開篇文章，就來簡(jiǎn)單介紹一下容器方面的知識(shí)。請(qǐng)繼續(xù)往下看。

本章將會(huì)介紹 IOC 中的部分特性，這些特性均會(huì)在后面的源碼分析中悉數(shù)到場(chǎng)。如果大家不是很熟悉這些特性，這里可以看一下。

alias 的中文意思是“別名”，在 Spring 中，我們可以使用 alias 標(biāo)簽給 bean 起個(gè)別名。比如下面的配置：

這里我們給hello這個(gè) beanName 起了一個(gè)別名alias-hello，然后又給別名alias-hello起了一個(gè)別名double-alias-hello。我們可以通過這兩個(gè)別名獲取到hello這個(gè) bean 實(shí)例，比如下面的測(cè)試代碼：

public class ApplicationContextTest {

    @Test
    public void testAlias() {
        String configLocation = "application-alias.xml";
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
        System.out.println("    alias-hello -> " + applicationContext.getBean("alias-hello"));
        System.out.println("double-alias-hello -> " + applicationContext.getBean("double-alias-hello"));
    }
}

測(cè)試結(jié)果如下：

本小節(jié)，我們來了解一下 autowire 這個(gè)特性。autowire 即自動(dòng)注入的意思，通過使用 autowire 特性，我們就不用再顯示的配置 bean 之間的依賴了。把依賴的發(fā)現(xiàn)和注入都交給 Spring 去處理，省時(shí)又省力。autowire 幾個(gè)可選項(xiàng)，比如 byName、byType 和 constructor 等。autowire 是一個(gè)常用特性，相信大家都比較熟悉了，所以本節(jié)我們就 byName 為例，快速結(jié)束 autowire 特性的介紹。

當(dāng) bean 配置中的 autowire = byName 時(shí)，Spring 會(huì)首先通過反射獲取該 bean 所依賴 bean 的名字（beanName），然后再通過調(diào)用 BeanFactory.getName(beanName) 方法即可獲取對(duì)應(yīng)的依賴實(shí)例。autowire = byName 原理大致就是這樣，接下來我們來演示一下。

public class Service {

    private Dao mysqlDao;

    private Dao mongoDao;

    // 忽略 getter/setter

    @Override
    public String toString() {
        return super.toString() + "
					{" +
            "mysqlDao=" + mysqlDao +
            ", mongoDao=" + mongoDao +
            "}";
    }
}

public interface Dao {}
public class MySqlDao implements Dao {}
public class MongoDao implements Dao {}

配置如下：

測(cè)試代碼如下：

String configLocation = "application-autowire.xml";
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
System.out.println("service-without-autowire -> " + applicationContext.getBean("service-without-autowire"));
System.out.println("service-with-autowire -> " + applicationContext.getBean("service-with-autowire"));

測(cè)試結(jié)果如下：

從測(cè)試結(jié)果可以看出，兩種方式配置方式都能完成解決 bean 之間的依賴問題。只不過使用 autowire 會(huì)更加省力一些，配置文件也不會(huì)冗長(zhǎng)。這里舉的例子比較簡(jiǎn)單，假使一個(gè) bean 依賴了十幾二十個(gè) bean，再手動(dòng)去配置，恐怕就很難受了。

FactoryBean？看起來是不是很像 BeanFactory 孿生兄弟。不錯(cuò)，他們看起來很像，但是他們是不一樣的。FactoryBean 是一種工廠 bean，與普通的 bean 不一樣，F(xiàn)actoryBean 是一種可以產(chǎn)生 bean 的 bean，好吧說起來很繞嘴。FactoryBean 是一個(gè)接口，我們可以實(shí)現(xiàn)這個(gè)接口。下面演示一下：

public class HelloFactoryBean implements FactoryBean {

    @Override
    public Hello getObject() throws Exception {
        Hello hello = new Hello();
        hello.setContent("hello");
        return hello;
    }

    @Override
    public Class getObjectType() {
        return Hello.class;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }
}

配置如下：

測(cè)試代碼如下：

public class ApplicationContextTest {

    @Test
    public void testFactoryBean() {
        String configLocation = "application-factory-bean.xml";
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
        System.out.println("helloFactory -> " + applicationContext.getBean("helloFactory"));
        System.out.println("&helloFactory -> " + applicationContext.getBean("&helloFactory"));
    }
}

測(cè)試結(jié)果如下：

由測(cè)試結(jié)果可以看到，當(dāng)我們調(diào)用 getBean("helloFactory") 時(shí)，ApplicationContext 會(huì)返回一個(gè) Hello 對(duì)象，該對(duì)象是 HelloFactoryBean 的 getObject 方法所創(chuàng)建的。如果我們想獲取 HelloFactoryBean 本身，則可以在 helloFactory 前加上一個(gè)前綴&，即&helloFactory。

介紹完 FactoryBean，本節(jié)再來看看了一個(gè)和工廠相關(guān)的特性 -- factory-method。factory-method 可用于標(biāo)識(shí)靜態(tài)工廠的工廠方法（工廠方法是靜態(tài)的），直接舉例說明吧：

public class StaticHelloFactory {

    public static Hello getHello() {
        Hello hello = new Hello();
        hello.setContent("created by StaticHelloFactory");
        return hello;
    }
}

配置如下：

測(cè)試代碼如下：

public class ApplicationContextTest {

    @Test
    public void testFactoryMethod() {
        String configLocation = "application-factory-method.xml";
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
        System.out.println("staticHelloFactory -> " + applicationContext.getBean("staticHelloFactory"));
    }
}

測(cè)試結(jié)果如下：

對(duì)于非靜態(tài)工廠，需要使用 factory-bean 和 factory-method 兩個(gè)屬性配合。關(guān)于 factory-bean 這里就不繼續(xù)說了，留給大家自己去探索吧。

lookup-method 特性可能大家用的不多（我也沒用過），不過它也是個(gè)有用的特性。在介紹這個(gè)特性前，先介紹一下背景。我們通過 BeanFactory getBean 方法獲取 bean 實(shí)例時(shí)，對(duì)于 singleton 類型的 bean，BeanFactory 每次返回的都是同一個(gè) bean。對(duì)于 prototype 類型的 bean，BeanFactory 則會(huì)返回一個(gè)新的 bean。現(xiàn)在考慮這樣一種情況，一個(gè) singleton 類型的 bean 中有一個(gè) prototype 類型的成員變量。BeanFactory 在實(shí)例化 singleton 類型的 bean 時(shí)，會(huì)向其注入一個(gè) prototype 類型的實(shí)例。但是 singleton 類型的 bean 只會(huì)實(shí)例化一次，那么它內(nèi)部的 prototype 類型的成員變量也就不會(huì)再被改變。但如果我們每次從 singleton bean 中獲取這個(gè) prototype 成員變量時(shí)，都想獲取一個(gè)新的對(duì)象。這個(gè)時(shí)候怎么辦？舉個(gè)例子（該例子源于《Spring 揭秘》一書），我們有一個(gè)新聞提供類（NewsProvider），這個(gè)類中有一個(gè)新聞?lì)悾∟ews）成員變量。我們每次調(diào)用 getNews 方法都想獲取一條新的新聞。這里我們有兩種方式實(shí)現(xiàn)這個(gè)需求，一種方式是讓 NewsProvider 類實(shí)現(xiàn) ApplicationContextAware 接口（實(shí)現(xiàn) BeanFactoryAware 接口也是可以的），每次調(diào)用 NewsProvider 的 getNews 方法時(shí)，都從 ApplicationContext 中獲取一個(gè)新的 News 實(shí)例，返回給調(diào)用者。第二種方式就是這里的 lookup-method 了，Spring 會(huì)在運(yùn)行時(shí)對(duì) NewsProvider 進(jìn)行增強(qiáng)，使其 getNews 可以每次都返回一個(gè)新的實(shí)例。說完了背景和解決方案，接下來就來寫點(diǎn)測(cè)試代碼驗(yàn)證一下。

在演示兩種處理方式前，我們先來看看不使用任何處理方式，BeanFactory 所返回的 bean 實(shí)例情況。相關(guān)類定義如下：

public class News {
    // 僅演示使用，News 類中無成員變量
}

public class NewsProvider {

    private News news;

    public News getNews() {
        return news;
    }

    public void setNews(News news) {
        this.news = news;
    }
}

配置信息如下：

測(cè)試代碼如下：

String configLocation = "application-lookup-method.xml";
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
NewsProvider newsProvider = (NewsProvider) applicationContext.getBean("newsProvider");
System.out.println(newsProvider.getNews());
System.out.println(newsProvider.getNews());

測(cè)試結(jié)果如下：

從測(cè)試結(jié)果中可以看出，newsProvider.getNews() 方法兩次返回的結(jié)果都是一樣的，這個(gè)是不滿足要求的。

我們讓 NewsProvider 實(shí)現(xiàn) ApplicationContextAware 接口，實(shí)現(xiàn)代碼如下：

public class NewsProvider implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    private News news;

    /** 每次都從 applicationContext 中獲取一個(gè)新的 bean */
    public News getNews() {
        return applicationContext.getBean("news", News.class);
    }

    public void setNews(News news) {
        this.news = news;
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

配置和測(cè)試代碼同上，測(cè)試結(jié)果如下：

這里兩次獲取的 news 并就不是同一個(gè) bean 了，滿足了我們的需求。

使用 lookup-method 特性，配置文件需要改一下。如下：

NewsProvider 的代碼沿用 4.5.1 小節(jié)之前貼的代碼。測(cè)試代碼稍微變一下，如下：

String configLocation = "application-lookup-method.xml";
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
NewsProvider newsProvider = (NewsProvider) applicationContext.getBean("newsProvider");
System.out.println("newsProvider -> " + newsProvider);
System.out.println("news 1 -> " + newsProvider.getNews());
System.out.println("news 2 -> " + newsProvider.getNews());

測(cè)試結(jié)果如下：

從上面的結(jié)果可以看出，new1 和 new2 指向了不同的對(duì)象。同時(shí)，大家注意看 newsProvider，似乎變的很復(fù)雜。由此可看出，NewsProvider 被 CGLIB 增強(qiáng)了。

當(dāng)一個(gè) bean 直接依賴另一個(gè) bean，可以使用 標(biāo)簽進(jìn)行配置。不過如某個(gè) bean 并不直接依賴于 其他 bean，但又需要其他 bean 先實(shí)例化好，這個(gè)時(shí)候就需要使用 depends-on 特性了。depends-on 特性比較簡(jiǎn)單，就不演示了。僅貼一下配置文件的內(nèi)容，如下：

這里有兩個(gè)簡(jiǎn)單的類，其中 Hello 需要 World 在其之前完成實(shí)例化。相關(guān)配置如下：

BeanPostProcessor 是 bean 實(shí)例化時(shí)的后置處理器，包含兩個(gè)方法，其源碼如下：

public interface BeanPostProcessor {
    // bean 初始化前的回調(diào)方法
    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;

    // bean 初始化后的回調(diào)方法    
    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;

}

BeanPostProcessor 是 Spring 框架的一個(gè)擴(kuò)展點(diǎn)，通過實(shí)現(xiàn) BeanPostProcessor 接口，我們就可插手 bean 實(shí)例化的過程。比如大家熟悉的 AOP 就是在 bean 實(shí)例后期間將切面邏輯織入 bean 實(shí)例中的，AOP 也正是通過 BeanPostProcessor 和 IOC 容器建立起了聯(lián)系。這里我來演示一下 BeanPostProcessor 的使用方式，如下：

/**
 * 日志后置處理器，將會(huì)在 bean 創(chuàng)建前、后打印日志
 */
public class LoggerBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("Before " + beanName + " Initialization");
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("After " + beanName + " Initialization");
        return bean;
    }
}

配置如下：

測(cè)試代碼如下：

public class ApplicationContextTest {

    @Test
    public void testBeanPostProcessor() {
        String configLocation = "application-bean-post-processor.xml";
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext(configLocation);
    }
}

測(cè)試結(jié)果如下：

與 BeanPostProcessor 類似的還有一個(gè)叫 BeanFactoryPostProcessor 拓展點(diǎn)，顧名思義，用戶可以通過這個(gè)拓展點(diǎn)插手容器啟動(dòng)的過程。不過這個(gè)不屬于本系列文章范疇，暫時(shí)先不細(xì)說了。

Spring 中定義了一些列的 Aware 接口，比如這里的 BeanFactoryAware，以及 BeanNameAware 和 BeanClassLoaderAware 等等。通過實(shí)現(xiàn)這些 Aware 接口，我們可以在運(yùn)行時(shí)獲取一些配置信息或者其他一些信息。比如實(shí)現(xiàn) BeanNameAware 接口，我們可以獲取 bean 的配置名稱（beanName）。通過實(shí)現(xiàn) BeanFactoryAware 接口，我們可以在運(yùn)行時(shí)獲取 BeanFactory 實(shí)例。關(guān)于 Aware 類型接口的使用，可以參考4.5.1 實(shí)現(xiàn) ApplicationContextAware 接口一節(jié)中的敘述，這里就不演示了。

我在去年八月份的時(shí)候，嘗試過閱讀 Spring 源碼。不過 Spring 源碼太多了，調(diào)用復(fù)雜，看著看著就迷失在了代碼的海洋里。不過好在當(dāng)時(shí)找到了一個(gè)經(jīng)過簡(jiǎn)化后的類 Spring 框架，該框架黃億華前輩在學(xué)習(xí) Spring 源碼時(shí)所寫的 tiny-spring。如果大家覺得看 Spring 源碼比較困難，可以先學(xué)習(xí)一下 tiny-spring 的源碼，先對(duì) Spring 代碼結(jié)構(gòu)有個(gè)大概的了解。

另外也建議大家自己動(dòng)手實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 IOC 容器，通過實(shí)踐，才會(huì)有更多的感悟。我在去年八月份的時(shí)候，實(shí)現(xiàn)過一個(gè)簡(jiǎn)單的 IOC 和 AOP（可以參考我去年發(fā)的文章：仿照 Spring 實(shí)現(xiàn)簡(jiǎn)單的 IOC 和 AOP - 上篇），并在最后將兩者整合到了一起。正是有了之前的實(shí)踐，才使得我對(duì) Spring 的原理有了更進(jìn)一步的認(rèn)識(shí)。當(dāng)做完一些準(zhǔn)備工作后，再次閱讀 Spring 源碼，就沒以前那么痛苦了。當(dāng)然，Spring 的代碼經(jīng)過十幾年的迭代，代碼量很大。我在分析的過程中也只是盡量保證搞懂重要的邏輯，無法做到面面俱到。不過，如果大家愿意去讀 Spring 源碼，我相信會(huì)比我理解的更透徹。

除了上面說的動(dòng)手實(shí)踐外，在閱讀源碼的過程中，如果實(shí)在看不懂，不妨調(diào)試一下。比如某個(gè)變量你不知道有什么用，但是它又比較關(guān)鍵，在多個(gè)地方都出現(xiàn)了，顯然你必須要搞懂它。那么此時(shí)寫點(diǎn)測(cè)試代碼調(diào)試一下，立馬就能知道它有什么用了。

以上是我在閱讀源碼時(shí)所使用過的一些方法，當(dāng)然僅有上面那些可能還不夠。本節(jié)的最后再推薦兩本書，如下：

《Spring 揭秘》- 王福強(qiáng)著

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

第二本書在豆瓣上的評(píng)分不太好，不過我覺得還好。這本書我僅看了容器部分的代碼分析，總的來說還行。我在看循環(huán)依賴那一塊的代碼時(shí)，這本書還是給了我一些幫助的。好了，本節(jié)就到這里。

在本文的最后一章，我來說說我為什么閱讀 Spring 的源碼吧。對(duì)我個(gè)人而言，有兩個(gè)原因。第一，作為 Java Web 開發(fā)人員，我們基本上繞不過 Spring 技術(shù)棧。當(dāng)然除了 Spring，還有很多其他的選擇（比如有些公司自己封裝框架）。但不可否認(rèn)，Spring 現(xiàn)在仍是主流。對(duì)于這樣一個(gè)經(jīng)常打交道的框架，弄懂實(shí)現(xiàn)原理，還有很有必要的。起碼在它出錯(cuò)輸出一大堆異常時(shí)，你不會(huì)很心慌，可以從容的 debug。第二，我去年的這個(gè)時(shí)候，工作差不多快滿一年。我在寫第一年的工作總結(jié)時(shí)，覺得很心慌。感覺第一年好像只學(xué)到了一點(diǎn)開發(fā)的皮毛，技術(shù)方面，沒什么積累。加上后來想換工作，心里想著就自己現(xiàn)在的水平恐怕要失業(yè)了。所以為了平復(fù)自己焦慮的情緒，于是在去年的八月份的時(shí)候，我開始寫博客了。到現(xiàn)在寫了近30篇博客（比較少），其中有兩篇文章被博客平臺(tái)作為優(yōu)秀文章推薦過。現(xiàn)在，又快到7月份了，工齡馬上又要+1了。所以我現(xiàn)在在抓緊寫 Spring 相關(guān)的文章，希望在六月份多寫幾篇。算是對(duì)自己工作滿兩年的一個(gè)階段性技術(shù)總結(jié)，也是一個(gè)紀(jì)念吧。

當(dāng)然，看懂源碼并不是什么很了不起的事情，畢竟寫這些源碼的人才是真正的大神。我在大學(xué)的時(shí)候，自學(xué) MFC（沒錯(cuò)，就是微軟早已淘汰的東西）。并讀過侯捷老師著的《深入淺出MFC》一書，這本書中的一句話對(duì)我影響至深 - “勿在浮沙筑高臺(tái)”。勿在浮沙筑高臺(tái)，對(duì)于一個(gè)程序員來說，基礎(chǔ)很重要。所以我現(xiàn)在也在不斷的學(xué)習(xí)，希望能把基礎(chǔ)打好，這樣以后才能進(jìn)入更高的層次。

好了，感謝大家耐心看完我的嘮叨。本文先到這里，我要去寫后續(xù)的文章了，后面再見。bye~

本文在知識(shí)共享許可協(xié)議 4.0 下發(fā)布，轉(zhuǎn)載需在明顯位置處注明出處
作者：coolblog.xyz
本文同步發(fā)布在我的個(gè)人博客：http://www.coolblog.xyz

本作品采用知識(shí)共享署名-非商業(yè)性使用-禁止演繹 4.0 國(guó)際許可協(xié)議進(jìn)行許可。