Java的日志框架梳理 Java日志

对于Java的日志框架，你也许会经常看到这些名词：

Log4j、Log4j2
Logback
Slf4j
JCL (Jakarta Commons Logging)，也叫 Apache Common logging
J.U.L (java.util.logging)

初次接触这些，可能有种云雾缭绕不知所云的感觉。本文就来好好梳理下它们的关系。
发展历程要搞清楚它们的关系，就要从它们是在什么情况下产生的说起。我们按照时间的先后顺序来介绍。
Log4j
在JDK 1.3及以前，Java打日志依赖System.out.println(), System.err.println()或者e.printStackTrace()，Debug日志被写到STDOUT流，错误日志被写到STDERR流。这样打日志有一个非常大的缺陷，即无法定制化，且日志粒度不够细。
于是， Gülcü 于2001年发布了Log4j，后来成为Apache 基金会的顶级项目。Log4j 在设计上非常优秀，对后续的 Java Log 框架有长久而深远的影响，它定义的Logger、Appender、Level等概念如今已经被广泛使用。Log4j 的短板在于性能，在Logback 和 Log4j2 出来之后，Log4j的使用也减少了。
J.U.L
受Logj启发，Sun在Java1.4版本中引入了java.util.logging，但是j.u.l功能远不如log4j完善，开发者需要自己编写Appenders（Sun称之为Handlers），且只有两个Handlers可用（Console和File），j.u.l在Java1.5以后性能和可用性才有所提升。
JCL（commons-logging）
由于项目的日志打印必然选择两个框架中至少一个，这时候，Apache的JCL（commons-logging）诞生了。JCL 是一个Log Facade，只提供 Log API，不提供实现，然后有 Adapter 来使用 Log4j 或者 JUL 作为Log Implementation。
在程序中日志创建和记录都是用JCL中的接口，在真正运行时，会看当前ClassPath中有什么实现，如果有Log4j 就是用 Log4j, 如果啥都没有就是用 JDK 的 JUL。
这样，在你的项目中，还有第三方的项目中，大家记录日志都使用 JCL 的接口，然后最终运行程序时，可以按照自己的需求(或者喜好)来选择使用合适的Log Implementation。如果用Log4j, 就添加 Log4j 的jar包进去，然后写一个 Log4j 的配置文件；如果喜欢用JUL，就只需要写个 JUL 的配置文件。如果有其他的新的日志库出现，也只需要它提供一个Adapter，运行的时候把这个日志库的 jar 包加进去。
不过，commons-logging对Log4j和j.u.l的配置问题兼容的并不好，使用commons-loggings还可能会遇到类加载问题，导致NoClassDefFoundError的错误出现。

文章图片
到这个时候一切看起来都很简单，很美好。接口和实现做了良好的分离，在统一的JCL之下，不改变任何代码，就可以通过配置就换用功能更强大，或者性能更好的日志库实现。
这种简单美好一直持续到SLF4J出现。
SLF4J & Logback
SLF4J（Simple Logging Facade for Java）和 Logback 也是Gülcü 创立的项目，目的是为了提供更高性能的实现。
从设计模式的角度说，SLF4J 是用来在log和代码层之间起到门面作用，类似于 JCL 的 Log Facade。对于用户来说只要使用SLF4J提供的接口，即可隐藏日志的具体实现，SLF4J提供的核心API是一些接口和一个LoggerFactory的工厂类，用户只需按照它提供的统一纪录日志接口，最终日志的格式、纪录级别、输出方式等可通过具体日志系统的配置来实现，因此可以灵活的切换日志系统。
Logback是log4j的升级版，当前分为三个目标模块：

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

Logback相较于log4j有更多的优点：

更快的执行速度
更充分的测试
logback-classic 非常自然的实现了SLF4J
使用XML配置文件或者Groovy
自动重新载入配置文件
优雅地从I/O错误中恢复
自动清除旧的日志归档文件
自动压缩归档日志文件
谨慎模式
Lilith
配置文件中的条件处理
更丰富的过滤

更详细的解释参见官网：https://logback.qos.ch/reasonsToSwitch.html
到这里，你可能会问：Apache 已经有了个JCL，用来做各种Log lib统一的接口，如果 Gülcü 要搞一个更好的 Log 实现的话，直接写一个实现就好了，为啥还要搞一个和SLF4J呢?
原因是Gülcü 认为 JCL 的 API 设计得不好，容易让使用者写出性能有问题的代码。关于这点，你可以参考这篇文章获得更详细的介绍：https://zhuanlan.zhihu.com/p/24272450
现在事情就变复杂了。我们有了两个流行的 Log Facade，以及三个流行的 Log Implementation。Gülcü 是个追求完美的人，他决定让这些Log之间都能够方便的互相替换，所以做了各种 Adapter 和 Bridge 来连接:

文章图片
可以看到甚至 Log4j 和 JUL 都可以桥接到SLF4J，再通过 SLF4J 适配到到 Logback！需要注意的是不能有循环的桥接，比如下面这些依赖就不能同时存在:

jcl-over-slf4j 和 slf4j-jcl
log4j-over-slf4j 和 slf4j-log4j12
jul-to-slf4j 和 slf4j-jdk14

然而，事情在变得更麻烦！
Log4j2
现在有了更好的 SLF4J 和 Logback，慢慢取代JCL 和 Log4j ，事情到这里总该大统一圆满结束了吧。然而维护 Log4j 的人不这样想，他们不想坐视用户一点点被 SLF4J / Logback 蚕食，继而搞出了 Log4j2。
Log4j2 和 Log4j1.x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。
现在好了，我们有了三个流行的Log 接口和四个流行的Log实现，如果画出桥接关系的图来回事什么样子呢?

文章图片
看到这里是不是感觉有点晕呢？是的，我也有这种感觉。同样，在添加依赖的时候，要小心不要有循环依赖。
小结
常见的Java日志框架

log4j
logback
j.u.l (java.util.logging)

常见的Java日志门面

SLF4J
commons-logging

日志框架的绑定如果使用 SLF4J 接口，SLF4J 允许终端用户在部署的时候插入自己想要的日志框架。SLF4J 发行包中自带几个 jar 文件作为 "SLF4J bindings" 的参考：

slf4j-nop：绑定到 NOP，沉默的忽略掉所有的日志
slf4j-simple：绑定到 Simple 实现，输出所有的事件到 System.err，只有 INFO 或更高级别的信息才会被打印出来
slf4j-log4j12：绑定 1.2 版的 log4j，需要你把 log4j.jar 放置到你的类路径下
slf4j-jdk14：绑定 java.util.logging
slf4j-jcl：绑定 JCL，这种绑定会把所有的 SLF4J 日志代理到 JCL

实际上，SLF4J 不依赖于任何的类加载器机制。每一个 SLF4J 绑定都会在编译时使用一种也只能使用一种特定日志框架。想要切换日志框架的话，仅仅是替换掉类路径下的 SLF4J 绑定。例如，将要从 J.U.L 切换到 log4j，只需要用 slf4j-log4j12.jar 替换掉 slf4j-jdk14.jar。下图概述了这个过程。

文章图片
通过 SLF4J 统一日志
上面说到，如果使用 SLF4J 作为日志门面接口，那么可以很方便地选择一种日志框架（只能绑定一种）。然而，现实中我们遇到的情况却要更复杂些：我们想使用 SLF4J 的API，但是系统中已经使用了 JCL、log4j 或者 J.U.L，我们该怎么办呢？
SLF4J 为我们提供了从老接口切换到 SLF4J 的方法，如下图所示。

文章图片
我们以图中的左上部分为例来说明下。目前的应用程序中已经使用了如下混杂方式的API来进行日志的编程：

commons-logging
log4j1
J.U.L

【Java的日志框架梳理】现在想统一将日志的输出交给 logback。解决方法是：

第一步，先将上述日志系统的API全部无缝切换到 SLF4J
- 去掉 commons-logging（其实去不去都可以），使用 jcl-over-slf4j 将 commons-logging 的底层日志输出切换到 SLF4J
- 去掉 Log4j1（必须去掉），使用 log4j-over-slf4j，将 Log4j1 的日志输出切换到 SLF4J
- 使用 jul-to-slf4j，将 J.U.L 的日志输出切换到 SLF4J
第二步，让 SLF4J 绑定 Logback 来作为底层日志输出，加入以下 jar 包依赖
- slf4j-api
- logback-core
- logback-classic

图中剩下两个部分和上面很类似，详细说明可以参考官网：https://www.slf4j.org/legacy.html
最佳实践推荐使用 SLF4J + Logback。maven依赖如下，其中version字段用占位符代替，你应该根据项目的实际情况选择合适的版本：

org.slf4j slf4j-api ${version} ch.qos.logback logback-core ${version} ch.qos.logback logback-classic ${version} org.slf4j slf4j-log4j12 99.0-does-not-exist org.slf4j log4j-over-slf4j ${version} org.slf4j jcl-over-slf4j ${version} log4j log4j 99.0-does-not-exist apache-log4j log4j 999-not-exist

再提几点最佳实践：

总是使用 Log Facade，而不是具体的 Log Implementation
只添加一个 Log Implementation 依赖
具体的日志依赖应该设置为 optional，并使用 runtime scope
设为optional，依赖不会传递，这样如果你是个lib项目，然后别的项目使用了你这个lib，不会被引入不想要的Log Implementation 依赖；
Scope设置为runtime，是为了防止开发人员在项目中直接使用Log Implementation中的类，而不使用Log Facade中的类。
如果有必要, 排除依赖的第三方库中的Log Impementation依赖
这是很常见的一个问题，第三方库的开发者未必会把具体的日志实现或者桥接器的依赖设置为optional，然后你的项目继承了这些依赖——具体的日志实现未必是你想使用的，比如他依赖了Log4j，你想使用Logback，这时就很尴尬。另外，如果不同的第三方依赖使用了不同的桥接器和Log实现，也极容易形成环。
这种情况下，推荐的处理方法，是使用exclude来排除所有的这些Log实现和桥接器的依赖，只保留第三方库里面对Log Facade的依赖。

参考资料