1.1 接口和類說明

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

接口ListableBeanFactory

官方說明

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

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

接口HierarchicalBeanFactory

官方說明

       由bean factory實現的子接口，實現了該接口的bean factory能成為一個層次結構的一部分。

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

接口ApplicationContext

官方說明：

中心接口，以提供應用程序的配置。當應用程序正在運行，這是只讀的，但如果實現支持，它是允許重新加載的。

一個ApplicationContext提供如下功能：

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

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

能夠向注冊的監聽器發布事件，其繼承自ApplicationEventPublisher。

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

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

接口AutowireCapableBeanFactory

官方說明

    BeanFactory接口的擴展，可以被那些有能力自動裝配的bean factory實現，用以達到為存在的bean暴露此項功能的目的。

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

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

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

接口ConfigurableApplicationContext

官方說明

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

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

個人理解:

抽象類AbstractApplicationContext

官方說明：

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

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

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

個人理解：

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

抽象類AbstractRefreshableApplicationContext

ApplicationContext的基類的實現，其支持多次refreshs，每次創建一個內部bean工廠實例。通常（但不一定），一個上下文將會由一系列的配置定位來驅動，加載bean definations。

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

抽象類AbstractRefreshableConfigApplicationContext

官方說明

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

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

抽象類AbstractXmlApplicationContext說明：

ApplicationContext的便利基類的實現。用于提取包含bean definition信息的XML文檔，該文檔由XmlBeanDefinitionReader負責解釋。

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

類FileSystemXmlApplicationContext說明

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

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

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

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

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

接口ResourceLoader

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

接口ResourcePatternResolver

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

類PathMatchingResourcePatternResolver

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

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

2容器啟動分析

2.1容器的構建
 我們以FileSystemXmlApplicationContext為例來分析容器的啟動過程，首先看看FileSystemXmlApplicationContext的構造函數:

public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
                                  throws BeansException {
        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
//refresh方法是容器啟動的核心，包括內部容器的維護,資源定位處理,資源的解析、注冊等。
            refresh();
        }
}
關于super的調用，以下代碼是個重點：
以下代碼來自于AbstractApplicationContext，這里要注意的是容器在構造時自動構造了資源模式解釋器，關于資源模式解釋器后面會有介紹.
//資源模式解釋器，用于解釋處理ant-style配置信息,也可以把它理解為批量資源解釋器,并把解釋的一組資源定位解釋成Resource.該實例在容器創建時會自動創建
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實現，從圖1可以看到AbstractApplicationContext是ApplicationContext接口的最頂層實現。注意:方法中的子方法調用將在后面的章節中分別介紹。

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

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

            try {
    // Allows post-processing of the bean factory in context subclasses.
                postProcessBeanFactory(beanFactory);
//調用BeanFactory的后置處理，其處理的流程是:
/** *//** *//** *//**
(1)先對在prepareBeanFactory階段注冊的后置處理組件先進行調用;
(2)然后從容器加載BeanFactoryPostProcessor類型的bean,進行調用處理，這類例子我們經常用到，例如PropertyPlaceholderConfigurer在分離數據庫配置中的使用；*/
                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;
            }
        }
    }