7. Nested Diagnostic Contexts
在现实世界中的系统经常不得不同时处理多个客户端请求。在这样的一个典型的多线程的系统中，不同的线程将处理不同的客户端。Logging特别能够适应这种复杂的分布式的应用程序的调试和跟踪。一个常见的区分每个客户端所输出的Logging的方法是为每个客户端实例化一个新的独立的Logger。这导致Logger的大量产生，管理的成本也超过了logging本身。
唯一标识每个log请求是一个轻量级的技术。Neil Harrison 在名为“Patterns for Logging Diagnostic Messages”的书中描述了这个方法in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997).
为了唯一标识每个请求，用户把上下文信息推入NDC(Nested Diagnostic Context)中。
NDC类示例如下：
public class NDC {
// Used when printing the diagnostic
public static String get();
// Remove the top of the context from the NDC.
public static String pop();
// Add diagnostic context for the current thread.
public static void push(String message);
// Remove the diagnostic context for this thread.
public static void remove();
}
NDC如同一个堆栈样管理每个线程。注意所有the org.apache.log4j.NDC 类的方法都是静态的。假设NDC输出被开启，每次一个log 请求被生成时，适当的log4j组件为将要输出log的线程包含完整的NDC堆栈。这是在没有用户的干预的情况下做到的，用户只负责在NDC中定位正确的信息，通过在代码中正确位置插入很少的push和pop方法就行了。相反的，在代码中per-client实现方法有着很大变化。
为了演示这个点，让我们以一个发送内容到匿名客户端的servlet为例。这个servlet可以在开始执行每个其他代码前的初始化时建立NDC。上下文信息可以是客户主机的名字和其他的请求中固有的信息。
典型的信息包括cookies。因此，即使servlet同时为多个客户同时提供服务，log 被同样的代码初始化，例如属于同一个logger，依然可以被区别，因为每个客户请求将有不同的NDC堆栈。与之相比，Contrast this with the complexity of passing a freshly instantiated logger to all code exercised during the client's request。
不过，一些诡异的程序，例如虚拟主机的web server记录日志，不是一般的依靠虚拟主机的上下文，还要依靠软件的组件发出请求。近来log4j的发布版本支持多层的树形结构。这个增强允许每个虚拟主机可以处理在树型结构中属于它自己的logger。
8. 优化
一个经常引用的依靠于logging的参数是可以计算的花费。这是一个合理的概念，一个适度的应用程序可能产生成千上万个日志请求。许多努力花在测量和调试logging的优化上。Log4j要求快速和弹性：速度最重要，弹性是其次。
用户应该注意随后的优化建议。
1.日志为禁用时，日志的优化。
当日志被彻底的关闭，一个日志请求的花费等于一个方法的调用加上整数的比较时间。
在233mhz的Pentium II 机器上这个花费通常在5-50纳秒之间。
然而，方法调用包括参数构建的隐藏花费。
例如，对于logger cat，
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
引起了构建信息参数的花费，例如，转化整数i和entry[i]到一个string，并且连接中间字符串，不管信息是否被输出。这个参数的构建花费可能是很高，它主要决定于被调用的参数的大小。
避免参数构建的花费应如下，
if(logger.isDebugEnabled() {
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}
如果logger的debug被关闭这将不会招致参数构建的花费。另一方面，如果logger是debug的话，它将产生两次判断 logger是否能用的花费。一次是在debugenabled，一次是debug。这是无关紧要的，因为判断日志的能用 只占日志实际花费时间的约1%。
在Log4j里，日志请求在Logger 类的实例里。Logger 是一个类，而不是一个接口。这大量的减少了在方法调用上的弹性化的花费。
当然用户采用预处理或编译时间技术去编译出所有的日志声明。这将导致完美的执行成效。然而因为二进制应用程序不包括任何的日志声明的结果，日志不可能对那个二进制程序开启。以我的观点，以这种较大的代价来换取较小的性能优化是不值得的。
2。当日志状态为启用时，日志的优化。
这是本质上的优化logger的层次。当日志状态为开，Log4j依然需要比较请求的级别与logger的级别。然而， logger可能没有被安排一个级别；它们将从它们的father继承。这样，在继承之前，logger可能需要搜索它的ancestor。
这里有一个认真的努力使层次的搜索尽可能的快。例如，子logger仅仅连接到它的存在的father logger。
在先前展示的BasicConfigurator 例子中，名为com.foo.bar 的logger是连接到跟根logger，因此绕过 了不存在的logger com和com.foo。这将显著的改善执行的速度，特别是解析logger的层结构时。
典型的层次结构的解析的花费是logger彻底关闭时的三倍。
3.日志信息的输出时，日志的优化。
这是主要花费在日志输出的格式化和发送它到它的输出源上。这里我们再一次的付出努力以使格式化执行的尽可能快。同appender一样。实际上典型的花费大约是100-300毫秒。
详情看org.apache.log4.performance.Logging。
虽然Log4j有许多特点，但是它的第一个设计目标还是速度。一些Log4j的组件已经被重写过很多次以改善性能。不过，投稿者经常提出了新的优化。你应该满意的知道，以SimpleLayout的配置执行测试已经展示了Log4j的输出同System.out.println一样快。
9. 总结
Log4j是一个用java写成的流行的日志包。一个它与众不同的特点是在logger中的继承的概念。用logger的继承可以以任意的间隔控制日志的状态输出。这个减少了体积和最小化日志的代价。
易管理性是Log4j API的优点之一。只要日志定义被加入到代码中，它们就可以用配置文件来控制。它们可以有选择的被禁用，并且发送到不同的多个输出源上，以用户选择好的格式。
Log4j的包被设计成，不需花费沉重的执行代价就可以保留它们在产品中。
