前言

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

學習日誌框架，首先要熟悉各類日誌框架，這裡推薦幾篇文章，就不再贅述了。

https://www.cnblogs.com/rjzheng/p/10042911.html

https://www.cnblogs.com/chanshuyi/p/something_about_java_log_framework.html

https://blog.csdn.net/xktxoo/article/details/76359299

https://stackify.com/compare-java-logging-frameworks/

對於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的配置加載過程有更為深入的理解。

 

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