Java日志

对于一个应用程序来说日志记录是必不可少的一部分。线上问题追踪，基于日志的业务逻辑统计分析等都离不日志。java领域存在多种日志框架，目前常用的日志框架包括Log4j 1，Log4j 2，Commons Logging，Slf4j，Logback，Jul。

参考：

https://www.cnblogs.com/chenhongliang/p/5312517.html

https://www.jianshu.com/p/190c56429ec4

Java常用日志框架类别

• Log4j Apache Log4j是一个基于Java的日志记录工具。它是由Ceki Gülcü首创的，现在则是Apache软件基金会的一个项目。 Log4j是几种Java日志框架之一。

• Log4j 2 Apache Log4j 2是apache开发的一款Log4j的升级产品。

• Commons Logging Apache基金会所属的项目，是一套Java日志接口，之前叫Jakarta Commons Logging，后更名为Commons Logging。

• Slf4j 类似于Commons Logging，是一套简易Java日志门面，本身并无日志的实现。（Simple Logging Facade for Java，缩写Slf4j）。

• Logback 一套日志组件的实现(Slf4j阵营)。

• Jul (Java Util Logging),自Java1.4以来的官方日志实现。

看了上面的介绍是否会觉得比较混乱，这些日志框架之间有什么异同，都是由谁在维护，在项目中应该如何选择日志框架，应该如何使用? 下文会逐一介绍。

Java常用日志框架历史

• 1996年早期，欧洲安全电子市场项目组决定编写它自己的程序跟踪API(Tracing API)。经过不断的完善，这个API终于成为一个十分受欢迎的Java日志软件包，即Log4j。后来Log4j成为Apache基金会项目中的一员。

• 期间Log4j近乎成了Java社区的日志标准。据说Apache基金会还曾经建议Sun引入Log4j到java的标准库中，但Sun拒绝了。

• 2002年Java1.4发布，Sun推出了自己的日志库JUL(Java Util Logging),其实现基本模仿了Log4j的实现。在JUL出来以前，Log4j就已经成为一项成熟的技术，使得Log4j在选择上占据了一定的优势。

• 接着，Apache推出了Jakarta Commons Logging，JCL只是定义了一套日志接口(其内部也提供一个Simple Log的简单实现)，支持运行时动态加载日志组件的实现，也就是说，在你应用代码里，只需调用Commons Logging的接口，底层实现可以是Log4j，也可以是Java Util Logging。

• 后来(2006年)，Ceki Gülcü不适应Apache的工作方式，离开了Apache。然后先后创建了Slf4j(日志门面接口，类似于Commons Logging)和Logback(Slf4j的实现)两个项目，并回瑞典创建了QOS公司，QOS官网上是这样描述Logback的：The Generic，Reliable Fast&Flexible Logging Framework(一个通用，可靠，快速且灵活的日志框架)。

• 现今，Java日志领域被划分为两大阵营：Commons Logging阵营和Slf4j阵营。
  Commons Logging在Apache大树的笼罩下，有很大的用户基数。但有证据表明，形式正在发生变化。2013年底有人分析了GitHub上30000个项目，统计出了最流行的100个Libraries，可以看出Slf4j的发展趋势更好：

• Apache眼看有被Logback反超的势头，于2012-07重写了Log4j 1.x，成立了新的项目Log4j 2, Log4j 2具有Logback的所有特性。

java常用日志框架关系

• Log4j 2与Log4j 1发生了很大的变化，Log4j 2不兼容Log4j 1。

• Commons Logging和Slf4j是日志门面(门面模式是软件工程中常用的一种软件设计模式，也被称为正面模式、外观模式。它为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用)。Log4j和Logback则是具体的日志实现方案。可以简单的理解为接口与接口的实现，调用者只需要关注接口而无需关注具体的实现，做到解耦。

• 比较常用的组合使用方式是Slf4j与Logback组合使用，Commons Logging与Log4j组合使用。

• Logback必须配合Slf4j使用。由于Logback和Slf4j是同一个作者，其兼容性不言而喻。

Commons Logging与Slf4j实现机制对比

Commons Logging实现机制

Commons Logging是通过动态查找机制，在程序运行时，使用自己的ClassLoader寻找和载入本地具体的实现。详细策略可以查看commons-logging-*.jar包中的org.apache.commons.logging.impl.LogFactoryImpl.java文件。由于Osgi不同的插件使用独立的ClassLoader，Osgi的这种机制保证了插件互相独立, 其机制限制了Commons Logging在Osgi中的正常使用。

Slf4j实现机制

Slf4j在编译期间，静态绑定本地的Log库，因此可以在Osgi中正常使用。它是通过查找类路径下org.slf4j.impl.StaticLoggerBinder，然后在StaticLoggerBinder中进行绑定。

项目中选择日志框架选择

如果是在一个新的项目中建议使用Slf4j与Logback组合，这样有如下的几个优点。

• Slf4j实现机制决定Slf4j限制较少，使用范围更广。由于Slf4j在编译期间，静态绑定本地的LOG库使得通用性要比Commons Logging要好。

• Logback拥有更好的性能。Logback声称：某些关键操作，比如判定是否记录一条日志语句的操作，其性能得到了显著的提高。这个操作在Logback中需要3纳秒，而在Log4J中则需要30纳秒。LogBack创建记录器（logger）的速度也更快：13毫秒，而在Log4J中需要23毫秒。更重要的是，它获取已存在的记录器只需94纳秒，而Log4J需要2234纳秒，时间减少到了1/23。跟JUL相比的性能提高也是显著的。

• Commons Logging开销更高

# 在使Commons Logging时为了减少构建日志信息的开销，通常的做法是
if(log.isDebugEnabled()){
  log.debug("User name： " +
    user.getName() + " buy goods id ：" + good.getId());
}

# 在Slf4j阵营，你只需这么做：
log.debug("User name：{} ,buy goods id ：{}", user.getName(),good.getId());

# 也就是说，Slf4j把构建日志的开销放在了它确认需要显示这条日志之后，减少内存和Cup的开销，使用占位符号，代码也更为简洁

• Logback文档免费。Logback的所有文档是全面免费提供的，不象Log4J那样只提供部分免费文档而需要用户去购买付费文档。

Slf4j用法

Slf4j与其它日志组件的关系说明

• Slf4j的设计思想比较简洁，使用了Facade设计模式，Slf4j本身只提供了一个slf4j-api-version.jar包，这个jar中主要是日志的抽象接口，jar中本身并没有对抽象出来的接口做实现。
• 对于不同的日志实现方案(例如Logback，Log4j...)，封装出不同的桥接组件(例如logback-classic-version.jar，slf4j-log4j12-version.jar)，这样使用过程中可以灵活的选取自己项目里的日志实现。

Slf4j与其它日志组件调用关系图

Slf4j与其他各种日志组件的桥接说明

jar包名	说明
slf4j-log4j12-1.7.13.jar	Log4j1.2版本的桥接器，你需要将Log4j.jar加入Classpath。
slf4j-jdk14-1.7.13.jar	java.util.logging的桥接器，Jdk原生日志框架。
slf4j-nop-1.7.13.jar	NOP桥接器，默默丢弃一切日志。
slf4j-simple-1.7.13.jar	一个简单实现的桥接器，该实现输出所有事件到System.err. 只有Info以及高于该级别的消息被打印，在小型应用中它也许是有用的。
slf4j-jcl-1.7.13.jar	Jakarta Commons Logging 的桥接器. 这个桥接器将Slf4j所有日志委派给Jcl。
logback-classic-1.0.13.jar(requires logback-core-1.0.13.jar)	Slf4j的原生实现，Logback直接实现了Slf4j的接口，因此使用Slf4j与Logback的结合使用也意味更小的内存与计算开销

• 具体的接入方式参见下图
  

 

 

 

1.日志体系

 

日志分层

日志体系大致如上图所示，我们的系统会直接与接口层交互。当然也可以直接使用具体的日志实现，比如logback，但是按照面向接口编程的理念，建议不要在系统中直接使用具体日志系统的代码，否则后续若要更换日志系统，会相当麻烦。

 

2.bridge层

 

 

先盗slf4j官网一张图

concrete-bindings.png

 

其中Adaptation layer是bridge层。为什么需要bridge？其实slf4j(slf4j-api.jar)只提供了一个门面，并没有具体的实现。像最左边的那一列，如果我们的系统中只引入了slf4j-api.jar，那么日志无法输出。若想正常输出日志，还需引入真正写日志到文件的jar包。

图中深蓝色的日志框架并不需要bridge层就可以使用slf4j进行日志打印，原因在于这些日志框架都直接实现了slf4j。而log4j和jdk log并没有实现slf4j(废话，jdk的log怎么可能依赖于第三方的框架。。。)，因此需要一个中间层去转化一下。

总结一下，充当bridge层的jar包：slf4j-log412.jar 和 slf4j-jdk14.jar

3.其他框架转接到slf4j

 

 

也是先盗图一张

legacy.png

 

假设系统中使用了jcl作为了门面，那么对jcl api的调用如何转化为对slf4j api的调用？(常见的Spring框架的日志框架就是jcl)

slf4j提供了jar包将别的日志api的调用转调到slf4j的api上。
jcl-over-slf4j.jar : jcl >>> slf4j
log4j-over-slf4j.jar : log4j >>> slf4j
jul-to-slf4j.jar : jdk api >>> slf4j
前两个包需要分别替换commons-logging.jar和log4j.jar。

在上述桥接、转换过程中，有一个限制就是转调到slf4j的日志框架不能与当前slf4j桥接的日志框架相同。举个例子，系统使用slf4j和log4j打印日志，我们又引入了log4j-over-slf4j.jar去把log4j转调到slf4j上，这就会出现如下递归调用情况：
业务系统 ---> slf4j api ---> log4j api --->转调到 slf4j api ---> log4j api --->....

4.log4j2与slf4j

先区别几个包
slf4j-log4j12.jar: slf4j提供的slf4j到log4j1.x的bridge；
log4j-over-slf4j.jar: slf4j提供的log4j转调slf4j，一般是在业务系统直接调用了log4j的api，但是想转调到slf4j，再通过别的日志框架进行日志输出的情况；
log4j-slf4j-impl.jar: log4j2提供的slf4j到log4j2.x的bridge；

5.总结

若业务系统中使用的是日志门面，则参考concrete-bindings.png;
若业务系统没有使用日志门面，但是想更换为别的具体日志系统，则参考legacy.png，先转调到slf4j api，再通过别的日志系统输出日志。