Java日志框架

转载自：http://www.javashuo.com/article/p-qgnyfndm-bp.html

1、Java日志框架概述

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

一、日志框架类别

• 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以来的官方日志实现。

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

二、日志框架历史

• 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的全部特性。

三、日志框架关系

• 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那样只提供部分免费文档而须要用户去购买付费文档。

2、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的结合使用也意味更小的内存与计算开销

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

3、Slf4j源码分析

一、slf4j-api-version.jar中几个核心类与接口

类与接口	用途
org.slf4j.LoggerFactory(class)	给调用方提供的建立Logger的工厂类，在编译时绑定具体的日志实现组件
org.slf4j.Logger(interface)	给调用方提供的日志记录抽象方法，例如debug(String msg),info(String msg)等方法
org.slf4j.ILoggerFactory(interface)	获取的Logger的工厂接口，具体的日志组件实现此接口
org.slf4j.helpers.NOPLogger(class)	对org.slf4j.Logger接口的一个没有任何操做的实现，也是Slf4j的默认日志实现
org.slf4j.impl.StaticLoggerBinder(class)	与具体的日志实现组件实现的桥接类，具体的日志实现组件须要定义org.slf4j.impl包，并在org.slf4j.impl包下提供此类，注意在slf4j-api-version.jar中不存在org.slf4j.impl.StaticLoggerBinder，在源码包slf4j-api-version-source.jar中才存在此类

Slf4j调用过程源码分析，只加入slf4j-api-version.jar，不加入任何实现包

示例代码参见：https://github.com/chlsmile/slf4j-demo

pom核心配置以下

<dependencies>
    <!--只有slf4j-api依赖-->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.13</version>
    </dependency>
  </dependencies>

程序入口类以下

源码分析

• 1)调用LoggerFactory的getLogger()方法建立Logger
  

• 2)调用LoggerFactory的getILoggerFactory方法来建立ILoggerFactory
  

• 3)调用LoggerFactory的performInitialization方法来进行初始化
  

• 4)调用LoggerFactory的bind()方法
  

• 5)调用LoggerFactory的findPossibleStaticLoggerBinderPathSet()方法获取StaticLoggerBinderPath集合
  

• 6)调用LoggerFactory的reportMultipleBindingAmbiguity()方法，记录绑定的StaticLoggerBinder信息
  

• 7)LoggerFactory的reportMultipleBindingAmbiguity()方法
  

• 8)LoggerFactory的bind()方法找不到StaticLoggerBinder，抛出NoClassDefFoundError异常
  

• 9)LoggerFactory的bind()方法捕获NoClassDefFoundError异常，匹配到StaticLoggerBinder关键词记录信息到控制台
  

• 10)LoggerFactory的performInitialization()方法内部调用bind()方法结束
  

• 11)LoggerFactory的getLogger()方法内部getILoggerFactory()方法调用完成，建立出NOPLoggerFactory，而后由NOPLoggerFactory调用内部的getLogger()方法，建立出NOPLogger
  

• 12)App类内部的logger实际为NOPLogger,调用logger.info()方法实际调用的是NOPLogger的info方法
  

二、Slf4j调用过程源码分析

加入slf4j-api-version.jar，与Logback组件

Slf4j做为门面采用Logback做为实现或者采用其它上面提到过的组件做为实现相似，这里只分析采用Logback组件做为实现

示例代码参见：https://github.com/chlsmile/slf4j-logback-demo

pom核心配置以下

<dependencies>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.13</version>
    </dependency>
    <!--logback-classic依赖logback-core，会自动级联引入-->
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.2.3</version>
    </dependency>
  </dependencies>

程序入口类同上

源码分析

• 1)2)3)4)同上
• 5)调用LoggerFactory的findPossibleStaticLoggerBinderPathSet()方法获取StaticLoggerBinderPath集合
  
• 6)调用LoggerFactory的bind()方法的staticLoggerBinderPathSet集合对象赋值
  
• 7)在LoggerFactory的bind()方法中调用loback包下的StaticLoggerBinder建立单例对象
  
• 8)在LoggerFactory的bind()方法中调用reportActualBinding()记录日志加载信息
  
  
• 9)LoggerFactory中INITIALIZATION_STATE的值为SUCCESSFUL_INITIALIZATION，调用StaticLoggerBinder的单例对象获取ILoggerFactory
  
  
• 10)此时LoggerFactory中的getLogger()方法中获取到的ILoggerFactory其实是logback jar下的LoggerContext
  
• 11)此时LoggerFactory调用getLogger()方法获取到的Logger其实是logback jar下的Logger
  
  

三、Slf4j调用过程源码分析

加入slf4j-api-version.jar，同时加入多种日志实现组件

在项目中若是用slf4j-api做为日志门面，有多个日志实现组件同时存在，例如同时存在Logback，slf4j-log4j12，slf4j-jdk14，slf4j-jcl四种实现，则在项目实际运行中，Slf4j的绑定选择绑定方式将有Jvm肯定，而且是随机的，这样会和预期不符，实际使用过程当中须要避免这种状况。

示例代码参见：https://github.com/chlsmile/slf4j-logback-log4j-demo

pom核心配置以下

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.7.25</version>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.2.3</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jdk14</artifactId>
      <version>1.7.25</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jcl</artifactId>
      <version>1.7.25</version>
    </dependency>
  </dependencies>

程序入口类同上

源码分析

• 基本步骤同上，这里只追踪主要不一样点
• 1)追踪LoggerFactory的bind()方法内部调用findPossibleStaticLoggerBinderPathSet()方法后，从classpath下4个jar包内找到StaticLoggerBinder
  
• 2)此时LoggerFactory的bind()方法内部调用reportMultipleBindingAmbiguity()方法，给出警告信息classpath下同时存在多个StaticLoggerBinder,JVM会随机选择一个StaticLoggerBinder
  

四、使用Slf4时如何桥接遗留的api

在实际环境中咱们常常会遇到不一样的组件使用的日志框架不一样的状况，例如Spring Framework使用的是日志组件是Commons Logging，XSocket依赖的则是Java Util Logging。当咱们在同一项目中使用不一样的组件时应该若是解决不一样组件依赖的日志组件不一致的状况呢？如今咱们须要统一日志方案，统一使用Slf4j，把他们的日志输出重定向到Slf4j，而后Slf4j又会根据绑定器把日志交给具体的日志实现工具。Slf4j带有几个桥接模块，能够重定向Log4j，JCL和java.util.logging中的Api到Slf4j。

遗留的api桥接方案

jar包名	做用
log4j-over-slf4j-version.jar	将Log4j重定向到Slf4j
jcl-over-slf4j-version.jar	将Commons Logging里的Simple Logger重定向到slf4j
jul-to-slf4j-version.jar	将Java Util Logging重定向到Slf4j

桥接方式参见下图

使用Slf4j桥接注意事项

• 在使用Slf4j桥接时要注意避免造成死循环，在项目依赖的jar包中不要存在如下状况。

多个日志jar包造成死循环的条件	产生缘由
log4j-over-slf4j.jar和slf4j-log4j12.jar同时存在	因为slf4j-log4j12.jar的存在会将全部日志调用委托给log4j。但因为同时因为log4j-over-slf4j.jar的存在，会将全部对log4j api的调用委托给相应等值的slf4j,因此log4j-over-slf4j.jar和slf4j-log4j12.jar同时存在会造成死循环
jul-to-slf4j.jar和slf4j-jdk14.jar同时存在	因为slf4j-jdk14.jar的存在会将全部日志调用委托给jdk的log。但因为同时jul-to-slf4j.jar的存在，会将全部对jul api的调用委托给相应等值的slf4j，因此jul-to-slf4j.jar和slf4j-jdk14.jar同时存在会造成死循环

五、遗留api桥接死循环源码分析源码

这里以项目中集成log4j-over-slf4j与slf4j-log4j12为例，其它组合造成死循环原理相相似。

示例代码参见：https://github.com/chlsmile/slf4j-Infinite-loop-demo

程序入口类同上

源码分析

基本步骤同上，调用链路LoggerFactory.getLogger()>LoggerFactory.getILoggerFactory()> LoggerFactory.performInitialization()>LoggerFactory.bind()

• 1)LoggerFactory.bind()方法内部调用StaticLoggerBinder.getSingleton()获取StaticLoggerBinder实例
  
• 2)StaticLoggerBinder调用构造方法内部调用Log4jLoggerFactory构造方法建立ILoggerFactory
  
• 3)Log4jLoggerFactory加载内部static代码块，校验出classpath下存在org.apache.log4j.Log4jLoggerFactory，抛出异常
  

4、排除第三方包的日志依赖

在实际使用过程当中，项目会根据须要引入一些第三方组件，例如经常使用的Spring，而Spring自己的日志实现使用了Commons Logging，咱们又想使用Slf4j+Loback组合，这时候须要在项目中将Commons Logging排除掉，一般会用到如下3种方案，3种方案各有利弊，能够根据项目的实际状况选择最适合本身项目的解决方案。

方案一：maven的exclusion

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
    <version>${springframework.version}</version>
</dependency>

这种方案优势是exclusion是maven原生提供的，不足之处是若是有多个组件都依赖了commons-logging，则须要在不少处增长，使用起来不太方便

方案二：声明commons-logging的scope为provided

<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.1.1</version>
  <scope>provided</scope>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>jcl-over-slf4j</artifactId>
  <version>1.8.0-beta2</version>
</dependency>

这种方案在调试代码时仍是有可能致使IDE将commons-logging放置在classpath下，从而致使程序运行时出现异常

方案三：在maven私服中增长虚拟版本号

在maven私服中增长相似于99.0-does-not-exist这种虚拟的版本号

<dependency>    
    <groupId>commons-logging</groupId>    
    <artifactId>commons-logging</artifactId>    
    <version>99.0-does-not-exist</version>    
</dependency> 
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>jcl-over-slf4j</artifactId>
  <version>1.8.0-beta2</version>
</dependency>

这种方案好处是声明方式比较简单，用IDE调试代码时也不会出现问题，不足之处是99.0-does-not-exist这种版本是maven中央仓库中是不存在的，须要发布到本身的maven私服中。

总结

因为历史缘由JDK自身提供的Log组件出现的较晚，致使Jdk提供Log组件时第三方社区的日志组件已经比较稳定成熟。通过多年的发展Slf4j+Logback与组合，Commons Logging与Log4j组合两大阵营已经基本成为了Java项目开发的标准，建议在新的项目开发中从这两种方案中选择适合本身项目的组合方案。