Spring IoC容器與應用上下文的設計與實現

一、前言

　　寫這篇博文的主要目的如下：

• 通過相關類和介面分析IoC容器到底長什麼樣。
• 闡述筆者對Spring上下文和容器的理解。
• 介紹重要的類輔助理解SpringBoot的啟動流程。

 

二、Spring IoC容器的設計

　　看看下面這張圖（摘自《Spring技術內幕》），IoC容器的設計分為兩條線，

1. 　 BeanFactory ==> HierarchicalBeanFactory ==>ConfigurableBeanFactory ，這條線可以理解成IoC容器的設計路線。
2. 　 BeanFactory ==> ListableBeanFactory ==> ApplicationContext ==> ConfigurableApplicationContext ，這條可以成為Spring應用上下文的設計路線。

　　為什麼這樣要分兩條線呢，主要是將容器和上下文區分開來。因為在在Spring專案中，上下文對容器不僅是擴充套件的關係，更重要的是持有的關係，上下文是以屬性的形式持有了容器，開發者可以通過上下文物件獲取到容器。筆者十分傾向於將二者分開來理解。當然也可以將應用上下文理解成容器的高階表現形式。

 

2.1，IoC容器的設計線路

　　BeanFactory定義了IoC容器的基本規範，包括getBean()按型別和按名稱的獲取Bean的方法。

 　　

　　HierarchicalBeanFactory 在BeanFactory的基礎上增加了getParentBeanFactory()方法，使BeanFactory具備了雙親IoC容器管理的功能。

　　ConfigurableBeanFactory介面提供了配置BeanFactory的各種方法。比如setParentBeanFactory()方法，配置上面提到的雙親IoC容器，addBeanPostProcessor()方法，配置Bean後置處理器等。

　　到這裡先埋個包袱：到ConfigurableBeanFactory介面為止，IoC容器還沒有具備作為“容器”最基本的功能，那就是能裝東西。

 

2.2、應用上下文設計路線

　　上面說了應用上下文是IoC容器的高階表現形式，ListableBeanFactory具備了操作BeanDefinition 的能力，比如getBeanDefinitionCount()方法，可以獲取Bean的總數等。

　　ApplicationContext 類那就厲害了，如下程式碼所示，實現了一大堆介面

1 public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
2         MessageSource, ApplicationEventPublisher, ResourcePatternResolver

• MessageSource，支援不同的資訊源。具備支援國際化的實現，為開發多語言版本的應用提供服務。
• ResourcePatternResolver，訪問資料來源。具備了從不同地方得到Bean定義資源的能力，比如：xml，java config，註解等等。
• ApplicationEventPublisher，釋出事件。使應用上下文具備了事件機制。事件機制為Bean宣告週期的管理提供了便利。

　　WebApplicationContext擴充套件了對web應用的支援。

　　ConfigurableApplicationContext就更重要了，看過Spring原始碼的都知道一個重要的方法叫refresh，沒錯就是在這個介面中定義的。最重要的是擴充套件了配置上下文的功能，和控制上下文生命週期的能力等等。

 

三、IoC容器的具體實現類 DefaultListableBeanFactory（重點）

　　首先證明一點，為什麼說DefaultListableBeanFactory類是具體的實現類呢？

　　隨便啟動一個SpringBoot專案找到第25行程式碼（在SpringBoot的啟動流程系列博文中有介紹）

public ConfigurableApplicationContext run(String... args) {
    //記錄程式執行時間
    StopWatch stopWatch = new StopWatch();
    stopWatch.start();
    // ConfigurableApplicationContext Spring 的上下文
    ConfigurableApplicationContext context = null;
    Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
    configureHeadlessProperty();
    //從META-INF/spring.factories中獲取監聽器
    //1、獲取並啟動監聽器
    SpringApplicationRunListeners listeners = getRunListeners(args);
    listeners.starting();
    try {
        ApplicationArguments applicationArguments = new DefaultApplicationArguments(
                args);
        //2、構造容器環境
        ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
        //處理需要忽略的Bean
        configureIgnoreBeanInfo(environment);
        //列印banner
        Banner printedBanner = printBanner(environment);
        ///3、初始化容器
        context = createApplicationContext();
        //例項化SpringBootExceptionReporter.class，用來支援報告關於啟動的錯誤
        exceptionReporters = getSpringFactoriesInstances(
                SpringBootExceptionReporter.class,
                new Class[]{ConfigurableApplicationContext.class}, context);
        //4、重新整理容器前的準備階段
        prepareContext(context, environment, listeners, applicationArguments, printedBanner);
        //5、重新整理容器
        refreshContext(context);
        //重新整理容器後的擴充套件介面
        afterRefresh(context, applicationArguments);
        stopWatch.stop();
        if (this.logStartupInfo) {
            new StartupInfoLogger(this.mainApplicationClass)
                    .logStarted(getApplicationLog(), stopWatch);
        }
        listeners.started(context);
        callRunners(context, applicationArguments);
    } catch (Throwable ex) {
        handleRunFailure(context, ex, exceptionReporters, listeners);
        throw new IllegalStateException(ex);
    }

    try {
        listeners.running(context);
    } catch (Throwable ex) {
        handleRunFailure(context, ex, exceptionReporters, null);
        throw new IllegalStateException(ex);
    }
    return context;
}

　　debug

　　如2標註點所示IoC容器的真實面孔就是這個DefaultListableBeanFactory類了。當然他還有一個子類XmlBeanFactory，不過都已經被標註為啟用了（@Deprecated）在《Spring技術內幕》這本書裡面也是著重的講的這個類，可能當時作者是以SpringMVC專案來講解的吧。XmlBeanFactory顧名思義就是提供了對xml配置方式的支援。呃。。。又勾起了用SpringMVC的痛苦回憶。

　　言歸正傳，

　　如下圖，看看他的繼承關係

　　 章節二中提到了很多的IoC容器系列，這樣總結一下吧，俗話說一流企業做標準，二流企業做產品，章節二中的那一坨就是IoC容器的實現標準，本章節我們要總結的類DefaultListableBeanFactory就是IoC容器的具體產品。

　　看見上圖中那一堆介面和類是不是有點懵，沒關係，我們們慢慢梳理一下。

 

3.1，作為IoC容器的基礎設計路線

　　這條線路在上一章節中已經梳理過了。只是多出了ConfigurableListableBeanFactory介面，ConfigurableListableBeanFactory介面主要是增加指定忽略型別和介面等

 

3.2、作為IoC容器的高階設計路線

　　這條設計路線乍一看還是挺複雜的，的確是這樣。

　　1， BeanFactory ==> AutowireCapableBeanFactory ==> AbstractAutowireCapableBeanFactory ==> DefaultListableBeanFactory 

　　在這條線路中，AutowireCapableBeanFactory介面定義了自動注入bean（autowireBean()），建立bean(createBean())，初始化bean(initializeBean())方法等。那麼真正實現這些方法的類便是AbstractAutowireCapableBeanFactory。

　　AbstractAutowireCapableBeanFactory抽象類中實現了AutowireCapableBeanFactory介面定義的方法。在此基礎上通過繼承AbstractBeanFactory具備了操作Bean的能力。

　　2， SingletonBeanRegistry ==> DefaultSingletonBeanRegistry ==> FactoryBeanRegistrySupport ==> AbstractBeanFactory ==> AutowireCapableBeanFactory ==> DefaultListableBeanFactory 

　　這條關係鏈有點長，在這條鏈中我們要關心的是SingletonBeanRegistry介面，顧名思義，這個介面是單例Bean的註冊介面。當然也不止註冊這麼簡單。如下圖中所示，除了註冊單例之外，還定義獲取單例的方法。

　　注意：為什麼只有singleton的註冊中心，而沒有prototype型別的Bean的註冊中心呢？因為單例Bean（singleton）是Spring幫我們建立的並維護的，原型Bean（prototype）是每次獲取都會建立出來一個例項。本質是不同的。

　　3， AliasRegistry ==> SimpleAliasRegistry ==> DefaultSingletonBeanRegistry ==> FactoryBeanRegistrySupport ==> AbstractBeanFactory ==> AutowireCapableBeanFactory ==> DefaultListableBeanFactory 

 　　這條路線呢，主要是提供管理別稱的能力。因為不是重點，在此就不詳細分析了。

　　4， AliasRegistry ==> BeanDefinitionRegistry ==> DefaultListableBeanFactory 

　　BeanDefinitionRegistry介面要重點說一下，該介面是BeanDefinition的註冊中心。使DefaultListableBeanFactory具備操作BeanDefinition的能力。看一下它有什麼方法。

　　包括了註冊，刪除，獲取BeanDefinition的方法。當然這只是個介面，這些方法的具體實現在DefaultListableBeanFactory中。

 

3.3、DefaultListableBeanFactory幾個重要的父類和介面

3.3.1， AbstractBeanFactory 抽象類

　　如上圖所示，AbstractBeanFactory中實現了BeanFactory中定義的幾個重要的方法。常用的註解 @Autowired @Resource(name = "xxx") 大家都知道一個是按類查詢，一個是按名獲取。具體實現這兩個註解的方法就是上圖中圈出來的幾個方法。幾個getBean()方法最終都進入了doGetBean()方法。doGetBean()方法是實際獲得Bean的地方，也是觸發依賴注入發生的地方。在SpringBoot啟動流程總會對這個方法進行詳細的介紹。

3.3.2， AbstractAutowireCapableBeanFactory 抽象類

　　AbstractBeanFactory中實現了getBean()方法，AbstractAutowireCapableBeanFactory中實現了Bean的建立方法。

　　當我們需要定義一個Bean通常會有這樣寫 @Bean(name = "test", initMethod = "init", destroyMethod = "destroy") 。AbstractAutowireCapableBeanFactory中完成了一個Bean從 create(createBean()) ==> createInstance(createBeanInstance()) ==> init(invokeInitMethods()) 的所有工作。所以這個抽象類的作用不言而喻。具體的建立過程，會在SpringBoot的啟動流程中詳細介紹。

3.3.3， DefaultSingletonBeanRegistry 讓IoC容器擁有作為“容器”的能力

　　其實我們經常說的Spring 容器，這個容器其實更多的是BeanFactory所代表的意義：Bean生產工廠。是滴，通常我們理解的容器應該是能裝東西的，但是spring 容器不是代表代表水桶一樣的東西，而是像富士康一樣，生產東西的地方。比如我們需要一個Bean，我們只需要告訴spring，spring就會給我們。所以到目前為止我們還沒有看到IoC作為“容器”的能力。以上言論純屬自己理解，不喜勿噴。

　　DefaultSingletonBeanRegistry屬性先貼出來

public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
    /**
     * Cache of singleton objects: bean name --> bean instance
     * 快取 單例物件
     */
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);//好習慣，建立ConcurrentHashMap，指定初始化因子，縱觀Spring原始碼，建立HashMap，都有初始化因子。get

    /**
     * Cache of singleton factories: bean name --> ObjectFactory
     * 快取 單例工廠
     */
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

    /**
     * Cache of early singleton objects: bean name --> bean instance
     * 快取 提前暴露的物件
     */
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

    /**
     * Set of registered singletons, containing the bean names in registration order
     * 已經註冊的單例物件集合，按照註冊順序排序的，並且是不可重複的。
     */
    private final Set<String> registeredSingletons = new LinkedHashSet<>(256);

    /**
     * Names of beans that are currently in creation
     *
     */
    private final Set<String> singletonsCurrentlyInCreation =
            Collections.newSetFromMap(new ConcurrentHashMap<>(16));

    /**
     * Names of beans currently excluded from in creation checks
     */
    private final Set<String> inCreationCheckExclusions =
            Collections.newSetFromMap(new ConcurrentHashMap<>(16));

    /**
     * List of suppressed Exceptions, available for associating related causes
     */
    @Nullable
    private Set<Exception> suppressedExceptions;

    /**
     * Flag that indicates whether we're currently within destroySingletons
     */
    private boolean singletonsCurrentlyInDestruction = false;

    /**
     * Disposable bean instances: bean name --> disposable instance
     * spring是作為一個註冊中心的樣子，在容器shutdown的時候，直接從這裡面找到需要執行destory鉤子的Bean
     */
    private final Map<String, Object> disposableBeans = new LinkedHashMap<>();

    /**
     * Map between containing bean names: bean name --> Set of bean names that the bean contains
     * 名稱為name的bean，所持有的beans 的對映關係
     */
    private final Map<String, Set<String>> containedBeanMap = new ConcurrentHashMap<>(16);

    /**
     * Map between dependent bean names: bean name --> Set of dependent bean names
     * 名稱為name的bean與其所依賴的bean的對映關係
     */
    private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<>(64);

    /**
     * Map between depending bean names: bean name --> Set of bean names for the bean's dependencies
     */
    private final Map<String, Set<String>> dependenciesForBeanMap = new ConcurrentHashMap<>(64);
}

 

　　屬性singletonObjects ，沒錯，就是這個東東，最終儲存單例（singleton）Bean的地方，在SpringBoot啟動流程中，會詳細介紹存取的過程。上面說了原型（prototype）Bean是不需要快取的，不解釋了。到這裡我們初步看到了IoC作為“容器”該有的樣子。

　　DefaultSingletonBeanRegistry上面提到的SingletonBeanRegistry介面的相關方法，並且增加了很多對單例的操作的方法。

3.3.4， DefaultListableBeanFactory （重點）

　　上面我們從IoC容器的巨集觀設計角度闡述了DefaultListableBeanFactory作為IoC容器的具體實現的設計思想。在這裡來分析一下這個類本身的設計。

　　首先看看該類的屬性

public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
        implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable {
    /**
     * Map from serialized id to factory instance
     * 快取 序列化ID到 DefaultListableBeanFactory 例項的對映
     */
    private static final Map<String, Reference<DefaultListableBeanFactory>> serializableFactories =
            new ConcurrentHashMap<>(8);

    /**
     * Optional id for this factory, for serialization purposes
     */
    @Nullable
    private String serializationId;

    /**
     * Whether to allow re-registration of a different definition with the same name
     */
    private boolean allowBeanDefinitionOverriding = true;

    /**
     * Whether to allow eager class loading even for lazy-init beans
     */
    private boolean allowEagerClassLoading = true;

    /**
     * Optional OrderComparator for dependency Lists and arrays
     */
    @Nullable
    private Comparator<Object> dependencyComparator;

    /**
     * Resolver to use for checking if a bean definition is an autowire candidate
     * 被用來解決去校驗一個BeanDefinition是不是自動裝載的候選人
     */
    private AutowireCandidateResolver autowireCandidateResolver = new SimpleAutowireCandidateResolver();

    /**
     * Map from dependency type to corresponding autowired value
     * 快取 型別對應的自動裝載的Bean
     */
    private final Map<Class<?>, Object> resolvableDependencies = new ConcurrentHashMap<>(16);

    /**
     * Map of bean definition objects, keyed by bean name
     * 快取 beanName到BeanDefinition的對映關係
     */
    private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<>(256);

    /**
     * Map of singleton and non-singleton bean names, keyed by dependency type
     * 快取 型別 和 beanName的對映關係
     */
    private final Map<Class<?>, String[]> allBeanNamesByType = new ConcurrentHashMap<>(64);

    /**
     * Map of singleton-only bean names, keyed by dependency type
     * 快取 型別 和 單例Bean names的對映
     */
    private final Map<Class<?>, String[]> singletonBeanNamesByType = new ConcurrentHashMap<>(64);

    /**
     * List of bean definition names, in registration order
     * 快取 beanDefinition name的list
     */
    private volatile List<String> beanDefinitionNames = new ArrayList<>(256);

    /**
     * List of names of manually registered singletons, in registration order
     */
    private volatile Set<String> manualSingletonNames = new LinkedHashSet<>(16);

    /**
     * Cached array of bean definition names in case of frozen configuration
     */
    @Nullable
    private volatile String[] frozenBeanDefinitionNames;

    /**
     * Whether bean definition metadata may be cached for all beans
     */
    private volatile boolean configurationFrozen = false;
}

　　在Spring中，實際上是把DefaultListableBeanFactory作為一個預設的功能完整的IoC容器來使用。 DefaultListableBeanFactory作為一個功能完整的容器具備了除以上父類所具有功能外，還加入了對BeanDefinition的管理和維護。從上面的程式碼可以看到一個重要的屬性：beanDefinitionMap。beanDefinitionMap快取了Bean name到 BeanDefinition的對映。到這裡是不是發現了IoC容器另外一個作為“容器”的能力。在我的理解範圍內，IoC容器作為“容器”真正裝的兩個最總要的能力算是總結完了，一個是裝單例（Singleton）Bean，一個是裝BeanDefinition。

 

3.3.5， BeanDefinition 

　　Spring通過定義BeanDefinition來管理基於Spring的應用中的各種物件以及他們之間的相互依賴關係。BeanDefinition抽象了我們對Bean的定義，是讓容器起作用的主要資料型別。我麼都知道在計算機世界裡，所有的功能都是建立在通過資料對現實進行抽象的基礎上的。IoC容器是用來管理物件依賴關係的，對IoC容器來說，BeanDefinition就是對依賴反轉模式中管理的物件依賴關係的資料抽象，也是容器實現依賴反轉功能的核心資料結構，依賴反轉功能都是圍繞對這個BeanDefinition的處理來完成的。這些BeanDefinition就像是容器裡裝的水，有了這些基本資料，容器才能發揮作用。簡單一句話來說，BeanDefinition就是Bean的後設資料，BeanDefinition存放了對Bean的基本描述，包括Bean擁有什麼屬性，方法，Bean的位置等等Bean的各種資訊。IoC容器可以通過BeanDefinition生成Bean。

　　BeanDefinition究竟長什麼樣呢？

　　在同第三章debug的地方一樣，點開beanFactory，然後檢視beanDefinitionMap屬性。

　　OK，BeanDefinition就是長這樣了。具體怎麼通過它生成Bean，在SpringBoot啟動流程中會詳細介紹。

 

四、SpringBoot web工程中的上下文 AnnotationConfigServletWebServerApplicationContext

　　在SpringBoot工程中，應用型別分為三種，如下程式碼所示。

public enum WebApplicationType {
    /**
     * 應用程式不是web應用，也不應該用web伺服器去啟動
     */
    NONE,
    /**
     * 應用程式應作為基於servlet的web應用程式執行，並應啟動嵌入式servlet web（tomcat）伺服器。
     */
    SERVLET,
    /**
     * 應用程式應作為 reactive web應用程式執行，並應啟動嵌入式 reactive web伺服器。
     */
    REACTIVE
}

　　對應三種應用型別，SpringBoot專案有三種對應的應用上下文，我們以web工程為例，即其上下文為AnnotationConfigServletWebServerApplicationContext

public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework.boot."
        + "web.servlet.context.AnnotationConfigServletWebServerApplicationContext";
public static final String DEFAULT_REACTIVE_WEB_CONTEXT_CLASS = "org.springframework."
        + "boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext";
public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
        + "annotation.AnnotationConfigApplicationContext";
        
protected ConfigurableApplicationContext createApplicationContext() {
    Class<?> contextClass = this.applicationContextClass;
    if (contextClass == null) {
        try {
            switch (this.webApplicationType) {
                case SERVLET:
                    contextClass = Class.forName(DEFAULT_WEB_CONTEXT_CLASS);
                    break;
                case REACTIVE:
                    contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
                    break;
                default:
                    contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
            }
        } catch (ClassNotFoundException ex) {
            throw new IllegalStateException(
                    "Unable create a default ApplicationContext, "
                            + "please specify an ApplicationContextClass",
                    ex);
        }
    }
    return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
}

　　我們先看一下AnnotationConfigServletWebServerApplicationContext的設計。　

 　　在2.2中已經介紹了ApplicationContext的設計

　　關於AnnotationConfigServletWebServerApplicationContext詳細的設計路線在這裡就不像DefaultListableBeanFactory容器那麼詳細的去講解了。在第二章說過，應用上下文可以理解成IoC容器的高階表現形式，拿上圖和DefaultListableBeanFactory的繼承關係圖，不難發現，應用上下文確實是在IoC容器的基礎上豐富了一些高階功能。在第二章中，我們還說過應用上下文對IoC容器是持有的關係。繼續看第二章debug的截圖，context就是AnnotationConfigServletWebServerApplicationContext的神祕面孔，他的一個屬性beanFactory就是IoC容器（DefaultListableBeanFactory）。所以他們之間是持有，和擴充套件的關係。

　　接下來看GenericApplicationContext類

public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
    private final DefaultListableBeanFactory beanFactory;
    ...
}

 　　第一行赫然定義了beanFactory屬性，正是DefaultListableBeanFactory物件。

　　關於上下文還有另外一個最重要的方法refresh，上文中說道該方法是在ConfigurableApplicationContext介面中定義的，那麼在哪實現的該方法呢？

　　看AbstractApplicationContext類。

@Override
public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        // Prepare this context for refreshing.
        //重新整理上下文環境
        prepareRefresh();

        // Tell the subclass to refresh the internal bean factory.
        //這裡是在子類中啟動 refreshBeanFactory() 的地方
        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

        // Prepare the bean factory for use in this context.
        //準備bean工廠，以便在此上下文中使用
        prepareBeanFactory(beanFactory);

        try {
            // Allows post-processing of the bean factory in context subclasses.
            //設定 beanFactory 的後置處理
            postProcessBeanFactory(beanFactory);

            // Invoke factory processors registered as beans in the context.
            //呼叫 BeanFactory 的後處理器，這些處理器是在Bean 定義中向容器註冊的
            invokeBeanFactoryPostProcessors(beanFactory);

            // Register bean processors that intercept bean creation.
            //註冊Bean的後處理器，在Bean建立過程中呼叫
            registerBeanPostProcessors(beanFactory);

            // Initialize message source for this context.
            //對上下文中的訊息源進行初始化
            initMessageSource();

            // Initialize event multicaster for this context.
            //初始化上下文中的事件機制
            initApplicationEventMulticaster();

            // Initialize other special beans in specific context subclasses.
            //初始化其他特殊的Bean
            onRefresh();

            // Check for listener beans and register them.
            //檢查監聽Bean並且將這些監聽Bean向容器註冊
            registerListeners();

            // Instantiate all remaining (non-lazy-init) singletons.
            //例項化所有的（non-lazy-init）單件
            finishBeanFactoryInitialization(beanFactory);

            // Last step: publish corresponding event.
            //釋出容器事件，結束Refresh過程
            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.
            destroyBeans();

            // Reset 'active' flag.
            cancelRefresh(ex);

            // Propagate exception to caller.
            throw ex;
        } finally {
            // Reset common introspection caches in Spring's core, since we
            // might not ever need metadata for singleton beans anymore...
            resetCommonCaches();
        }
    }
}

 　　OK，應用上下文就介紹到這裡。

 

 五、IoC容器的初始化過程

 　　在這裡我們先口述一下IoC容器的初始化過程吧，原始碼分析，請移步SpringBoot啟動流程分析。

　　簡單來說IoC容器的初始化過程是由前面介紹的refresh()方法啟動的，這個方法標誌著IoC容器的正式啟動。具體來說，這個啟動包括三個過程

• BeanDefinition的Resource定位
• BeanDefinition的載入
• 向IoC容器註冊BeanDefinition

 　　1、第一個過程：Resource定位

　　這個定位指的是BeanDefinition的資源定位，它由ResourceLoader通過統一的Resource介面完成，這個Resource對各種形式的BeanDefinition的使用都提供了統一介面。對於這些BeanDefinition的存在形式，可以是通過像SpringMVC中的xml定義的Bean，也可以是像在類路徑中的Bean定義資訊，比如使用@Component等註解定義的。這個過程類似於容器尋找資料的過程，就像用水桶裝水先要把水找到一樣。

　　結合SpringBoot說一下這個過程，對於SpringBoot，我們都知道他的包掃描是從主類所在的包開始掃描的，那這個定位的過程在SpringBoot中具體是這樣的，在refresh容器之前（prepareContext()方法中），會先將主類解析成BeanDefinition，然後在refresh方法中並且是掃描Bean之前，解析主類的BeanDefinition獲取basePackage的路徑。這樣就完成了定位的過程。（先不討論SpringBoot中指定掃描包路徑和自動裝配）

　　2、第二個過程：BeanDefinition的載入

　　這個載入過程是把使用者定義好的Bean表示成IoC容器內部的資料結構，而這個容器內部的資料結構就是BeanDefinition。

　　在SpringBoot中，上面我們說到通過主類找到了basePackage，SpringBoot會將該路徑拼接成：classpath*:org/springframework/boot/demo/**/*.class這樣的形式，然後一個叫做PathMatchingResourcePatternResolver的類會將該路徑下所有的.class檔案都載入進來，然後遍歷判斷是不是有@Component註解，如果有的話，就是我們要裝載的BeanDefinition。大致過程就是這樣的了。

　　注意：@Configuration，@Controller，@Service等註解底層都是@Component註解，只不過包裝了一層罷了。

 　　3、第三個過程：註冊BeanDefinition

 　　這個過程通過呼叫上文提到的BeanDefinitionRegister介面的實現來完成。這個註冊過程把載入過程中解析得到的BeanDefinition向IoC容器進行註冊。通過上文的分析，我們可以看到，在IoC容器中將BeanDefinition注入到一個ConcurrentHashMap中，IoC容器就是通過這個HashMap來持有這些BeanDefinition資料的。比如DefaultListableBeanFactory 中的beanDefinitionMap屬性。

六、IoC容器的依賴注入

　　上面對IoC容器的初始化過程進行了詳細的介紹，這個過程完成的主要的工作是在IoC容器中建立BeanDefinition資料對映。在此過程中並沒有看到IoC容器對Bean的依賴關係進行注入。依賴注入是Spring實現“控制反轉”的重要一環。Spring將依賴關係交給IoC容器來完成。

　　依賴控制反轉的實現有很多種方式。在Spring中，IoC容器是實現這個模式的載體，它可以在物件生成或者初始化時直接將資料注入到物件中，也可以通過將物件注入到物件資料域中的方式來注入對方法呼叫的依賴。這種依賴注入是可以遞迴的，物件被逐層注入。

 

 

　　原創不易，轉載請註明出處。

　　如有錯誤的地方還請留言指正。

 

參考文獻：

　　《Spring技術內幕--深入解析Spring框架與設計原理（第二版）》