最强最全常用开发库 - 日志类库详解

Java日志库是最能体现Java库在进化中的渊源关系的，在理解时重点理解日志框架本身和日志门面，以及比较好的实践等。要关注其历史渊源和设计（比如桥接），而具体在使用时查询接口即可， 否则会陷入JUL(Java Util Log), JCL(Commons Logging), Log4j, SLF4J, Logback，Log4j2傻傻分不清楚的境地。@pdai

日志库简介

我认为全面理解日志库需要从下面三个角度去理解：@pdai

• 最重要的一点是 区分日志系统和日志门面;
• 其次是日志库的使用, 包含配置与API使用；配置侧重于日志系统的配置，API使用侧重于日志门面；
• 最后是选型，改造和最佳实践等

日志库之日志系统

java.util.logging (JUL)

JDK1.4 开始，通过 java.util.logging 提供日志功能。虽然是官方自带的log lib，JUL的使用确不广泛。主要原因:

• JUL从JDK1.4 才开始加入(2002年)，当时各种第三方log lib已经被广泛使用了
• JUL早期存在性能问题，到JDK1.5上才有了不错的进步，但现在和Logback/Log4j2相比还是有所不如
• JUL的功能不如Logback/Log4j2等完善，比如Output Handler就没有Logback/Log4j2的丰富，有时候需要自己来继承定制，又比如默认没有从ClassPath里加载配置文件的功能

Log4j

Log4j 是 apache 的一个开源项目，创始人 Ceki Gulcu。Log4j 应该说是 Java 领域资格最老，应用最广的日志工具。Log4j 是高度可配置的，并可通过在运行时的外部文件配置。它根据记录的优先级别，并提供机制，以指示记录信息到许多的目的地，诸如：数据库，文件，控制台，UNIX 系统日志等。

Log4j 中有三个主要组成部分：

• loggers - 负责捕获记录信息。
• appenders - 负责发布日志信息，以不同的首选目的地。
• layouts - 负责格式化不同风格的日志信息。

官网地址：http://logging.apache.org/log4j/2.x/

Log4j 的短板在于性能，在Logback 和 Log4j2 出来之后，Log4j的使用也减少了。

Logback

Logback 是由 log4j 创始人 Ceki Gulcu 设计的又一个开源日记组件，是作为 Log4j 的继承者来开发的，提供了性能更好的实现，异步 logger，Filter等更多的特性。

logback 当前分成三个模块：logback-core、logback-classic 和 logback-access。

• logback-core - 是其它两个模块的基础模块。
• logback-classic - 是 log4j 的一个 改良版本。此外 logback-classic 完整实现 SLF4J API 使你可以很方便地更换成其它日记系统如 log4j 或 JDK14 Logging。
• logback-access - 访问模块与 Servlet 容器集成提供通过 Http 来访问日记的功能。

官网地址: http://logback.qos.ch/

Log4j2

维护 Log4j 的人为了性能又搞出了 Log4j2。

Log4j2 和 Log4j1.x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。

Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。

官网地址: http://logging.apache.org/log4j/2.x/

Log4j vs Logback vs Log4j2

从性能上Log4J2要强，但从生态上Logback+SLF4J优先。@pdai

初步对比

logback和log4j2都宣称自己是log4j的后代，一个是出于同一个作者，另一个则是在名字上根正苗红。

撇开血统不谈，比较一下log4j2和logback：

• log4j2比logback更新：log4j2的GA版在2014年底才推出，比logback晚了好几年，这期间log4j2确实吸收了slf4j和logback的一些优点（比如日志模板），同时应用了不少的新技术
• 由于采用了更先进的锁机制和LMAX Disruptor库，log4j2的性能优于logback，特别是在多线程环境下和使用异步日志的环境下
• 二者都支持Filter（应该说是log4j2借鉴了logback的Filter），能够实现灵活的日志记录规则（例如仅对一部分用户记录debug级别的日志）
• 二者都支持对配置文件的动态更新
• 二者都能够适配slf4j，logback与slf4j的适配应该会更好一些，毕竟省掉了一层适配库
• logback能够自动压缩/删除旧日志
• logback提供了对日志的HTTP访问功能
• log4j2实现了“无垃圾”和“低垃圾”模式。简单地说，log4j2在记录日志时，能够重用对象（如String等），尽可能避免实例化新的临时对象，减少因日志记录产生的垃圾对象，减少垃圾回收带来的性能下降
• log4j2和logback各有长处，总体来说，如果对性能要求比较高的话，log4j2相对还是较优的选择。

性能对比

附上log4j2与logback性能对比的benchmark，这份benchmark是Apache Logging出的，有多大水分不知道，仅供参考

同步写文件日志的benchmark：

异步写日志的benchmark：

当然，这些benchmark都是在日志Pattern中不包含Location信息（如日志代码行号 ，调用者信息，Class名/源码文件名等）时测定的，如果输出Location信息的话，性能谁也拯救不了：

日志库之日志门面

common-logging

common-logging 是 apache 的一个开源项目。也称Jakarta Commons Logging，缩写 JCL。

common-logging 的功能是提供日志功能的 API 接口，本身并不提供日志的具体实现（当然，common-logging 内部有一个 Simple logger 的简单实现，但是功能很弱，直接忽略），而是在运行时动态的绑定日志实现组件来工作（如 log4j、java.util.loggin）。

官网地址: http://commons.apache.org/proper/commons-logging/

slf4j

全称为 Simple Logging Facade for Java，即 java 简单日志门面。

什么，作者又是 Ceki Gulcu！这位大神写了 Log4j、Logback 和 slf4j，专注日志组件开发五百年，一直只能超越自己。

类似于 Common-Logging，slf4j 是对不同日志框架提供的一个 API 封装，可以在部署的时候不修改任何配置即可接入一种日志实现方案。但是，slf4j 在编译时静态绑定真正的 Log 库。使用 SLF4J 时，如果你需要使用某一种日志实现，那么你必须选择正确的 SLF4J 的 jar 包的集合（各种桥接包）。

官网地址: http://www.slf4j.org/

common-logging vs slf4j

slf4j 库类似于 Apache Common-Logging。但是，他在编译时静态绑定真正的日志库。这点似乎很麻烦，其实也不过是导入桥接 jar 包而已。

slf4j 一大亮点是提供了更方便的日志记录方式：

不需要使用logger.isDebugEnabled()来解决日志因为字符拼接产生的性能问题。slf4j 的方式是使用{}作为字符串替换符，形式如下：

logger.debug("id: {}, name: {} ", id, name);

日志库使用方案

使用日志解决方案基本可分为三步：

• 引入 jar 包
• 配置
• 使用 API

常见的各种日志解决方案的第 2 步和第 3 步基本一样，实施上的差别主要在第 1 步，也就是使用不同的库。

日志库jar包

这里首选推荐使用 slf4j + logback 的组合。

如果你习惯了 common-logging，可以选择 common-logging+log4j。

强烈建议不要直接使用日志实现组件(logback、log4j、java.util.logging)，理由前面也说过，就是无法灵活替换日志库。

还有一种情况：你的老项目使用了 common-logging，或是直接使用日志实现组件。如果修改老的代码，工作量太大，需要兼容处理。在下文，都将看到各种应对方法。

注：据我所知，当前仍没有方法可以将 slf4j 桥接到 common-logging。如果我孤陋寡闻了，请不吝赐教。

slf4j 直接绑定日志组件

• slf4j + logback

添加依赖到 pom.xml 中即可。

logback-classic-1.0.13.jar 会自动将 slf4j-api-1.7.21.jar 和 logback-core-1.0.13.jar 也添加到你的项目中。

  ch.qos.logback
  logback-classic
  1.0.13

• slf4j + log4j

添加依赖到 pom.xml 中即可。

slf4j-log4j12-1.7.21.jar 会自动将 slf4j-api-1.7.21.jar 和 log4j-1.2.17.jar 也添加到你的项目中。

  org.slf4j
  slf4j-log4j12
  1.7.21

• slf4j + java.util.logging

添加依赖到 pom.xml 中即可。

slf4j-jdk14-1.7.21.jar 会自动将 slf4j-api-1.7.21.jar 也添加到你的项目中。

  org.slf4j
  slf4j-jdk14
  1.7.21

slf4j 兼容非 slf4j 日志组件

在介绍解决方案前，先提一个概念——桥接

• 什么是桥接呢

假如你正在开发应用程序所调用的组件当中已经使用了 common-logging，这时你需要 jcl-over-slf4j.jar 把日志信息输出重定向到 slf4j-api，slf4j-api 再去调用 slf4j 实际依赖的日志组件。这个过程称为桥接。下图是官方的 slf4j 桥接策略图：

从图中应该可以看出，无论你的老项目中使用的是 common-logging 或是直接使用 log4j、java.util.logging，都可以使用对应的桥接 jar 包来解决兼容问题。

• slf4j 兼容 common-logging

  org.slf4j
  jcl-over-slf4j
  1.7.12

• slf4j 兼容 log4j

    org.slf4j
    log4j-over-slf4j
    1.7.12

• slf4j 兼容 java.util.logging

    org.slf4j
    jul-to-slf4j
    1.7.12

• spring 集成 slf4j

做 java web 开发，基本离不开 spring 框架。很遗憾，spring 使用的日志解决方案是 common-logging + log4j。

所以，你需要一个桥接 jar 包：logback-ext-spring。

  ch.qos.logback
  logback-classic
  1.1.3


  org.logback-extensions
  logback-ext-spring
  0.1.2


  org.slf4j
  jcl-over-slf4j
  1.7.12

common-logging 绑定日志组件

• common-logging + log4j

添加依赖到 pom.xml 中即可。

  commons-logging
  commons-logging
  1.2


  log4j
  log4j
  1.2.17

日志库配置 - 针对于日志框架

log4j2 配置

log4j2 基本配置形式如下：

;

  
    value
    
  
  
  
    
      
    
    ...
  
  
    
      
    
    ...
    
      
    
  

配置示例：

  
    target/test.log
  
  
 
  
    
      
      
        
        
      
    
    
      
      
        
        
      
    
    
      
        %d %p %C{1.} [%t] %m%n
      
    
  
 
  
    
      
        
      
      
    
 
    
      
    
 
    
      
    
  
 

logback 配置

 


 
  
 
  
  
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
  
    
    
      ${user.dir}/logs/${DIR_NAME}/all.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      30MB
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/error.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      10MB
    
 
    
      ERROR
      ACCEPT
      DENY
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/warn.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      10MB
    
 
    
      WARN
      ACCEPT
      DENY
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/info.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      10MB
    
 
    
      INFO
      ACCEPT
      DENY
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/debug.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      10MB
    
 
    
      DEBUG
      ACCEPT
      DENY
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/trace.%d{yyyy-MM-dd}.log
      30
    
 
    
    
      10MB
    
 
    
      TRACE
      ACCEPT
      DENY
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
 
  
    
    
      ${user.dir}/logs/${DIR_NAME}/springframework.%d{yyyy-MM-dd}.log
      
      30
    
 
    
    
      10MB
    
 
    
      %d{HH:mm:ss.SSS} [%thread] [%-5p] %c{36}.%M - %m%n
    
  
  
 
  
  
  
    
    
    
    
    
    
  
 
  
  
    
  
 
  
    
  
  
 

log4j 配置

完整的 log4j.xml 参考示例

日志库API - 针对于日志门面

slf4j 用法

使用 slf4j 的 API 很简单。使用LoggerFactory初始化一个Logger实例，然后调用 Logger 对应的打印等级函数就行了。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
public class App {
    private static final Logger log = LoggerFactory.getLogger(App.class);
    public static void main(String[] args) {
        String msg = "print log, current level: {}";
        log.trace(msg, "trace");
        log.debug(msg, "debug");
        log.info(msg, "info");
        log.warn(msg, "warn");
        log.error(msg, "error");
    }
}

common-logging 用法

common-logging 用法和 slf4j 几乎一样，但是支持的打印等级多了一个更高级别的：fatal。

此外，common-logging 不支持{}替换参数，你只能选择拼接字符串这种方式了。

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
 
public class JclTest {
    private static final Log log = LogFactory.getLog(JclTest.class);
 
    public static void main(String[] args) {
        String msg = "print log, current level: ";
        log.trace(msg + "trace");
        log.debug(msg + "debug");
        log.info(msg + "info");
        log.warn(msg + "warn");
        log.error(msg + "error");
        log.fatal(msg + "fatal");
    }
}

日志库选型与改造

对Java日志组件选型的建议

slf4j已经成为了Java日志组件的明星选手，可以完美替代JCL，使用JCL桥接库也能完美兼容一切使用JCL作为日志门面的类库，现在的新系统已经没有不使用slf4j作为日志API的理由了
日志记录服务方面，log4j在功能上输于logback和log4j2，在性能方面log4j2则全面超越log4j和logback。所以新系统应该在logback和log4j2中做出选择，对于性能有很高要求的系统，应优先考虑log4j2

对日志架构使用比较好的实践

总是使用Log Facade，而不是具体Log Implementation

正如之前所说的，使用 Log Facade 可以方便的切换具体的日志实现。而且，如果依赖多个项目，使用了不同的Log Facade，还可以方便的通过 Adapter 转接到同一个实现上。如果依赖项目使用了多个不同的日志实现，就麻烦的多了。

具体来说，现在推荐使用 Log4j-API 或者 SLF4j，不推荐继续使用 JCL。

只添加一个 Log Implementation依赖

毫无疑问，项目中应该只使用一个具体的 Log Implementation，建议使用 Logback 或者Log4j2。如果有依赖的项目中，使用的 Log Facade不支持直接使用当前的 Log Implementation，就添加合适的桥接器依赖。具体的桥接关系可以看上一篇文章的图。

具体的日志实现依赖应该设置为optional和使用runtime scope

在项目中，Log Implementation的依赖强烈建议设置为runtime scope，并且设置为optional。例如项目中使用了 SLF4J 作为 Log Facade，然后想使用 Log4j2 作为 Implementation，那么使用 maven 添加依赖的时候这样设置:

    org.apache.logging.log4j
    log4j-core
    ${log4j.version}
    runtime
    true


    org.apache.logging.log4j
    log4j-slf4j-impl
    ${log4j.version}
    runtime
    true

设为optional，依赖不会传递，这样如果你是个lib项目，然后别的项目使用了你这个lib，不会被引入不想要的Log Implementation 依赖；

Scope设置为runtime，是为了防止开发人员在项目中直接使用Log Implementation中的类，而不适用Log Facade中的类。

如果有必要, 排除依赖的第三方库中的Log Impementation依赖

这是很常见的一个问题，第三方库的开发者未必会把具体的日志实现或者桥接器的依赖设置为optional，然后你的项目继承了这些依赖——具体的日志实现未必是你想使用的，比如他依赖了Log4j，你想使用Logback，这时就很尴尬。另外，如果不同的第三方依赖使用了不同的桥接器和Log实现，也极容易形成环。

这种情况下，推荐的处理方法，是使用exclude来排除所有的这些Log实现和桥接器的依赖，只保留第三方库里面对Log Facade的依赖。

比如阿里的JStorm就没有很好的处理这个问题，依赖jstorm会引入对Logback和log4j-over-slf4j的依赖，如果你想在自己的项目中使用Log4j或其他Log实现的话，就需要加上excludes:

    com.alibaba.jstorm
    jstorm-core
    2.1.1
    
        
            org.slf4j
            log4j-over-slf4j
        
        
            ch.qos.logback
            logback-classic
        
    

避免为不会输出的log付出代价

Log库都可以灵活的设置输出界别，所以每一条程序中的log，都是有可能不会被输出的。这时候要注意不要额外的付出代价。

先看两个有问题的写法：

logger.debug("start process request, url: " + url);
logger.debug("receive request: {}", toJson(request));

第一条是直接做了字符串拼接，所以即使日志级别高于debug也会做一个字符串连接操作；第二条虽然用了SLF4J/Log4j2 中的懒求值方式来避免不必要的字符串拼接开销，但是toJson()这个函数却是都会被调用并且开销更大。

推荐的写法如下:

logger.debug("start process request, url:{}", url); // SLF4J/LOG4J2
logger.debug("receive request: {}", () -> toJson(request)); // LOG4J2
logger.debug(() -> "receive request: " + toJson(request)); // LOG4J2
if (logger.isDebugEnabled()) { // SLF4J/LOG4J2
    logger.debug("receive request: " + toJson(request)); 
}

日志格式中最好不要使用行号，函数名等字段

原因是，为了获取语句所在的函数名，或者行号，log库的实现都是获取当前的stacktrace，然后分析取出这些信息，而获取stacktrace的代价是很昂贵的。如果有很多的日志输出，就会占用大量的CPU。在没有特殊需要的情况下，建议不要在日志中输出这些这些字段。

最后， log中不要输出稀奇古怪的字符！

部分开发人员为了方便看到自己的log，会在log语句中加上醒目的前缀，比如:

logger.debug("========================start process request=============");

虽然对于自己来说是方便了，但是如果所有人都这样来做的话，那log输出就没法看了！正确的做法是使用grep 来看只自己关心的日志。

对现有系统日志架构的改造建议

如果现有系统使用JCL作为日志门面，又确实面临着JCL的ClassLoader机制带来的问题，完全可以引入slf4j并通过桥接库将JCL api输出的日志桥接至slf4j，再通过适配库适配至现有的日志输出服务（如log4j），如下图：

这样做不需要任何代码级的改造，就可以解决JCL的ClassLoader带来的问题，但没有办法享受日志模板等slf4j的api带来的优点。不过之后在现系统上开发的新功能就可以使用slf4j的api了，老代码也可以分批进行改造。

如果现有系统使用JCL作为日志门面，又头疼JCL不支持logback和log4j2等新的日志服务，也可以通过桥接库以slf4j替代JCL，但同样无法直接享受slf4j api的优点。

如果想要使用slf4j的api，那么就不得不进行代码改造了，当然改造也可以参考1中提到的方式逐步进行。

如果现系统面临着log4j的性能问题，可以使用Apache Logging提供的log4j到log4j2的桥接库log4j-1.2-api，把通过log4j api输出的日志桥接至log4j2。这样可以最快地使用上log4j2的先进性能，但组件中缺失了slf4j，对后续进行日志架构改造的灵活性有影响。另一种办法是先把log4j桥接至slf4j，再使用slf4j到log4j2的适配库。这样做稍微麻烦了一点，但可以逐步将系统中的日志输出标准化为使用slf4j的api，为后面的工作打好基础。

参考文档

主要参考整理自：

• https://www.jianshu.com/p/85d141365d39
• https://blog.csdn.net/Dome_/article/details/98489727
• https://zhuanlan.zhihu.com/p/24272450

此外还参考了：

• http://www.slf4j.org/manual.html
• http://logback.qos.ch/
• http://logging.apache.org/log4j/1.2/
• http://commons.apache.org/proper/commons-logging/
• http://blog.csdn.net/yycdaizi/article/details/8276265

更多内容

最全的Java后端知识体系 https://www.pdai.tech, 每天更新中...。