在過去兩三年的spring生态圈，最讓人興奮的莫過于spring boot架構。或許從命名上就能看出這個架構的設計初衷：快速的啟動spring應用。因而spring boot應用本質上就是一個基于spring架構的應用，它是spring對“約定優先于配置”理念的最佳實踐産物，它能夠幫助開發者更快速高效地建構基于spring生态圈的應用。
掃碼關注“不才黃某”
回複“spring”
擷取spring boot實戰視訊
那spring boot有何魔法？自動配置、起步依賴、actuator、指令行界面(cli) 是spring boot最重要的4大核心特性，其中cli是spring boot的可選特性，雖然它功能強大，但也引入了一套不太正常的開發模型，因而這個系列的文章僅關注其它3種特性。如文章标題，本文是這個系列的第一部分，将為你打開spring boot的大門，重點為你剖析其啟動流程以及自動配置實作原理。要掌握這部分核心内容，了解一些spring架構的基礎知識，将會讓你事半功倍。
如果有看過<code>springapplication.run()</code>方法的源碼，spring boot冗長無比的啟動流程一定會讓你抓狂，透過現象看本質，springapplication隻是将一個典型的spring應用的啟動流程進行了擴充，是以，透徹了解spring容器是打開spring boot大門的一把鑰匙。
可以把spring ioc容器比作一間餐館，當你來到餐館，通常會直接招呼服務員：點菜！至于菜的原料是什麼？如何用原料把菜做出來？可能你根本就不關心。ioc容器也是一樣，你隻需要告訴它需要某個bean，它就把對應的執行個體（instance）扔給你，至于這個bean是否依賴其他元件，怎樣完成它的初始化，根本就不需要你關心。
作為餐館，想要做出菜肴，得知道菜的原料和菜單，同樣地，ioc容器想要管理各個業務對象以及它們之間的依賴關系，需要通過某種途徑來記錄和管理這些資訊。<code>beandefinition</code>對象就承擔了這個責任：容器中的每一個bean都會有一個對應的beandefinition執行個體，該執行個體負責儲存bean對象的所有必要資訊，包括bean對象的class類型、是否是抽象類、構造方法和參數、其它屬性等等。當用戶端向容器請求相應對象時，容器就會通過這些資訊為用戶端傳回一個完整可用的bean執行個體。
原材料已經準備好（把beandefinition看着原料），開始做菜吧，等等，你還需要一份菜單，<code>beandefinitionregistry</code>和<code>beanfactory</code>就是這份菜單，beandefinitionregistry抽象出bean的注冊邏輯，而beanfactory則抽象出了bean的管理邏輯，而各個beanfactory的實作類就具體承擔了bean的注冊以及管理工作。它們之間的關系就如下圖：
beanfactory、beandefinitionregistry關系圖（來自：spring揭秘）
<code>defaultlistablebeanfactory</code>作為一個比較通用的beanfactory實作，它同時也實作了beandefinitionregistry接口，是以它就承擔了bean的注冊管理工作。從圖中也可以看出，beanfactory接口中主要包含getbean、containbean、gettype、getaliases等管理bean的方法，而beandefinitionregistry接口則包含registerbeandefinition、removebeandefinition、getbeandefinition等注冊管理beandefinition的方法。
下面通過一段簡單的代碼來模拟beanfactory底層是如何工作的：
這段代碼僅為了說明beanfactory底層的大緻工作流程，實際情況會更加複雜，比如bean之間的依賴關系可能定義在外部配置檔案(xml/properties)中、也可能是注解方式。spring ioc容器的整個工作流程大緻可以分為兩個階段：
①、容器啟動階段
容器啟動時，會通過某種途徑加載<code>configuration metadata</code>。除了代碼方式比較直接外，在大部分情況下，容器需要依賴某些工具類，比如：<code>beandefinitionreader</code>，beandefinitionreader會對加載的<code>configuration metadata</code>進行解析和分析，并将分析後的資訊組裝為相應的beandefinition，最後把這些儲存了bean定義的beandefinition，注冊到相應的beandefinitionregistry，這樣容器的啟動工作就完成了。這個階段主要完成一些準備性工作，更側重于bean對象管理資訊的收集，當然一些驗證性或者輔助性的工作也在這一階段完成。
來看一個簡單的例子吧，過往，所有的bean都定義在xml配置檔案中，下面的代碼将模拟beanfactory如何從配置檔案中加載bean的定義以及依賴關系：
②、bean的執行個體化階段
經過第一階段，所有bean定義都通過beandefinition的方式注冊到beandefinitionregistry中，當某個請求通過容器的getbean方法請求某個對象，或者因為依賴關系容器需要隐式的調用getbean時，就會觸發第二階段的活動：容器會首先檢查所請求的對象之前是否已經執行個體化完成。如果沒有，則會根據注冊的beandefinition所提供的資訊執行個體化被請求對象，并為其注入依賴。當該對象裝配完畢後，容器會立即将其傳回給請求方法使用。
beanfactory隻是spring ioc容器的一種實作，如果沒有特殊指定，它采用采用延遲初始化政策：隻有當通路容器中的某個對象時，才對該對象進行初始化和依賴注入操作。而在實際場景下，我們更多的使用另外一種類型的容器：<code>applicationcontext</code>，它建構在beanfactory之上，屬于更進階的容器，除了具有beanfactory的所有能力之外，還提供對事件監聽機制以及國際化的支援等。它管理的bean，在容器啟動時全部完成初始化和依賴注入操作。
ioc容器負責管理容器中所有bean的生命周期，而在bean生命周期的不同階段，spring提供了不同的擴充點來改變bean的命運。在容器的啟動階段，<code>beanfactorypostprocessor</code>允許我們在容器執行個體化相應對象之前，對注冊到容器的beandefinition所儲存的資訊做一些額外的操作，比如修改bean定義的某些屬性或者增加其他資訊等。
如果要自定義擴充類，通常需要實作<code>org.springframework.beans.factory.config.beanfactorypostprocessor</code>接口，與此同時，因為容器中可能有多個beanfactorypostprocessor，可能還需要實作<code>org.springframework.core.ordered</code>接口，以保證beanfactorypostprocessor按照順序執行。spring提供了為數不多的beanfactorypostprocessor實作，我們以<code>propertyplaceholderconfigurer</code>來說明其大緻的工作流程。
在spring項目的xml配置檔案中，經常可以看到許多配置項的值使用占位符，而将占位符所代表的值單獨配置到獨立的properties檔案，這樣可以将散落在不同xml檔案中的配置集中管理，而且也友善運維根據不同的環境進行配置不同的值。這個非常實用的功能就是由propertyplaceholderconfigurer負責實作的。
根據前文，當beanfactory在第一階段加載完所有配置資訊時，beanfactory中儲存的對象的屬性還是以占位符方式存在的，比如<code>${jdbc.mysql.url}</code>。當propertyplaceholderconfigurer作為beanfactorypostprocessor被應用時，它會使用properties配置檔案中的值來替換相應的beandefinition中占位符所表示的屬性值。當需要執行個體化bean時，bean定義中的屬性值就已經被替換成我們配置的值。當然其實作比上面描述的要複雜一些，這裡僅說明其大緻工作原理，更詳細的實作可以參考其源碼。
與之相似的，還有<code>beanpostprocessor</code>，其存在于對象執行個體化階段。跟beanfactorypostprocessor類似，它會處理容器内所有符合條件并且已經執行個體化後的對象。簡單的對比，beanfactorypostprocessor處理bean的定義，而beanpostprocessor則處理bean完成執行個體化後的對象。beanpostprocessor定義了兩個接口：
為了了解這兩個方法執行的時機，簡單的了解下bean的整個生命周期：
bean的執行個體化過程（來自：spring揭秘）
<code>postprocessbeforeinitialization()</code>方法與<code>postprocessafterinitialization()</code>分别對應圖中前置處理和後置處理兩個步驟将執行的方法。這兩個方法中都傳入了bean對象執行個體的引用，為擴充容器的對象執行個體化過程提供了很大便利，在這兒幾乎可以對傳入的執行個體執行任何操作。注解、aop等功能的實作均大量使用了<code>beanpostprocessor</code>，比如有一個自定義注解，你完全可以實作beanpostprocessor的接口，在其中判斷bean對象的腦袋上是否有該注解，如果有，你可以對這個bean執行個體執行任何操作，想想是不是非常的簡單？
再來看一個更常見的例子，在spring中經常能夠看到各種各樣的aware接口，其作用就是在對象執行個體化完成以後将aware接口定義中規定的依賴注入到目前執行個體中。比如最常見的<code>applicationcontextaware</code>接口，實作了這個接口的類都可以擷取到一個applicationcontext對象。當容器中每個對象的執行個體化過程走到beanpostprocessor前置處理這一步時，容器會檢測到之前注冊到容器的applicationcontextawareprocessor，然後就會調用其postprocessbeforeinitialization()方法，檢查并設定aware相關依賴。看看代碼吧，是不是很簡單：
最後總結一下，本小節内容和你一起回顧了spring容器的部分核心内容，限于篇幅不能寫更多，但了解這部分内容，足以讓您輕松了解spring boot的啟動原理，如果在後續的學習過程中遇到一些晦澀難懂的知識，再回過頭來看看spring的核心知識，也許有意想不到的效果。也許spring boot的中文資料很少，但spring的中文資料和書籍有太多太多，總有東西能給你啟發。
我們知道<code>bean</code>是spring ioc中非常核心的概念，spring容器負責bean的生命周期的管理。在最初，spring使用xml配置檔案的方式來描述bean的定義以及互相間的依賴關系，但随着spring的發展，越來越多的人對這種方式表示不滿，因為spring項目的所有業務類均以bean的形式配置在xml檔案中，造成了大量的xml檔案，使項目變得複雜且難以管理。
後來，基于純java annotation依賴注入架構<code>guice</code>出世，其性能明顯優于采用xml方式的spring，甚至有部分人認為，<code>guice</code>可以完全取代spring（<code>guice</code>僅是一個輕量級ioc架構，取代spring還差的挺遠）。正是這樣的危機感，促使spring及社群推出并持續完善了<code>javaconfig</code>子項目，它基于java代碼和annotation注解來描述bean之間的依賴綁定關系。比如，下面是使用xml配置方式來描述bean的定義：
而基于javaconfig的配置形式是這樣的：
如果兩個bean之間有依賴關系的話，在xml配置中應該是這樣：
而在javaconfig中則是這樣：
你可能注意到這個示例中，有兩個bean都依賴于dependencyservice，也就是說當初始化bookservice時會調用<code>dependencyservice()</code>，在初始化otherservice時也會調用<code>dependencyservice()</code>，那麼問題來了？這時候ioc容器中是有一個dependencyservice執行個體還是兩個？這個問題留着大家思考吧，這裡不再贅述。
<code>@componentscan</code>注解對應xml配置形式中的<code><context:component-scan></code>元素，表示啟用元件掃描，spring會自動掃描所有通過注解配置的bean，然後将其注冊到ioc容器中。我們可以通過<code>basepackages</code>等屬性來指定<code>@componentscan</code>自動掃描的範圍，如果不指定，預設從聲明<code>@componentscan</code>所在類的<code>package</code>進行掃描。正因為如此，springboot的啟動類都預設在<code>src/main/java</code>下。
<code>@import</code>注解用于導入配置類，舉個簡單的例子：
現在有另外一個配置類，比如：<code>moonuserconfiguration</code>，這個配置類中有一個bean依賴于<code>moonbookconfiguration</code>中的bookservice，如何将這兩個bean組合在一起？借助<code>@import</code>即可：
需要注意的是，在4.2之前，<code>@import</code>注解隻支援導入配置類，但是在4.2之後，它支援導入普通類，并将這個類作為一個bean的定義注冊到ioc容器中。
<code>@conditional</code>注解表示在滿足某種條件後才初始化一個bean或者啟用某些配置。它一般用在由<code>@component</code>、<code>@service</code>、<code>@configuration</code>等注解辨別的類上面，或者由<code>@bean</code>标記的方法上。如果一個<code>@configuration</code>類标記了<code>@conditional</code>，則該類中所有辨別了<code>@bean</code>的方法和<code>@import</code>注解導入的相關類将遵從這些條件。
在spring裡可以很友善的編寫你自己的條件類，所要做的就是實作<code>condition</code>接口，并覆寫它的<code>matches()</code>方法。舉個例子，下面的簡單條件類表示隻有在<code>classpath</code>裡存在<code>jdbctemplate</code>類時才生效：
當你用java來聲明bean的時候，可以使用這個自定義條件類：
這個例子中隻有當<code>jdbctemplatecondition</code>類的條件成立時才會建立myservice這個bean。也就是說myservice這bean的建立條件是<code>classpath</code>裡面包含<code>jdbctemplate</code>，否則這個bean的聲明就會被忽略掉。
<code>spring boot</code>定義了很多有趣的條件，并把他們運用到了配置類上，這些配置類構成了<code>spring boot</code>的自動配置的基礎。<code>spring boot</code>運用條件化配置的方法是：定義多個特殊的條件化注解，并将它們用到配置類上。下面列出了<code>spring boot</code>提供的部分條件化注解：
條件化注解
配置生效條件
@conditionalonbean
配置了某個特定bean
@conditionalonmissingbean
沒有配置特定的bean
@conditionalonclass
classpath裡有指定的類
@conditionalonmissingclass
classpath裡沒有指定的類
@conditionalonexpression
給定的spring expression language表達式計算結果為true
@conditionalonjava
java的版本比對特定指或者一個範圍值
@conditionalonproperty
指定的配置屬性要有一個明确的值
@conditionalonresource
classpath裡有指定的資源
@conditionalonwebapplication
這是一個web應用程式
@conditionalonnotwebapplication
這不是一個web應用程式
當某些屬性的值需要配置的時候，我們一般會在<code>application.properties</code>檔案中建立配置項，然後在bean中使用<code>@value</code>注解來擷取配置的值，比如下面配置資料源的代碼。
使用<code>@value</code>注解注入的屬性通常都比較簡單，如果同一個配置在多個地方使用，也存在不友善維護的問題（考慮下，如果有幾十個地方在使用某個配置，而現在你想改下名字，你改怎麼做？）。對于更為複雜的配置，spring boot提供了更優雅的實作方式，那就是<code>@configurationproperties</code>注解。我們可以通過下面的方式來改寫上面的代碼：
<code>@configurationproperties</code>對于更為複雜的配置，處理起來也是得心應手，比如有如下配置檔案：
可以定義如下配置類來接收這些屬性
<code>@enableconfigurationproperties</code>注解表示對<code>@configurationproperties</code>的内嵌支援，預設會将對應properties class作為bean注入的ioc容器中，即在相應的properties類上不用加<code>@component</code>注解。
jvm提供了3種類加載器：<code>bootstrapclassloader</code>、<code>extclassloader</code>、<code>appclassloader</code>分别加載java核心類庫、擴充類庫以及應用的類路徑(<code>classpath</code>)下的類庫。jvm通過雙親委派模型進行類的加載，我們也可以通過繼承<code>java.lang.classloader</code>實作自己的類加載器。
何為雙親委派模型？當一個類加載器收到類加載任務時，會先交給自己的父加載器去完成，是以最終加載任務都會傳遞到最頂層的bootstrapclassloader，隻有當父加載器無法完成加載任務時，才會嘗試自己來加載。
采用雙親委派模型的一個好處是保證使用不同類加載器最終得到的都是同一個對象，這樣就可以保證java 核心庫的類型安全，比如，加載位于rt.jar包中的<code>java.lang.object</code>類，不管是哪個加載器加載這個類，最終都是委托給頂層的bootstrapclassloader來加載的，這樣就可以保證任何的類加載器最終得到的都是同樣一個object對象。檢視classloader的源碼，對雙親委派模型會有更直覺的認識：
但雙親委派模型并不能解決所有的類加載器問題，比如，java 提供了很多服務提供者接口(<code>service provider interface</code>，spi)，允許第三方為這些接口提供實作。常見的 spi 有 jdbc、jndi、jaxp 等，這些spi的接口由核心類庫提供，卻由第三方實作，這樣就存在一個問題：spi 的接口是 java 核心庫的一部分，是由bootstrapclassloader加載的；spi實作的java類一般是由appclassloader來加載的。bootstrapclassloader是無法找到 spi 的實作類的，因為它隻加載java的核心庫。它也不能代理給appclassloader，因為它是最頂層的類加載器。也就是說，雙親委派模型并不能解決這個問題。
線程上下文類加載器(<code>contextclassloader</code>)正好解決了這個問題。從名稱上看，可能會誤解為它是一種新的類加載器，實際上，它僅僅是thread類的一個變量而已，可以通過<code>setcontextclassloader(classloader cl)</code>和<code>getcontextclassloader()</code>來設定和擷取該對象。如果不做任何的設定，java應用的線程的上下文類加載器預設就是appclassloader。在核心類庫使用spi接口時，傳遞的類加載器使用線程上下文類加載器，就可以成功的加載到spi實作的類。線程上下文類加載器在很多spi的實作中都會用到。但在jdbc中，你可能會看到一種更直接的實作方式，比如，jdbc驅動管理<code>java.sql.driver</code>中的<code>loadinitialdrivers()</code>方法中，你可以直接看到jdk是如何加載驅動的：
其實講解線程上下文類加載器，最主要是讓大家在看到<code>thread.currentthread().getclassloader()</code>和<code>thread.currentthread().getcontextclassloader()</code>時不會一臉懵逼，這兩者除了在許多底層架構中取得的classloader可能會有所不同外，其他大多數業務場景下都是一樣的，大家隻要知道它是為了解決什麼問題而存在的即可。
類加載器除了加載class外，還有一個非常重要功能，就是加載資源，它可以從jar包中讀取任何資源檔案，比如，<code>classloader.getresources(string name)</code>方法就是用于讀取jar包中的資源檔案，其代碼如下：
是不是覺得有點眼熟，不錯，它的邏輯其實跟類加載的邏輯是一樣的，首先判斷父類加載器是否為空，不為空則委托父類加載器執行資源查找任務，直到bootstrapclassloader，最後才輪到自己查找。而不同的類加載器負責掃描不同路徑下的jar包，就如同加載class一樣，最後會掃描所有的jar包，找到符合條件的資源檔案。
類加載器的<code>findresources(name)</code>方法會周遊其負責加載的所有jar包，找到jar包中名稱為name的資源檔案，這裡的資源可以是任何檔案，甚至是.class檔案，比如下面的示例，用于查找array.class檔案：
運作後可以得到如下結果：
根據資源檔案的url，可以構造相應的檔案來讀取資源内容。
看到這裡，你可能會感到挺奇怪的，你不是要詳解<code>springfactoriesloader</code>嗎？上來講了一堆classloader是幾個意思？看下它的源碼你就知道了：
有了前面關于classloader的知識，再來了解這段代碼，是不是感覺豁然開朗：從<code>classpath</code>下的每個jar包中搜尋所有<code>meta-inf/spring.factories</code>配置檔案，然後将解析properties檔案，找到指定名稱的配置後傳回。需要注意的是，其實這裡不僅僅是會去classpath路徑下查找，會掃描所有路徑下的jar包，隻不過這個檔案隻會在classpath下的jar包中。來簡單看下<code>spring.factories</code>檔案的内容吧：
執行<code>loadfactorynames(enableautoconfiguration.class, classloader)</code>後，得到對應的一組<code>@configuration</code>類，
我們就可以通過反射執行個體化這些類然後注入到ioc容器中，最後容器裡就有了一系列标注了<code>@configuration</code>的javaconfig形式的配置類。
這就是<code>springfactoriesloader</code>，它本質上屬于spring架構私有的一種擴充方案，類似于spi，spring boot在spring基礎上的很多核心功能都是基于此，希望大家可以了解。
過去，事件監聽機制多用于圖形界面程式設計，比如：點選按鈕、在文本框輸入内容等操作被稱為事件，而當事件觸發時，應用程式作出一定的響應則表示應用監聽了這個事件，而在伺服器端，事件的監聽機制更多的用于異步通知以及監控和異常處理。java提供了實作事件監聽機制的兩個基礎類：自定義事件類型擴充自<code>java.util.eventobject</code>、事件的監聽器擴充自<code>java.util.eventlistener</code>。來看一個簡單的執行個體：簡單的監控一個方法的耗時。
首先定義事件類型，通常的做法是擴充eventobject，随着事件的發生，相應的狀态通常都封裝在此類中：
事件釋出之後，相應的監聽器即可對該類型的事件進行處理，我們可以在方法開始執行之前釋出一個begin事件，在方法執行結束之後釋出一個end事件，相應地，事件監聽器需要提供方法對這兩種情況下接收到的事件進行處理：
事件監聽器接口針對不同的事件釋出實際提供相應的處理方法定義，最重要的是，其方法隻接收methodmonitorevent參數，說明這個監聽器類隻負責監聽器對應的事件并進行處理。有了事件和監聽器，剩下的就是釋出事件，然後讓相應的監聽器監聽并處理。通常情況，我們會有一個事件釋出者，它本身作為事件源，在合适的時機，将相應的事件釋出給對應的事件監聽器：
對于事件釋出者（事件源）通常需要關注兩點：
在合适的時機釋出事件。此例中的methodmonitor()方法是事件釋出的源頭，其在方法執行之前和結束之後兩個時間點釋出methodmonitorevent事件，每個時間點釋出的事件都會傳給相應的監聽器進行處理。在具體實作時需要注意的是，事件釋出是順序執行，為了不影響處理性能，事件監聽器的處理邏輯應盡量簡單。
事件監聽器的管理。publisher類中提供了事件監聽器的注冊與移除方法，這樣用戶端可以根據實際情況決定是否需要注冊新的監聽器或者移除某個監聽器。如果這裡沒有提供remove方法，那麼注冊的監聽器示例将一直被methodmonitoreventpublisher引用，即使已經廢棄不用了，也依然在釋出者的監聽器清單中，這會導緻隐性的記憶體洩漏。
spring的applicationcontext容器内部中的所有事件類型均繼承自<code>org.springframework.context.appliationevent</code>，容器中的所有監聽器都實作<code>org.springframework.context.applicationlistener</code>接口，并且以bean的形式注冊在容器中。一旦在容器内釋出applicationevent及其子類型的事件，注冊到容器的applicationlistener就會對這些事件進行處理。
你應該已經猜到是怎麼回事了。
applicationevent繼承自eventobject，spring提供了一些預設的實作，比如：<code>contextclosedevent</code>表示容器在即将關閉時釋出的事件類型，<code>contextrefreshedevent</code>表示容器在初始化或者重新整理的時候釋出的事件類型......
容器内部使用applicationlistener作為事件監聽器接口定義，它繼承自eventlistener。applicationcontext容器在啟動時，會自動識别并加載eventlistener類型的bean，一旦容器内有事件釋出，将通知這些注冊到容器的eventlistener。
applicationcontext接口繼承了applicationeventpublisher接口，該接口提供了<code>void publishevent(applicationevent event)</code>方法定義，不難看出，applicationcontext容器擔當的就是事件釋出者的角色。如果有興趣可以檢視<code>abstractapplicationcontext.publishevent(applicationevent event)</code>方法的源碼：applicationcontext将事件的釋出以及監聽器的管理工作委托給<code>applicationeventmulticaster</code>接口的實作類。在容器啟動時，會檢查容器内是否存在名為applicationeventmulticaster的applicationeventmulticaster對象執行個體。如果有就使用其提供的實作，沒有就預設初始化一個simpleapplicationeventmulticaster作為實作。
最後，如果我們業務需要在容器内部釋出事件，隻需要為其注入applicationeventpublisher依賴即可：實作applicationeventpublisheraware接口或者applicationcontextaware接口(aware接口相關内容請回顧上文)。
典型的spring boot應用的啟動類一般均位于<code>src/main/java</code>根路徑下，比如<code>moonapplication</code>類：
其中<code>@springbootapplication</code>開啟元件掃描和自動配置，而<code>springapplication.run</code>則負責啟動引導應用程式。<code>@springbootapplication</code>是一個複合<code>annotation</code>，它将三個有用的注解組合在一起：
<code>@springbootconfiguration</code>就是<code>@configuration</code>，它是spring架構的注解，标明該類是一個<code>javaconfig</code>配置類。而<code>@componentscan</code>啟用元件掃描，前文已經詳細講解過，這裡着重關注<code>@enableautoconfiguration</code>。
<code>@enableautoconfiguration</code>注解表示開啟spring boot自動配置功能，spring boot會根據應用的依賴、自定義的bean、classpath下有沒有某個類 等等因素來猜測你需要的bean，然後注冊到ioc容器中。那<code>@enableautoconfiguration</code>是如何推算出你的需求？首先看下它的定義：
你的關注點應該在<code>@import(enableautoconfigurationimportselector.class)</code>上了，前文說過，<code>@import</code>注解用于導入類，并将這個類作為一個bean的定義注冊到容器中，這裡它将把<code>enableautoconfigurationimportselector</code>作為bean注入到容器中，而這個類會将所有符合條件的@configuration配置都加載到容器中，看看它的代碼：
這個類會掃描所有的jar包，将所有符合條件的@configuration配置類注入的容器中，何為符合條件，看看<code>meta-inf/spring.factories</code>的檔案内容：
以<code>datasourceautoconfiguration</code>為例，看看spring boot是如何自動配置的：
分别說一說：
<code>@conditionalonclass({ datasource.class, embeddeddatabasetype.class })</code>：當classpath中存在datasource或者embeddeddatabasetype類時才啟用這個配置，否則這個配置将被忽略。
<code>@enableconfigurationproperties(datasourceproperties.class)</code>：将datasource的預設配置類注入到ioc容器中，datasourceproperties定義為：
<code>@import({ registrar.class, datasourcepoolmetadataprovidersconfiguration.class })</code>：導入其他額外的配置，就以<code>datasourcepoolmetadataprovidersconfiguration</code>為例吧。
datasourcepoolmetadataprovidersconfiguration是資料庫連接配接池提供者的一個配置類，即classpath中存在<code>org.apache.tomcat.jdbc.pool.datasource.class</code>，則使用tomcat-jdbc連接配接池，如果classpath中存在<code>hikaridatasource.class</code>則使用hikari連接配接池。
這裡僅描述了datasourceautoconfiguration的冰山一角，但足以說明spring boot如何利用條件話配置來實作自動配置的。回顧一下，<code>@enableautoconfiguration</code>中導入了enableautoconfigurationimportselector類，而這個類的<code>selectimports()</code>通過springfactoriesloader得到了大量的配置類，而每一個配置類則根據條件化配置來做出決策，以實作自動配置。
整個流程很清晰，但漏了一個大問題：<code>enableautoconfigurationimportselector.selectimports()</code>是何時執行的？其實這個方法會在容器啟動過程中執行：<code>abstractapplicationcontext.refresh()</code>，更多的細節在下一小節中說明。
springboot整個啟動流程分為兩個步驟：初始化一個springapplication對象、執行該對象的run方法。看下springapplication的初始化流程，springapplication的構造方法中調用initialize(object[] sources)方法，其代碼如下：
初始化流程中最重要的就是通過springfactoriesloader找到<code>spring.factories</code>檔案中配置的<code>applicationcontextinitializer</code>和<code>applicationlistener</code>兩個接口的實作類名稱，以便後期構造相應的執行個體。<code>applicationcontextinitializer</code>的主要目的是在<code>configurableapplicationcontext</code>做refresh之前，對configurableapplicationcontext執行個體做進一步的設定或處理。configurableapplicationcontext繼承自applicationcontext，其主要提供了對applicationcontext進行設定的能力。
實作一個applicationcontextinitializer非常簡單，因為它隻有一個方法，但大多數情況下我們沒有必要自定義一個applicationcontextinitializer，即便是spring boot架構，它預設也隻是注冊了兩個實作，畢竟spring的容器已經非常成熟和穩定，你沒有必要來改變它。
而<code>applicationlistener</code>的目的就沒什麼好說的了，它是spring架構對java事件監聽機制的一種架構實作，具體内容在前文spring事件監聽機制這個小節有詳細講解。這裡主要說說，如果你想為spring boot應用添加監聽器，該如何實作？
spring boot提供兩種方式來添加自定義監聽器：
通過<code>springapplication.addlisteners(applicationlistener<?>... listeners)</code>或者<code>springapplication.setlisteners(collection<? extends applicationlistener<?>> listeners)</code>兩個方法來添加一個或者多個自定義監聽器
既然springapplication的初始化流程中已經從<code>spring.factories</code>中擷取到<code>applicationlistener</code>的實作類，那麼我們直接在自己的jar包的<code>meta-inf/spring.factories</code>檔案中新增配置即可：
關于springapplication的初始化，我們就說這麼多。
spring boot應用的整個啟動流程都封裝在springapplication.run方法中，其整個流程真的是太長太長了，但本質上就是在spring容器啟動的基礎上做了大量的擴充，按照這個思路來看看源碼：
① 通過springfactoriesloader查找并加載所有的<code>springapplicationrunlisteners</code>，通過調用starting()方法通知所有的springapplicationrunlisteners：應用開始啟動了。springapplicationrunlisteners其本質上就是一個事件釋出者，它在springboot應用啟動的不同時間點釋出不同應用事件類型(applicationevent)，如果有哪些事件監聽者(applicationlistener)對這些事件感興趣，則可以接收并且處理。還記得初始化流程中，springapplication加載了一系列applicationlistener嗎？這個啟動流程中沒有發現有釋出事件的代碼，其實都已經在springapplicationrunlisteners這兒實作了。
簡單的分析一下其實作流程，首先看下springapplicationrunlistener的源碼：
springapplicationrunlistener隻有一個實作類：<code>eventpublishingrunlistener</code>。①處的代碼隻會擷取到一個eventpublishingrunlistener的執行個體，我們來看看starting()方法的内容：
順着這個邏輯，你可以在②處的<code>prepareenvironment()</code>方法的源碼中找到<code>listeners.environmentprepared(environment);</code>即springapplicationrunlistener接口的第二個方法，那不出你所料，<code>environmentprepared()</code>又釋出了另外一個事件<code>applicationenvironmentpreparedevent</code>。接下來會發生什麼，就不用我多說了吧。
② 建立并配置目前應用将要使用的<code>environment</code>，environment用于描述應用程式目前的運作環境，其抽象了兩個方面的内容：配置檔案(profile)和屬性(properties)，開發經驗豐富的同學對這兩個東西一定不會陌生：不同的環境(eg：生産環境、預釋出環境)可以使用不同的配置檔案，而屬性則可以從配置檔案、環境變量、指令行參數等來源擷取。是以，當environment準備好後，在整個應用的任何時候，都可以從environment中擷取資源。
總結起來，②處的兩句代碼，主要完成以下幾件事：
判斷environment是否存在，不存在就建立（如果是web項目就建立<code>standardservletenvironment</code>，否則建立<code>standardenvironment</code>）
配置environment：配置profile以及properties
調用springapplicationrunlistener的<code>environmentprepared()</code>方法，通知事件監聽者：應用的environment已經準備好
③、springboot應用在啟動時會輸出這樣的東西：
如果想把這個東西改成自己的塗鴉，你可以研究以下banner的實作，這個任務就留給你們吧。
④、根據是否是web項目，來建立不同的applicationcontext容器。
⑤、建立一系列<code>failureanalyzer</code>，建立流程依然是通過springfactoriesloader擷取到所有實作failureanalyzer接口的class，然後在建立對應的執行個體。failureanalyzer用于分析故障并提供相關診斷資訊。
⑥、初始化applicationcontext，主要完成以下工作：
将準備好的environment設定給applicationcontext
周遊調用所有的applicationcontextinitializer的<code>initialize()</code>方法來對已經建立好的applicationcontext進行進一步的處理
調用springapplicationrunlistener的<code>contextprepared()</code>方法，通知所有的監聽者：applicationcontext已經準備完畢
将所有的bean加載到容器中
調用springapplicationrunlistener的<code>contextloaded()</code>方法，通知所有的監聽者：applicationcontext已經裝載完畢
⑦、調用applicationcontext的<code>refresh()</code>方法，完成ioc容器可用的最後一道工序。從名字上了解為重新整理容器，那何為重新整理？就是插手容器的啟動，聯系一下第一小節的内容。那如何重新整理呢？且看下面代碼：
看看這個方法的實作：
擷取到所有的<code>beanfactorypostprocessor</code>來對容器做一些額外的操作。beanfactorypostprocessor允許我們在容器執行個體化相應對象之前，對注冊到容器的beandefinition所儲存的資訊做一些額外的操作。這裡的getbeanfactorypostprocessors()方法可以擷取到3個processor：
不是有那麼多beanfactorypostprocessor的實作類，為什麼這兒隻有這3個？因為在初始化流程擷取到的各種applicationcontextinitializer和applicationlistener中，隻有上文3個做了類似于如下操作：
然後你就可以進入到<code>postprocessorregistrationdelegate.invokebeanfactorypostprocessors()</code>方法了，這個方法除了會周遊上面的3個beanfactorypostprocessor處理外，還會擷取類型為<code>beandefinitionregistrypostprocessor</code>的bean：<code>org.springframework.context.annotation.internalconfigurationannotationprocessor</code>，對應的class為<code>configurationclasspostprocessor</code>。<code>configurationclasspostprocessor</code>用于解析處理各種注解，包括：@configuration、@componentscan、@import、@propertysource、@importresource、@bean。當處理<code>@import</code>注解的時候，就會調用<自動配置>這一小節中的<code>enableautoconfigurationimportselector.selectimports()</code>來完成自動配置功能。其他的這裡不再多講，如果你有興趣，可以查閱參考資料6。
⑧、查找目前context中是否注冊有commandlinerunner和applicationrunner，如果有則周遊執行它們。
⑨、執行所有springapplicationrunlistener的finished()方法。
這就是spring boot的整個啟動流程，其核心就是在spring容器初始化并啟動的基礎上加入各種擴充點，這些擴充點包括：applicationcontextinitializer、applicationlistener以及各種beanfactorypostprocessor等等。你對整個流程的細節不必太過關注，甚至沒弄明白也沒有關系，你隻要了解這些擴充點是在何時如何工作的，能讓它們為你所用即可。
整個啟動流程确實非常複雜，可以查詢參考資料中的部分章節和内容，對照着源碼，多看看，我想最終你都能弄清楚的。言而總之，spring才是核心，了解清楚spring容器的啟動流程，那spring boot啟動流程就不在話下了。