1.1 接口和類說明

類圖中列出了多種類和接口，下面列出重點(diǎn)的進(jìn)行說明。注意官方說明，翻譯自API。

接口ListableBeanFactory

官方說明

BeanFactory接口的擴(kuò)展，由那些能夠列舉它們所管理的所有bean實(shí)例的bean工廠所實(shí)現(xiàn)。而不是試圖通過來自于客戶端的by name方式的bean查找。預(yù)載所有bean definitions的BeanFactory實(shí)現(xiàn)可能會實(shí)現(xiàn)該接口。

個人理解：提供bean factory所管理bean的枚舉的接口

接口HierarchicalBeanFactory

官方說明

       由bean factory實(shí)現(xiàn)的子接口，實(shí)現(xiàn)了該接口的bean factory能成為一個層次結(jié)構(gòu)的一部分。

個人理解：用以組織bean factory層次的一個接口。

接口ApplicationContext

官方說明：

中心接口，以提供應(yīng)用程序的配置。當(dāng)應(yīng)用程序正在運(yùn)行，這是只讀的，但如果實(shí)現(xiàn)支持，它是允許重新加載的。

一個ApplicationContext提供如下功能：

用來訪問應(yīng)用程序組件的bean factory方法，其繼承自ListableBeanFactory。

能以通用的方式加載文件資源，其繼承自ResourceLoader。

能夠向注冊的監(jiān)聽器發(fā)布事件，其繼承自ApplicationEventPublisher。

能夠解析消息，支持國際化，繼承自MessageSource。

繼承自父上下文，后代上下文中的Definition將總能獲得優(yōu)先級，這意味著，例如，一個單親上下文能夠被整個應(yīng)用程序使用，而每個servlet有它自己的孩子上下文，它獨(dú)立于其他的servlet。

接口AutowireCapableBeanFactory

官方說明

    BeanFactory接口的擴(kuò)展，可以被那些有能力自動裝配的bean factory實(shí)現(xiàn)，用以達(dá)到為存在的bean暴露此項(xiàng)功能的目的。

    該接口不應(yīng)在常見的應(yīng)用程序中使用，黏合BeanFactory或者ListableBeanFactory是其典型的應(yīng)用案例。

    應(yīng)該注意的是，該接口不應(yīng)被ApplicationContext直接實(shí)現(xiàn)，因?yàn)閼?yīng)用程序代碼幾乎不曾被應(yīng)用程序代碼使用。也就是說，它也可以通過訪問ApplicationContext的getAutowireCapableBeanFactory（）方法從應(yīng)用程序上下文中獲得，即獲得一個AutowireCapableBeanFactory實(shí)例。
個人理解

    從接口定義的方法中可以看出，該接口主要用于自動裝配bean，包括創(chuàng)建bean、裝配bean的屬性、裝配bean的依賴、注冊bean等。該接口對于外部的應(yīng)用程序而言，幾乎不需要使用，其只應(yīng)用于Spring容器的內(nèi)部管理，實(shí)際上只有內(nèi)部bean factory實(shí)現(xiàn)此功能。關(guān)于內(nèi)部bean factory后面會有說明。

接口ConfigurableApplicationContext

官方說明

SPI(單個程序啟動)接口將會被大多數(shù)而不是全部的應(yīng)用程序上下文實(shí)現(xiàn)，除了在ApplicationContext中的應(yīng)用程序上下文客戶端方法，其還提供設(shè)施來配置上下文。

         配置和生命周期方法被封裝在這里，以避免使他們暴漏給ApplicationContext的客戶端代碼。這些方法應(yīng)該只用于啟動和關(guān)閉代碼中。

個人理解:

抽象類AbstractApplicationContext

官方說明：

ApplicationContext接口的抽象實(shí)現(xiàn)。其不要求配置使用的存儲類型，只是簡單的實(shí)現(xiàn)了常見上下文功能。它采用了模板方法模式，因此要求具體子類實(shí)現(xiàn)抽象方法。

與普通的BeanFactory相比，ApplicationContext支持檢測定義在其內(nèi)部的bean工廠中的特殊的bean。因此，該類能自動注冊BeanFactoryPostProcessor、BeanPostProcessor、ApplicationListener，它們在上下文中都被定義為beans。

通過擴(kuò)展DefaultResourceLoader實(shí)現(xiàn)資源加載，因此，視非URL資源路徑為類路徑資源（支持完整類路徑資源命名，包括包路徑，例如mypackage/myresource.dat），否則getResourceByPath方法需要在子類中覆寫。

個人理解：

       該類提供了BeanFactory的后置processor的注冊、應(yīng)用上下文的雙親維護(hù)、資源加載的功能。

抽象類AbstractRefreshableApplicationContext

ApplicationContext的基類的實(shí)現(xiàn)，其支持多次refreshs，每次創(chuàng)建一個內(nèi)部bean工廠實(shí)例。通常（但不一定），一個上下文將會由一系列的配置定位來驅(qū)動，加載bean definations。

子類唯一需要實(shí)現(xiàn)的方法是loadBeanDefinitions，該方法主要是獲取每次刷新調(diào)用。具體的實(shí)現(xiàn)應(yīng)該是加載bean定義到給定的org.springframework.beans.factory.support.DefaultListableBeanFactory，通常委托給一個或多個特定的bean definition readers。

抽象類AbstractRefreshableConfigApplicationContext

官方說明

AbstractRefreshableApplicationContext的子類，增加了針對 指定的配置位置(configLocations)的常見的處理。可以作為基于XML應(yīng)用程序上下文實(shí)現(xiàn)的基類，例如ClassPathXmlApplicationContex與FileSystemXmlApplicationContext，也可以是XmlWebApplicationContext與XmlPortletApplicationContext。
個人理解：

 主要為配置文件位置的設(shè)置提供入口，即實(shí)現(xiàn)了setConfigLocation方法。這就提供了不依賴于Spring的且更靈活、通用的配置注入方式。

抽象類AbstractXmlApplicationContext說明：

ApplicationContext的便利基類的實(shí)現(xiàn)。用于提取包含bean definition信息的XML文檔，該文檔由XmlBeanDefinitionReader負(fù)責(zé)解釋。

子類要實(shí)getConfigResources和/或getConfigLocations，此外，他們可能會覆蓋
getResourceByPath鉤子來解釋相對路徑。

類FileSystemXmlApplicationContext說明

獨(dú)立的XML應(yīng)用程序上下文，它從文件系統(tǒng)或者URLs獲得上下文定義，解釋普通路徑為相對文件系統(tǒng)位置（如“MYDIR/ myfile.txt”），同時它也是有用的測試工具與獨(dú)立環(huán)境。

普通路徑總是會被解釋為相對當(dāng)前VM的工作目錄，即使他們以斜線開頭。（這與Servlet容器的語義是一致的。）使用一個明確的“file：”前綴，以執(zhí)行一個絕對文件路徑。

配置文件位置默認(rèn)值可以通過getConfigLocations覆蓋，配置位置可以表示為“/ MYFILES/ context.xml中”之類的具體文件，也可以像“/ MYFILES/ *- context.xml”似的Ant風(fēng)格模式（org.springframework.util.AntPathMatcher）。

注意：在多個配置位置的情況下，以后的bean定義覆蓋先前加載的文件中定義的。這可以通過一個額外的XML文件，來故意覆蓋某些bean定義。

這是一個簡單的，一站式的便利的ApplicationContext。考慮結(jié)合使用GenericApplicationContext和XmlBeanDefinitionReader提供更靈活的上下文設(shè)置。

接口ResourceLoader

加載資源(例如，類路徑和文件路徑)的策略接口，ApplicationContext需要提供此功能，加上擴(kuò)展的ResourcePatternResolver支持。DefaultResourceLoader是該接口的獨(dú)立實(shí)現(xiàn)，它可用于ApplicationContext以外，也可以被ResourceEditor使用。

接口ResourcePatternResolver

    解釋位置模式的策略接口，其擴(kuò)展自ResourcePatternResolver接口。

類PathMatchingResourcePatternResolver

ResourcePatternResolver接口的實(shí)現(xiàn)，能夠把指定的資源位置路徑轉(zhuǎn)化為一個或者多個匹配資源。源路徑可能是一個簡單的路徑，它一對一映射到目標(biāo)(Resource)，或者可能選擇性地包含特定的“classpath*：”前綴和/或者Ant-style正則表達(dá)式（由org.springframework.util.AntPathMatcher匹配）

在一般的情況，如果指定的位置路徑?jīng)]有以“classpath*：”前綴開始，并且未包含PathMatcher模式，解釋器將通過調(diào)用ResourceLoader的getResource方法返回單一的資源。例子可包括真實(shí)的 URLs，例如file:C:/context.xml；偽URLs，例如classpath:/context.xml；簡單的無前綴的路徑，例如，/WEB-INF/context.xml。

2容器啟動分析

2.1容器的構(gòu)建
 我們以FileSystemXmlApplicationContext為例來分析容器的啟動過程，首先看看FileSystemXmlApplicationContext的構(gòu)造函數(shù):

public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
                                  throws BeansException {
        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
//refresh方法是容器啟動的核心，包括內(nèi)部容器的維護(hù),資源定位處理,資源的解析、注冊等。
            refresh();
        }
}
關(guān)于super的調(diào)用，以下代碼是個重點(diǎn)：
以下代碼來自于AbstractApplicationContext，這里要注意的是容器在構(gòu)造時自動構(gòu)造了資源模式解釋器，關(guān)于資源模式解釋器后面會有介紹.
//資源模式解釋器，用于解釋處理ant-style配置信息,也可以把它理解為批量資源解釋器,并把解釋的一組資源定位解釋成Resource.該實(shí)例在容器創(chuàng)建時會自動創(chuàng)建
private ResourcePatternResolver resourcePatternResolver;
public AbstractApplicationContext(ApplicationContext parent) {
        this.parent = parent;
        this.resourcePatternResolver = getResourcePatternResolver();
}
protected ResourcePatternResolver getResourcePatternResolver() {
        return new PathMatchingResourcePatternResolver(this);
}

一般情況下，我們可以通過編碼的方式來啟動容器，例如，如下：

ApplicationContext context = new FileSystemXmlApplicationContext (
        new String[] {"classpath:applicationContext*.xml"},true,null);
BeanFactory factory = (BeanFactory) context;

2.2容器的初始化
2.2.1Refresh方法分析
    我們接下來分析fresh方法，該方法由FileSystemXmlApplicationContext的父類AbstractApplicationContext實(shí)現(xiàn)，從圖1可以看到AbstractApplicationContext是ApplicationContext接口的最頂層實(shí)現(xiàn)。注意:方法中的子方法調(diào)用將在后面的章節(jié)中分別介紹。

public void refresh() throws BeansException, IllegalStateException {
    //獲得啟動關(guān)閉監(jiān)視器，防止此刻容器被其他線程操作。
synchronized (this.startupShutdownMonitor) {
            prepareRefresh();//激活容器的活動狀態(tài)，采用鎖進(jìn)行同步
/** *//** *//** *//**這里是容器初始化最為關(guān)鍵的一步，主要完成：
1.內(nèi)部容器的初始化，包括對已經(jīng)存在的內(nèi)部容器管理的資源的銷毀、內(nèi)部容器的銷毀、創(chuàng)建新的內(nèi)部容器等；
2.資源定位解釋，即把configLocations解釋成一個或者多個Resource;
3.BeanDefinition加載與注冊，把Resource加載解釋成xml Document，然后對Document進(jìn)行解釋，形成BeanDefinition，并對Definition進(jìn)行注冊；*/
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

            //內(nèi)部工廠的預(yù)處理，主要是注冊一些Spring組件
            prepareBeanFactory(beanFactory);

            try {
    // Allows post-processing of the bean factory in context subclasses.
                postProcessBeanFactory(beanFactory);
//調(diào)用BeanFactory的后置處理，其處理的流程是:
/** *//** *//** *//**
(1)先對在prepareBeanFactory階段注冊的后置處理組件先進(jìn)行調(diào)用;
(2)然后從容器加載BeanFactoryPostProcessor類型的bean,進(jìn)行調(diào)用處理，這類例子我們經(jīng)常用到，例如PropertyPlaceholderConfigurer在分離數(shù)據(jù)庫配置中的使用；*/
                invokeBeanFactoryPostProcessors(beanFactory);
                // Register bean processors that intercept bean creation.
                registerBeanPostProcessors(beanFactory);
                // Initialize message source for this context.
                initMessageSource();
// Initialize event multicaster for this context.
                initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
                onRefresh();
                // Check for listener beans and register them.
                registerListeners();
                // Instantiate all remaining (non-lazy-init) singletons.
                finishBeanFactoryInitialization(beanFactory);
                // Last step: publish corresponding event.
                finishRefresh();
            }

            catch (BeansException ex) {
                beanFactory.destroySingletons();
                cancelRefresh(ex);
                throw ex;
            }
        }
    }