1996 年初，欧洲安全电子市场(EU SEMPER)项目组决定编写自己的日志记录API，后来这个API演变成了Log4j。Log4j是一个开放源码项目，一个非常流行的Java日志记录包。它允许开发者向代码中插入日志记录语句，还允许在不修改应用程序源码的情况下修改日志记录的行为。几乎每一个项目都会使用日志记录，但是由于日志记录不是项目的核心，因此受重视的程度一般不是很高。我们认为使用日志记录是一件非常严肃的事情，而且做好使用日志记录的规划比单纯记录日志本身更加重要。本文将比较全面的阐述Log4j的设计原理和使用方法。

日志记录 日志记录记录的是应用程序运行的轨迹。我们可以通过查看这些轨迹来调试应用程序，这可能也是日志记录最为流行的用法了。但是我们必须意识到规划良好的日志记录中还含有丰富的信息，通过手工的方式或借助一些工具(大多数时候需要自己来书写这些工具)来分析挖掘这些信息。例如，如果我们在规划中指出必须记录用户的每一次操作，记录的样式为 [日志信息]-[操作开始的时间]-[日志级别]-[日志类别]-[用户名]-[操作名]-[消息]，这只是我们假设的一种样式，实际的日志中一般会含有比这更加丰富的信息。为了更好的理解，我们根据该样式构造了一些日志记录(其中日志类别org.fulin.Main、org.fulin.Parser 和org.fulin.UserOperator使用了不同的样式)：
[日志信息]-[2006-07-30 08:54:20]-[INFO]-[org.fulin.Main]-[具体的消息]
[日志信息]-[2006-07-30 08:55:20]-[INFO]-[org.fulin.UserOperator]
-[User1]-[查询报表1]-[具体的消息]
[日志信息]-[2006-07-30 08:55:30]-[INFO]-[org.fulin.UserOperator]
-[User1]-[查询报表2]-[具体的消息]
[日志信息]-[2006-07-30 08:56:01]-[INFO]-[org.fulin.Parser]-[具体的消息]
[日志信息]-[2006-07-30 08:57:26]-[INFO]-[org.fulin.UserOperator]
-[User2]-[添加用户User3]-[具体的消息]
[日志信息]-[2006-07-30 08:58:20]-[INFO]-[org.fulin.UserOperator]-[User1]
-[查询报表3]-[具体的消息]
[日志信息]-[2006-07-30 08:59:38]-[INFO]-[org.fulin.UserOperator]-[User3]-[查询报表1]-[具体的消息]
[日志信息]-[2006-07-30 08:59:39]-[INFO]-[org.fulin.UserOperator]-[User2]-[退出系统]-[具体的消息]从上面的日志记录中我们很容易抽取出某一用户的操作列表，如对于用户User1我们的结果为：
[日志信息]-[2006-07-30 08:55:20]-[INFO]-[org.fulin.UserOperator]-[User1]-[查询报表1]-[具体的消息]
[日志信息]-[2006-07-30 08:55:30]-[INFO]-[org.fulin.UserOperator]-[User1]-[查询报表2]-[具体的消息]
[日志信息]-[2006-07-30 08:58:20]-[INFO]-[org.fulin.UserOperator]-[User1]-[查询报表3]-[具体的消息]这样我们就得到了某一时间段中User1的操作列表，可以利用这一列表来进行安全分析。我们还可以从另外的角度来分析上面的日志记录，如我们很容易统计出操作(日志类别为org.fulin.UserOperator)发生的总次数(6 次)，其中操作[查询报表1]为2次，[查询报表2]为1次，[查询报表3]为1次，[添加用户User3]为1次，[退出系统]为1次。这样我们就可以得出系统中的那些操作用户使用的比较频繁。以上我们从两个角度对日记记录中的信息进行了简单的挖掘，实际中待挖掘的方面要丰富的多，这取决于您的意图和您的想象力。这里我们还要特别强调一下：所有这一切都需要有使用日志记录的良好规划。如果规划不好(即日志记录没有规律性)，那么我们挖掘时的任务就会非常繁重或者使挖掘成为一个不可能的任务。文章到了这里我们要来描述日志记录的最为流行的用法了，即调试应用程序。我们在调试应用程序时一般会使用两种方法，除了日志记录之外，还有debugger调试器。我们不想把他们放到一起来描述，因为这是两个完全不同的问题，虽然他们都用来调试应用程序。使用debugger调试器我们可以清楚的知道引发错误的上下文及其相关信息，也可以使用单步执行、设置断点、检查变量以及暂挂和恢复线程等等比较高级的能力，但是尽管这样它也不能替代日志记录，同样日志记录也不能替代debugger调试器。我们要结合使用这两种方法，不同的场景使用不同的方法会有更好的效果。我们认为使用日志记录来调试应用程也应该充分考虑软件的开发周期。这里我们只考虑软件开发周期中的与日志记录有关的两个阶段：
* 开发阶段，用来记录应用程序的方方面面和各种细节，非常详细，使得一看到它就知道那里出了问题，出了什么样的问题。
* 出品阶段，要能够记录各种级别的错误和警告，同时也要适度记录应用程序正常运行的关键信息，这些信息可以给相关人员(开发人员、测试人员、用户等)极大的信心，使他们可以毫不犹豫的告诉您–瞧我们的软件在正常的运行。如一个好的web服务器的启动日志记录不仅要包含错误和警告，还要包含服务器正在启动，正在加载某某组件等等，最后还要提示启动是成功还是失败。阅读到这里我们就应该着手实现我们的日志记录了。比较幸运的是我们有好多日志记录软件包可选，这就使我们不必关心日志记录的细节，只要把主要的精力放到日志记录的规划上就好了。我们选择的是Log4j，文章的余下部分将主要介绍这个Java日志记录软件包。

log4j的特性
log4j的特性列表：
* 在运行速度方面进行了优化
* 使用基于名称的日志(logger)层次结构
* 是fail-stop的
* 是线程安全的
* 不受限于预定义的实用工具集
* 可以在运行时使用property和xml两种格式的文件来配置日志记录的行为
* 在一开始就设计为能够处理Java异常
* 能够定向输出到文件(file)、控制台(console)、java.io.OutputStream、java.io.Writer、远程服务器、远程Unix Syslog守护者、远程JMS监听者、NT EventLog或者发送e-mail
* 使用DEBUG、INFO、WARN、ERROR和FATAL五5个级别
* 可以容易的改变日志记录的布局(Layout)
* 输出日志记录的目的地和写策略可以通过实现Appender接口来改变
* 支持为每个日志(logger)附加多个目的地(appender)
* 提供国际化支持

log4j的设计原理Log4j有三个主要的组件：Logger、Appender和Layout。这三个组件相互配合使得我们可以获得非常强大的日志记录的能力。
Logger
Logger的名称是区分大小写的，依据名称可以确定其层次结构(即父子关系)，规则如下：
* 如果Logger A的名称后跟一个点(.)是Logger B的名称的前缀就认为Logger A是Logger B的祖先。
* 如果在Logger A和Logger B之间，Logger B没有任何其它的祖先就认为Logger A是Logger B的父亲。在Logger的层次结构的最顶层是root logger，它会永远存在，而且不能通过名字取到。
Loger x.y是Logger x.y.z的祖先，因为x.y.是x.y.z的前缀，这符合规则的前一条。另外在Logger x.y和Logger x.y.z之间，Logger x.y.z没有其它的祖先，因此Logger x.y是Logger x.y.z的父亲，这符合规则的后一条。这样我们依据上面的规则就可以构造出如图1所示的Logger的层次结构。每一个Logger都有一个Level，根据该Level的值Logger决定是否处理对应的日志请求。如果Level没有被设置，可以从祖先那里继承。如果Logger C没有被设置Level，那么它将沿着它的层次结构向上查找,如果找到就继承并结束，否则会一直查找到root logger结束。因为log4j在设计时保证root […]

[@more@]