前言
在實際開發項目中，日志永遠是一個繞不開的話題。本系列文章試圖以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>
源碼
首先，我們新建一個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創建完畢。
現在，你應該可以回答文首的三個問題了吧？
1. 如果沒有配置log4j2.xml，或是名字寫錯，會給出錯誤信息：ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.
2. xml文件加載過程如上。
總結
本文通過調試，描述了log4j2日志配置加載的主線（忽略了很多細節，比如可以配置path等等），后續的文章將會進一步描述配置文件的解析過程。
希望讀者通過本文，能夠對log4j2的配置加載過程有更為深入的理解。
最后，作者水平有限，難免錯漏，歡迎指正及交流，共同進步。