SimpleLayout類

SimpleLayout是最簡單的Layout，它只是打印消息級別和渲染后的消息，并且不處理異常信息。不過這里很奇怪為什么把sbuf作為成員變量？個人感覺這個會在多線程中引起問題~~~~其代碼如下：

測試用例：

測試結果：

HTMLLayout類

HTMLLayout將日志消息打印成HTML格式，Log4J中HTMLLayout的實現中將每一條日志信息打印成表格中的一行，因而包含了一些Header和Footer信息。并且HTMLLayout類還支持配置是否打印位置信息和自定義title。最終HTMLLayout的日志打印格式如下：

以上所有HTML內容信息都要經過轉義，即: ’<’ => &lt; ‘>’ => &gt; ‘&’ => &amp; ‘”’ => &quot;從上信息可以看到HTMLLayout支持異常處理，并且它也實現了getContentType()方法：

測試用例：

XMLLayout類

XMLLayout將日志消息打印成XML文件格式，打印出的XML文件不是一個完整的XML文件，它可以外部實體引入到一個格式正確的XML文件中。如XML文件的輸出名為abc，則可以通過以下方式引入：

XMLLayout還支持設置是否支持打印位置信息以及MDC（Mapped Diagnostic Context）信息，他們的默認值都為false：

XMLLayout的輸出格式如下：

從以上日志格式也可以看出XMLLayout已經處理了異常信息。

測試用例：

TTCCLayout類

TTCCLayout貌似有特殊含義，不過這個我還不太了解具體是什么意思。從代碼角度上，該Layout包含了time, thread, category, nested diagnostic context information, and rendered message等信息。其中是否打印thread(threadPrinting), category(categoryPrefixing), nested diagnostic(contextPrinting)信息是可以配置的。TTCCLayout不處理異常信息。其中format()函數代碼：

這里唯一需要解釋的就是dateFormat()函數，它是在其父類DateLayout中定義的，用于格式化時間信息。DateLayout支持的時間格式有：

NULL_DATE_FORMAT：NULL，此時dateFormat字段為null

RELATIVE_TIME_DATE_FORMAT：RELATIVE，默認值，此時dateFormat字段為RelativeTimeDateFormat實例。其實現即將LoggingEvent中的timestamp-startTime（RelativeTimeDateFormat實例化是初始化）。

ABS_TIME_DATE_FORMAT：ABSOLUTE，此時dateFormat字段為AbsoluteTimeDateFormat實例。它將時間信息格式化成HH:mm:ss,SSS格式。這里對性能優化有一個可以參考的地方，即在格式化是，它只是每秒做一次格式化計算，而對后綴sss的變化則直接計算出來。

DATE_AND_TIME_DATE_FORMAT：DATE，此時dateFormat字段為DateTimeDateFormat實例，此時它將時間信息格式化成dd MMM yyyy HH:mm:ss,SSS。

ISO8601_DATE_FORMAT：ISO8601，此時dateFormat字段為ISO8601DateFormat實例，它將時間信息格式化成yyyy-MM-dd HH:mm:ss,SSS。

以及普通的SimpleDateFormat中設置pattern的支持。

Log4J推薦使用自己定義的DateFormat，其文檔上說Log4J中定義的DateFormat信息有更好的性能。

測試用例：

測試結果：

PatternLayout類

個人感覺PatternLayout是Log4J中最常用也是最復雜的Layout了。PatternLayout的設計理念是LoggingEvent實例中所有的信息是否顯示、以何種格式顯示都是可以自定義的，比如要用PatternLayout實現TTCCLayout中的格式，可以這樣設置：

該測試用例的運行結果和TTCCLayout中默認的結果是一樣的。完整的，PatternLayout中可以設置的參數有（模擬C語言的printf中的參數）：

而且PatternLayout還支持在格式字符串前加入精度信息：

%-min.max[conversionChar]，如%-20.30c表示顯示日志名，左對齊，最短20個字符，最長30個字符，不足用空格補齊，超過的截取（從后往前截取）。

因而PatternLayout實現中，最主要要解決的是如何解析上述定義的格式。實現上述格式的解析，一種最直觀的方法是每次遍歷格式字符串，當遇到’%’，則進入解析模式，根據’%’后不同的字符做不同的解析，對其他字符，則直接作為輸出的字符。這種代碼會比較直觀，但是它每次都要遍歷格式字符串，會引起一些性能問題，而且如果在將來引入新的格式字符，需要直接改動PatternLayout代碼，不利于可擴展性。

為了解決這個問題，PatternLayout引入了解釋器模式：

其中PatternParser負責解析PatternLayout中設置的conversion pattern，它將conversion pattern解析出一個鏈狀的PatternConverter，而后在每次格式化LoggingEvent實例是，只需要遍歷該鏈即可：

在解析conversion pattern時，PatternParser使用了有限狀態機的方法：

即PatternParser定義了五種狀態，初始化時LITERAL_STATE，當遍歷完成，則退出；否則，如果當前字符不是’%’，則將該字符添加到currentLiteral中，繼續遍歷；否則，若下一字符是’%’，則將其當做基本字符處理，若下一字符是’n’，則添加換行符，否則，將之前收集的literal字符創建LiteralPatternConverter實例，添加到相應的PatternConverter鏈中，清空currentLiteral實例，并添加下一字符，解析器進入CONVERTER_STATE狀態：

對CONVERTER_STATE狀態，若當前字符是’-‘，則表明左對齊；若遇到’.’，則進入DOT_STATE狀態；若遇到數字，則進入MIN_STATE狀態；若遇到其他字符，則根據字符解析出不同的PatternConverter，并且如果存在可選項信息（’{}’中的信息），一起提取出來，并將狀態重新設置成LITERAL_STATE狀態：

進入MIN_STATE狀態，首先判斷當期字符是否為數字，若是，則繼續計算精度的最小值；若遇到’.’，則進入DOT_STATE狀態；否則，根據字符解析出不同的PatternConverter，并且如果存在可選項信息（’{}’中的信息），一起提取出來，并將狀態重新設置成LITERAL_STATE狀態：

進入DOT_STATE狀態，如果當前字符是數字，則進入MAX_STATE狀態；格式出錯，回到LITERAL_STATE狀態：

進入MAX_STATE狀態，若為數字，則繼續計算最大精度值，否則，根據字符解析出不同的PatternConverter，并且如果存在可選項信息（’{}’中的信息），一起提取出來，并將狀態重新設置成LITERAL_STATE狀態：

對finalizeConvert()方法的實現，只是簡單的根據不同的格式字符創建相應的PatternConverter，而且各個PatternConverter中的實現也是比較簡單的，有興趣的童鞋可以直接看源碼，這里不再贅述。

PatternLayout的這種有限狀態機的設置是代碼結構更加清晰，而引入解釋器模式，以后如果需要增加新的格式字符，只需要添加一個新的PatternConverter以及一小段case語句塊即可，減少了因為需求改變而引起的代碼的傾入性。

EnhancedPatternLayout類

在Log4J文檔中指出PatternLayout中存在同步問題以及其他問題，因而推薦使用EnhancedPatternLayout來替換它。對這句話我個人并沒有理解，首先關于同步問題，感覺其他Layout中也有涉及到，而且對一個Appender來說，它的doAppend()方法是同步方法，因而只要不在多個Appender之間共享同一個Layout實例，也不會出現同步問題；更令人費解的是關于其他問題的表述，說實話，我還沒有發現具體有什么其他問題，所以期待其他人來幫我解答。

但是不管怎么樣，我們還是來簡單的了解一下EnhancedPatternLayout的一些設計思想吧。EnhancedPatternLayout提供了和PatternLayout相同的接口，只是其內部實現有一些改變。EnhancedPatternLayout引入了LoggingEventPatternConverter，它會根據不同的子類的定義從LoggingEvent實例中獲取相應的信息；使用PatternParser解析出關于patternConverters和FormattingInfo兩個相對獨立的集合，遍歷這兩個集合，構建出兩個對應的數組，以在以后的解析中使用。大體上，EnhancedPatternLayout還是類似PatternLayout的設計。這里不再贅述。

NDC和MDC

有時候，一段相同的代碼需要處理不同的請求，從而導致一些看似相同的日志其實是在處理不同的請求。為了避免這種情況，從而使日志能夠提供更多的信息。

要實現這種功能，一個簡單的做法每個請求都有一個唯一的ID或Name，從而在處理這樣的請求的日志中每次都寫入該信息從而區分看似相同的日志。但是這種做法需要為每個日志打印語句添加相同的代碼，而且這個ID或Name信息要一直隨著方法調用傳遞下去，非常不方便，而且容易出錯。Log4J提供了兩種機制實現類似的需求：NDC和MDC。NDC是Nested Diagnostic Contexts的簡稱，它提供一個線程級別的棧，用戶向這個棧中壓入信息，這些信息可以通過Layout顯示出來。MDC是Mapped Diagnostic Contexts的簡稱，它提供了一個線程級別的Map，用戶向這個Map中添加鍵值對信息，這些信息可以通過Layout以指定Key的方式顯示出來。

NDC主要的使用接口有：

即使用前，將和當前上下文信息push如當前線程棧，使用完后pop出來：

 1 @Test
 2 public void testNDC() {
 3     PatternLayout layout = new PatternLayout();
 4     layout.setConversionPattern("%x - %m%n");
 5     configSetup(layout);
 6     
 7     NDC.push("Levin");
 8     NDC.push("Ding");
 9     logTest();
10     NDC.pop();
11     NDC.pop();
12 }
13 Levin Ding - Begin to execute testBasic() method
14 Levin Ding - Executing
15 Levin Ding - Catching an Exception
16 java.lang.Exception: Deliberately throw an Exception
17     at levin.log4j.layout.LayoutTest.logTest(LayoutTest.java:86)
18     
19 Levin Ding - Execute testBasic() method finished.

 1 @Test
 2 public void testMDC() {
 3     PatternLayout layout = new PatternLayout();
 4     layout.setConversionPattern("IP:%X{ip} Name:%X{name} - %m%n");
 5     configSetup(layout);
 6     
 7     MDC.put("ip", "127.0.0.1");
 8     MDC.put("name", "levin");
 9     logTest();
10     MDC.remove("ip");
11     MDC.remove("name");
12 }
13 IP:127.0.0.1 Name:levin - Begin to execute testBasic() method
14 IP:127.0.0.1 Name:levin - Executing
15 IP:127.0.0.1 Name:levin - Catching an Exception
16 java.lang.Exception: Deliberately throw an Exception
17     at levin.log4j.layout.LayoutTest.logTest(LayoutTest.java:100)
18     
19 IP:127.0.0.1 Name:levin - Execute testBasic() method finished.