Log4j2原始碼分析系列：（一）配置載入
前言
在實際開發專案中，日誌永遠是一個繞不開的話題。本系列文章試圖以slf4j和log4j2日誌體系為例，從原始碼角度分析日誌工作原理。
學習日誌框架，首先要熟悉各類日誌框架，這裡推薦兩篇文章，就不再贅述了。
對於log4j2，配置檔案有幾類：properties、xml、json/jsn以及yaml/yml，平常我們用xml居多。
一般情況下，我們會建立log4j2.xml放到專案的/resources資料夾下。大部分使用maven管理依賴的專案也可能分環境配置，不同環境讀取不同的log4j2檔案，這時它一般在/profiles/${env}/資料夾下。
大多數人，應該是“借鑑”其他專案，把配置複製過來，再修修補補。然而你是否思考過：
- 為什麼要寫這個配置檔案？不寫的話會出什麼問題？
- 這個配置檔案的命名有什麼規定嗎？為什麼我們平時見到的都是log4j2.xml，而不是其他名字？
- 這個配置檔案是如何被載入的？
回答以上問題，就是本文的初衷。
提示
1. 本文會用除錯的方法，以log4j2配置載入過程為主線，描述其工作流程；影響不大的旁枝細節會忽略，有興趣的讀者可自行查閱原始碼。
2. 多圖預警！用電腦檢視效果更佳。
3. 儘量動手操作，以加深理解。
環境準備
閱讀原始碼前，請確保引入了slf4j和log4j2依賴包，以及適配包。以maven為例，本文示例程式引入了：
<!-- slf4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
</dependency>
<!-- bridge -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log 原始碼
首先，我們新建一個java檔案，打斷點開始除錯。
進入getLogger方法。可以看到，在LoggerFactory獲取具體的Logger工廠。
進入getILoggerFactory方法。
這裡的一堆邏輯先不要管，我們最終會進入418行。
接下來進入真正的日誌繫結環節。由於我們只引入了log4j2，這裡會直接找到它，繼而繫結。StaticLoggerBinder就在log4j2的包中。
程式走到61行，可以看到這裡使用餓漢方式實現了單例。41行例項化StaticLoggerBinder，會跳到53行，我們進去看看細節。
可以看出Log4jLoggerFactory繼承了AbstractLoggerAdapter這個抽象的日誌介面卡。這個抽象介面卡中定義了若干方法，別急，馬上會提及。
回到LoggerFactory，通過方法getLoggerFactory，我們會得到剛剛創建出來的Log4jLoggerFactory：
接下來，我們進入log4j2的getLogger環節。
可以看到getLogger是個介面方法，並且有3個實現。
還記得我們剛才獲取到的Log4jLoggerFactory嗎？AbstractLoggerAdapter是它的父類，由此我們會走到AbstractLoggerAdapter的getLogger中。
getContext是AbstractLoggerAdapter的抽象方法，因此，我們下一步會走到Log4jLoggerFactory的getContext方法中。
這裡用反射定位到我們的日誌（anchor中文譯為"錨"，可以理解為類似檔案控制程式碼一類的東西），這裡得出的anchor為""，因此會進入後面的語句。
最終，我們會拿到一個AppClassLoader，LogManager會利用這個類載入器獲取上下文。
進入getContext看看：
請注意：這裡的factory是Log4jContextFactory，它是在LogManager中的靜態程式碼塊中初始化的，具體細節後面會補充。
現在，我們先進入getContext看看：
這裡的getContext是ContextSelector介面中的方法，下一步會進入ClassLoaderContextSelector中的getContext中。至於slector是怎麼初始化的，我們放在後面一起說。
下面幾步都是上下文相關操作，不再貼出，最終會回到這裡：
然後走到152行的ctx.start方法，進去看下：
到現在，終於要開始載入配置了！！！
接下來幾步比較直觀，貼圖示意：
在這裡，先建立ConfigurationFactory的例項，然後獲取配置。至於ConfigurationFactory的例項建立，這裡不再說明，可自行檢視。
接下來，進入getConfiguration方法：
進入該方法：
請注意，這裡的getFactories已經很明顯地告訴我們，這裡有4個工廠（均繼承自ConfigurationFactory ），分別處理前文提到的四類配置檔案型別：properties、xml、json/jsn以及yaml/yml。呼叫factory.getSupportedTypes()方法即可獲取到各類字尾。以xml為例：
其他型別檔案同理。
好了，回到載入配置的方法，可以看到426行程式碼判斷是否支援所有檔案型別。其實最終的核心程式碼是453~467行：
這裡嘗試用不同的條件獲取config，如果最終config為null，就會列印error日誌，告訴你沒有找到配置檔案。由於目前我們還沒有配置，就會走到466行。
現在，你可以在/resources路徑下增加一個log4j2檔案，填寫一下簡單配置，就會在459行得到config了。我們來看看getConfiguration的細節：
可以看出，這裡就是按照各種條件拼接處配置檔案的名字。
以最常見的log4j2.xml為例：
上圖中，我們已經得到了配置檔案的名字：log4j2.xml。
同時可以看到，prefix為log4j2，suffix為檔案字尾。
其中prefix（505行）是寫死在ConfigurationFactory中的：
所以，我們配置時定義的檔名，需要遵循規範，而不能隨意命名。
現在有了配置檔名，就可以載入了：
進入方法內部：
現在，url已經獲取到了。它的值是"專案路徑/target/classes/log4j2.xml"。
後面的事情就是從檔案載入內容（ 517行，涉及到類載入器的知識，請自行檢視）。
再然後，就是讀取xml檔案的內容啦：
走到這裡，就開始讀取xml檔案了。這部分內容且待下回分解。
遺留問題：LoggerManager的factory及其內部的selector是怎麼初始化的？
其實，在呼叫LogManager.getContext(cl,false);之前，LoggerManager中的靜態程式碼塊會提前被呼叫，我們看一下：
我們看89~100行程式碼即可：
進入方法ProviderUtil.getProviders()內部檢視：
可以看到provider是使用懶漢方式實現的單例（你會發現89行程式碼中ProviderUtil.hasProviders()方法執行時已經建立過了，因此這裡直接返回。注意建立過程有個細節，後面要用到），用於確定各個factory的優先順序。
我們重點看91行程式碼內部細節：
在96行，載入class，98行又將其轉換為LoggerContextFactory的子類（也就是Log4jContextFactory）。
那麼問題來了，className是啥，為啥它指定了Log4jContextFactory？
其實，在前面建立Provider例項時，構造器中會讀取log4j-core中的配置檔案，其中就包含className對應的屬性：
就這樣，得到了className：org.apache.logging.log4j.core.impl.Log4jContextFactory。
接著往下走：
可以看到這裡會用反射的方式例項化Log4jContextFactory物件，會呼叫Log4jContextFactory的無參構造器：
createContextSelector方法，就會初始化selector啦：
後續的初始化細節就不再展開啦。
最後會走到這裡：
至此，factory建立完畢。
現在，你應該可以回答文首的三個問題了吧？
總結
本文通過除錯，描述了log4j2日誌配置載入的主線（忽略了很多細節，比如可以配置path等等），後續的文章將會進一步描述配置檔案的解析過程。
希望讀者通過本文，能夠對log4j2的配置載入過程有更為深入的理解。
最後，作者水平有限，難免錯漏，歡迎指正及交流，共同進步。