一、写在前面
- 随着历史发展，Java语言涌现了不少优秀的日志框架，比如Log4j，Jul，Jcl，slf4j，logback等，它们之前存在了复杂的关系；
- 关系复杂: 多个接口、不同实现、各种转换器、复杂的桥接器；
- 一个应用会依赖各种三方包，三方包各种依赖不同的日志组件，管理不善会导致原有日志配置失效、应用启动失败；
- 一般情况下偶尔会发生日志组件相关问题，会经常记不起来各种日志组件以及基本的依赖关系 、转换关系等；
- 一直想整理下Java日志框架，留作备用，终于到了要好好整理的时候，一切为了提高工作效率；
- 最后也希望能帮助到大家理解日志框架、快速排查问题；
二、历史演进
要弄清楚Java日志框架,就不可避免的要讲到日志框架的历史发展，下面以时间先后的顺序来一一介绍。
2.1 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的使用也减少了。
2.2 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以后性能和可用性才有所提升。
2.3 J.C.L(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的错误出现。
一切看起来很完美，做到了接口统一和实现分离，项目可以在log4j和Jul之间自由的切换，想用谁就用谁，很简单，但是现实很残酷。
2.4 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
- 配置文件中的条件处理
- 更丰富的过滤
到这里，你可能会问：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
然而，事情在变得更麻烦！
2.5 Log4j2
现在有了更好的 SLF4J 和 Logback，慢慢取代JCL 和 Log4j ，事情到这里总该大统一圆满结束了吧。然而维护 Log4j 的人不这样想，他们不想坐视用户一点点被 SLF4J / Logback 蚕食，继而搞出了 Log4j2。
Log4j2 和 Log4j1.x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。现在好了，我们有了三个流行的Log 接口和四个流行的Log实现，如果画出桥接关系的图来回事什么样子呢?
三、实战演示
3.1.Spring Boot环境
3.2. Log4j、JUL、JCL演示
3.3. Log4j2使用
3.4. sl4j 和 logback、log4j
3.5. Log4j2使用
3.6. 最佳实战
参考文档
[1] Java的日志框架梳理 https://www.jianshu.com/p/5326b5cc7d6c
[2]
[3]