Log4j2源碼分析系列：（一）配置加載

前言

在實際開發項目中，日誌永遠是一個繞不開的話題。本系列文章試圖以slf4j和log4j2日誌體系爲例，從源碼角度分析日誌工做原理。

學習日誌框架，首先要熟悉各種日誌框架，這裏推薦兩篇文章，就再也不贅述了。

www.cnblogs.com/rjzheng/p/1…

www.cnblogs.com/chanshuyi/p…

對於log4j2，配置文件有幾類：properties、xml、json/jsn以及yaml/yml，日常咱們用xml居多。

通常狀況下，咱們會建立log4j2.xml放到項目的/resources文件夾下。大部分使用maven管理依賴的項目也可能分環境配置，不一樣環境讀取不一樣的log4j2文件，這時它通常在/profiles/${env}/文件夾下。

大多數人，應該是「借鑑」其餘項目，把配置複製過來，再修修補補。然而你是否思考過：

1. 爲何要寫這個配置文件？不寫的話會出什麼問題？
2. 這個配置文件的命名有什麼規定嗎？爲何咱們平時見到的都是log4j2.xml，而不是其餘名字？
3. 這個配置文件是如何被加載的？

回答以上問題，就是本文的初衷。

提示

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>log4j-slf4j-impl</artifactId>
            <version>2.7</version>
        </dependency>

        <!-- log4j2 -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.7</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.7</version>
        </dependency>複製代碼

源碼

首先，咱們新建一個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的配置加載過程有更爲深刻的理解。

最後，做者水平有限，不免錯漏，歡迎指正及交流，共同進步。