1 简介

本文主要探究以下内容：

  • 介绍 Java 日志体系发展历程

  • 介绍 slf4j 日志门面，并梳理现有日志体系之间的关系及依赖

    2 日志体系发展历程

    在日常工作中可以看到项目中依赖的跟日志相关的 jar 包有很多，commons-logging.jar、log4j.jar、slf4j-api.jar、logback.jar 等等，眼花缭乱。要理清它们之间的关系，首先要从 Java Log 的发展历程说起。
    Java日志框架 - 图1
    1.log4j
    log4j（作者 Ceki Gülcü）出来时就得到了广泛的应用，是 Java 日志事实上的标准，并成为了 Apache 的项目。
    2.JUL
    log4j 作为 Apache 基金会的一员，Apache 希望将 log4j 引入 jdk，不过被 sun 公司拒绝了。随后，sun 模仿 log4j，在 jdk1.4 中实现了 JUL 即 java.util.logging。
    3.JCL
    JUL 毕竟是 JDK 自带的，也有很多人用。同时还有其他日志组件，如 SimpleLog 等。这时如果有人想换成其他日志组件，如 log4j 换成 JUL，因为 API 完全不同，就需要改动代码。
    为了将日志接口与实现解耦，Apache 推出了 JCL 即 Apache Commons Logging。JCL 只定义了一套日志接口，具体实现由 log4j 或 JUL 来完成。JCL 基于动态绑定来实现日志的记录，在使用时只需要用 JCL 定义的接口来编写代码即可，程序真正运行时会检查 classpath 中的具体实现，因此可以自由选择是由 log4j 还是 JUL 来实现日志功能。
    4.slf4j&logback
    这样看上去也挺美好的，但是 log4j 的作者(Ceki Gülcü)觉得 JCL 不好用，便接着开发出了 slf4j，它跟 JCL 类似，本身不替供日志具体实现，只对外提供接口或门面。目的就是为了替代 JCL。同时，还开发出 logback，一个比 log4j 拥有更高性能的组件，目的是为了替代 log4j。
    5.log4j2
    最后，Apache 为了避免 slf4j 和 logback 慢慢取代 JCL 和 log4j，推出了自己的反击之作 log4j2，相比 log4j 其性能获得了很大的提升。于是，我们就看到了如此多的日志框架并存的局面。
    注：log4j2 目前是 Java 中最优秀的日志框架。

    3 门面模式、桥接器与日志实现

    大概了解了发展历程后，再详细看看它们之间的关系、依赖。

    3.1 门面模式

    比直接使用具体日志框架更合理的选择是使用日志门面接口。日志门面接口提供了一套独立于具体日志框架实现的API，应用程序通过使用这些独立的API就能够实现与具体日志框架的解耦，这跟JDBC是类似的。最早的日志门面接口是commons-logging，但目前最受欢迎的是SLF4J。
    SLF4J（Simple logging Facade for Java）
    意思为简单日志门面，它是把不同的日志系统的实现进行了具体的抽象化，只提供了统一的日志使用接口，使用时只需要按照其提供的接口方法进行调用即可，由于它只是一个接口，并不是一个具体的可以直接单独使用的日志框架，所以最终日志的格式、记录级别、输出方式等都要通过接口绑定的具体的日志系统来实现，这些具体的日志系统就有log4j2、log4j、logback、java.util.logging等，它们才实现了具体的日志系统的功能。日志门面在使用时，可以动态或者静态的指定具体的日志框架实现，实现了接口和实现的解耦，使得用户可以灵活的选择日志的具体实现框架。另一种就是具体的日志系统，它提供了具体的日志接口实现，应用程序通过具体实现执行日志打印的功能。
    image.png
    那为什么要将日志的体系搞这么复杂呢，简单一个实现不就好了吗，为什么分成门面与实现？要解答这个问题，需要回顾一下门面模式。门面模式，其核心为：外部与一个子系统的通信，必须通过一个统一的外观对象进行，使得子系统更易于使用。
    image.png
    现在，我们可以回到最初的问题了，日志体系为什么要使用SLF4J作为门面呢？

  • 使用slf4j后有利于根据自己实际的需求更换具体的日志系统，比如，之前使用的具体的日志系统为log4j，想更换为logback时，只需要删除log4j相关的jar，然后加入logback相关的jar和日志配置文件即可，而不需要改动具体的日志输出方法，试想如果没有采用这种方式，当你的系统中日志输出有成千上万条时，你要更换日志系统将是多么庞大的一项工程。如果你开发的是一个面向公众使用的组件或公共服务模块，那么一定要使用slf4的这种形式，这有利于别人在调用你的模块时保持和他系统中使用统一的日志输出。

3.2 slf4j桥接到具体的日志框架

Java日志体系当前大体可以分为三个部分：日志门面接口、桥接器、日志框架具体实现。门面接口与日志实现上面已经介绍过了。那么什么是桥接器呢？所谓“桥接器”，不过就是对某套API的伪实现，这种实现并不是直接去完成API所声明的功能，而是去调用有类似功能的别的API。这样就完成了从“某套API”到“别的API”的转调。如果同时存在A-to-B.jar和B-to-A.jar这两个桥接器，那么可以想象当应用程序开始调用A或者B的API时，会发生什么事。
下图来自官方文档：
Java日志框架 - 图4
由上图可以看到 slf4j 几乎可以使用所有的具体日志框架。
上图释义如下：

  • 绿色的 application：应用层，向下可直接调用 slf4j 提供的 API
  • 浅蓝色的 abstract logging api：抽象 API 层
  • 深蓝色的 native implementation of slf4j-api：具体日志框架实现层，不需要适配器，本身已经实现了 slf4j-api
  • 湖蓝色的 adaptation layer：适配层，也就是桥接器
  • 灰色的 non-native implementation of slf4j-api：具体日志框架实现层，本身没有实现 slf4j-api，需要桥接器

第三层所有灰色的 jar 包都带有红框，这表示它们都直接实现了 slf4j-api，只是湖蓝色的桥接器对 slf4j-api 的实现并不是直接输出日志，而是转去调用别的日志框架声明的 API。
slf4j-simple.jar 和 slf4j-nop.jar 这两个不用多说，看名字就知道一个是 slf4j 的简单实现，一个是 slf4j 的空实现，平时用处也不大。而 logback 之所以也实现了 slf4j-api，就是因为 logback 和 slf4j 出自同一人之手。

3.3 具体的日志框架桥接到slf4j

除了从 slf4j 到其他日志框架的桥接器，还有另外一类桥接器，它们的作用跟上面的恰好相反，它们能将其它日志框架的 API 转调到 slf4j 的 API 上。
下图来自官方文档：
Java日志框架 - 图5
上图展示了能安全地从别的日志框架 API 转调回 slf4j 的三种情形。要想实现转调，方法就是图上列出的用特定的桥接器 jar 替换掉原有的日志框架 jar。
以左上角第一种情形为例：当 slf4j 底层使用的具体实现是 logback 时，上层允许桥接到 slf4j 的日志框架 API 有 log4j 和 JUL。JCL 虽然不是什么日志框架的具体实现，但它的 API 仍然能够被转调回 slf4j。
看完三种情形以后，会发现几乎所有其他日志框架的 API，包括 JCL 的 API，都能够随意的转调回 slf4j。但是这里要十分注意，有一个限制就是转调回 slf4j 的日志框架不能跟 slf4j 当前使用的具体日志实现框架相同。这个限制主要为了防止 A-to-B.jar 跟 B-to-A.jar 同时出现在类路径中，从而导致 A 和 B 一直不停地互相递归调用，最后导致堆栈溢出。
举个栗子，假设日志框架采用 slf4j+log4j。一个具体的日志操作过程如下：
首先调用 slf4j 的 API 接口，然后 slf4j 将请求转发给 slf4j-log4j12 来处理，这个是在编译期间静态绑定好的。最后 slf4j-log4j12 通过 log4j 来完成日志操作。此时项目中如果再加一个 log4j-over-slf4j 会怎样？如下图，日志请求会重新打回给 slf4j，从而形成一个环形。
Java日志框架 - 图6

4 参考阅读

  1. Java日志体系总结
  2. Java日志体系梳理
  3. 面向log4j2 API编程而不是slf4j