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.