Log4j2原始碼分析系列:(一)配置載入
前言
在實際開發專案中,日誌永遠是一個繞不開的話題。本系列文章試圖以slf4j和log4j2日誌體系為例,從原始碼角度分析日誌工作原理。
學習日誌框架,首先要熟悉各類日誌框架,這裡推薦兩篇文章,就不再贅述了。
https://www.cnblogs.com/rjzheng/p/10042911.html
https://www.cnblogs.com/chanshuyi/p/something_about_java_log_framework.html
對於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>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>
IDE我用的是idea,用其他IDE的類似。
原始碼
首先,我們新建一個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的配置載入過程有更為深入的理解。
最後,作者水平有限,難免錯漏,歡迎指正及交流,共同進步。