log4j2是apache在log4j的基礎(chǔ)上，參考logback架構(gòu)實(shí)現(xiàn)的一套新的日志系統(tǒng)（我感覺(jué)是apache害怕logback了）。

log4j2的官方文檔上寫著一些它的優(yōu)點(diǎn)：

在擁有全部logback特性的情況下，還修復(fù)了一些隱藏問(wèn)題

API 分離：現(xiàn)在log4j2也是門面模式使用日志，默認(rèn)的日志實(shí)現(xiàn)是log4j2，當(dāng)然你也可以用logback（應(yīng)該沒(méi)有人會(huì)這么做）

性能提升：log4j2包含下一代基于LMAX Disruptor library的異步logger，在多線程場(chǎng)景下，擁有18倍于log4j和logback的性能

多API支持：log4j2提供Log4j 1.2, SLF4J, Commons Logging and java.util.logging (JUL) 的API支持

避免鎖定：使用Log4j2 API的應(yīng)用程序始終可以選擇使用任何符合SLF4J的庫(kù)作為log4j-to-slf4j適配器的記錄器實(shí)現(xiàn)

自動(dòng)重新加載配置：與Logback一樣，Log4j 2可以在修改時(shí)自動(dòng)重新加載其配置。與Logback不同，它會(huì)在重新配置發(fā)生時(shí)不會(huì)丟失日志事件。

高級(jí)過(guò)濾： 與Logback一樣，Log4j 2支持基于Log事件中的上下文數(shù)據(jù)，標(biāo)記，正則表達(dá)式和其他組件進(jìn)行過(guò)濾。

插件架構(gòu)： Log4j使用插件模式配置組件。因此，您無(wú)需編寫代碼來(lái)創(chuàng)建和配置Appender，Layout，Pattern Converter等。Log4j自動(dòng)識(shí)別插件并在配置引用它們時(shí)使用它們。

屬性支持：您可以在配置中引用屬性，Log4j將直接替換它們，或者Log4j將它們傳遞給將動(dòng)態(tài)解析它們的底層組件。

Java 8 Lambda支持

自定義日志級(jí)別

產(chǎn)生垃圾少：在穩(wěn)態(tài)日志記錄期間，Log4j 2 在獨(dú)立應(yīng)用程序中是無(wú)垃圾的，在Web應(yīng)用程序中是低垃圾。這減少了垃圾收集器的壓力，并且可以提供更好的響應(yīng)時(shí)間性能。

和應(yīng)用server集成：版本2.10.0引入了一個(gè)模塊log4j-appserver，以改進(jìn)與Apache Tomcat和Eclipse Jetty的集成。

在這段邏輯中，LogManager優(yōu)先通過(guò)配置文件”log4j2.component.properties”通過(guò)配置項(xiàng)”log4j2.loggerContextFactory”來(lái)獲取LoggerContextFactory，如果用戶做了對(duì)應(yīng)的配置，通過(guò)newCheckedInstanceOf方法實(shí)例化LoggerContextFactory的對(duì)象，最終的實(shí)現(xiàn)方式為：

再看構(gòu)造方法：

原來(lái)這里是為了讓osgi可以阻止啟動(dòng)。

再回到logManager：

可以看到在加載完P(guān)rovider之后，會(huì)做factory的綁定：

這里有一個(gè)getContext方法，跟進(jìn)，

直接看start：

可以看到每一個(gè)configuration都是從ConfigurationFactory拿出來(lái)的，我們先看看這個(gè)類的getInstance看看：

這里可以看到ConfigurationFactory中利用了PluginManager來(lái)進(jìn)行初始化，PluginManager會(huì)將ConfigurationFactory的子類加載進(jìn)來(lái)，默認(rèn)使用的XmlConfigurationFactory，JsonConfigurationFactory，YamlConfigurationFactory這三個(gè)子類，這里插件化加載暫時(shí)按下不表。

回到reconfigure這個(gè)方法，我們看到獲取ConfigurationFactory實(shí)例之后會(huì)去調(diào)用getConfiguration方法：

這個(gè)方法最重要的步驟就是config.start,這才是真正做配置解析的

發(fā)現(xiàn)這里面有一個(gè)比較重要的方法constructHierarchy，跟進(jìn)：

發(fā)現(xiàn)就是對(duì)剛剛獲取的configuration進(jìn)行解析，然后塞進(jìn)正確的地方?；氐絪tart方法，可以看到昨晚配置之后就是開(kāi)啟logger和appender了。

異步

AsyncAppender

一路跟進(jìn)

繼續(xù)跟進(jìn)：

這里實(shí)際打日志的方法居然是交給一個(gè)config去實(shí)現(xiàn)的。。。感覺(jué)有點(diǎn)奇怪。。跟進(jìn)看看

接下來(lái)就是callAppender了，我們直接開(kāi)始看AsyncAppender的append方法：

直接從AsyncLogger的logMessage看進(jìn)去：

這里的邏輯很簡(jiǎn)單，就是將日志相關(guān)的信息轉(zhuǎn)換成RingBufferLogEvent（RingBuffer是Disruptor的無(wú)所隊(duì)列），然后將其發(fā)布到RingBuffer中。發(fā)布到RingBuffer中，那肯定也有消費(fèi)邏輯。這時(shí)候有兩種方式可以找到這個(gè)消費(fèi)的邏輯。

找disruptor被使用的地方，然后查看，但是這樣做會(huì)很容易迷惑

按照Log4j2的尿性，這種Logger都有對(duì)應(yīng)的start方法，我們可以從start方法入手尋找

在start方法中，我們找到了一段代碼：

final RingBufferLogEventHandler[] handlers = {new RingBufferLogEventHandler};

disruptor.handleEventsWith(handlers);

直接看看這個(gè)RingBufferLogEventHandler的實(shí)現(xiàn)：

順著接口找上去，發(fā)現(xiàn)一個(gè)接口：

這個(gè)方法就是實(shí)際打日志了，AsyncLogger看起來(lái)還是比較簡(jiǎn)單的，只是使用了一個(gè)Disruptor。

插件化

之前在很多代碼里面都可以看到

final PluginManager manager = new PluginManager(CATEGORY);

manager.collectPlugins(pluginPackages);

其實(shí)整個(gè)log4j2為了獲得更好的擴(kuò)展性，將自己的很多組件都做成了插件，然后在配置的時(shí)候去加載plugin。

跟進(jìn)collectPlugins。

（不太重要的方法省略）

我們可以看到在process方法中，PluginProcessor會(huì)先收集所有的Plugin，然后在寫入文件。這樣做的好處就是可以省去反射時(shí)候的開(kāi)銷。

然后我又看了一下Plugin這個(gè)注解，發(fā)現(xiàn)它的RetentionPolicy是RUNTIME，一般來(lái)說(shuō)PluginProcessor是搭配RetentionPolicy.SOURCE，CLASS使用的，而且既然你把自己的Plugin掃描之后寫在文件中了，RetentionPolicy就沒(méi)有必要是RUNTIME了吧，這個(gè)是一個(gè)很奇怪的地方。

小結(jié)

總算是把Log4j2的代碼看完了，發(fā)現(xiàn)它的設(shè)計(jì)理念很值得借鑒，為了靈活性，所有的東西都設(shè)計(jì)成插件式?；ヂ?lián)網(wǎng)技術(shù)日益發(fā)展，各種中間件層出不窮，而作為工程師的我們更需要做的是去思考代碼與代碼之間的關(guān)系，毫無(wú)疑問(wèn)的是，解耦是最具有美感的關(guān)系。