注：本文转载至Java日志体系梳理，侵删~
1 简介
本文主要探究以下内容：
- 介绍 Java 日志体系发展历程
- 介绍 slf4j 日志门面，并梳理现有日志体系之间的关系及依赖
2 日志体系发展历程
在日常工作中可以看到项目中依赖的跟日志相关的 jar 包有很多，commons-logging.jar、log4j.jar、slf4j-api.jar、logback.jar 等等，眼花缭乱。要理清它们之间的关系，首先要从 Java Log 的发展历程说起。
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 JCL
commons-logging 已经停止更新，最后的状态如下所示：
JCL 支持的日志组件不多，并且现在用的人越来越少，就不多讲了。
3.2 slf4j桥接到具体的日志框架
下图来自官方文档：
由上图可以看到 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 上。
下图来自官方文档：
上图展示了能安全地从别的日志框架 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，从而形成一个环形。
