前言
对于一个应用程序来说日志记录是必不可少的一部分。线上问题追踪，基于日志的业务逻辑统计分析等都离不日志。java领域存在多种日志框架，目前常用的日志框架包括Log4j 1，Log4j 2，Commons Logging，Slf4j，Logback，Jul。但是在我们的系统里面到底该怎么使用日志框架？还在为弄不清commons-logging.jar、log4j.jar、sl4j-api.jar等日志框架之间复杂的关系而感到烦恼吗？还在为如何统一系统的日志输出而感到不知所措嘛？比如，要更改Spring的日志输出为Log4j 2，却不知该引哪些jar包，只知道去百度一下所谓的博客，照着人家复制，却无法弄懂其中的原理？本文将弄懂其中的原理，只要你静下心看本文，你就能随心所欲更改你系统里的日志框架，统一日志输出！
日志框架类别
记录型日志框架
- Jul (Java Util Logging)：JDK中的日志记录工具，也常称为JDKLog、jdk-logging，自Java1.4以来的官方日志实现。
- Log4j：Apache Log4j是一个基于Java的日志记录工具。它是由Ceki Gülcü首创的，现在则是Apache软件基金会的一个项目。 Log4j是几种Java日志框架之一。
- Log4j2：一个具体的日志实现框架，是Log4j 1的下一个版本，与Log4j 1发生了很大的变化，Log4j 2不兼容Log4j 1。
- Logback：一个具体的日志实现框架，和Slf4j是同一个作者，但其性能更好（推荐使用）。
门面型日志框架
- JCL：Apache基金会所属的项目，是一套Java日志接口，之前叫Jakarta Commons Logging，后更名为Commons Logging
- SLF4J：是一套简易Java日志门面，本身并无日志的实现。（Simple Logging Facade for Java，缩写Slf4j）
看到这么多日志框架是否会觉得比较混乱，这些日志框架之间有什么异同，都是由谁在维护，在项目中应该如何选择日志框架，应该如何使用? 不要急，我们先把这些术语概念先有个印象。让我们先了解一它们的发展历史。
日志框架发展史
Java日志的恩怨情仇
- 1996年早期，欧洲安全电子市场项目组决定编写它自己的程序跟踪API(Tracing API)。经过不断的完善，这个API终于成为一个十分受欢迎的Java日志软件包，即Log4j（由Ceki创建）。
- 后来Log4j成为Apache基金会项目中的一员，Ceki也加入Apache组织。后来Log4j近乎成了Java社区的日志标准。据说Apache基金会还曾经建议Sun引入Log4j到Java的标准库中，但Sun拒绝了。
- 2002年Java1.4发布，Sun推出了自己的日志库JUL(Java Util Logging),其实现基本模仿了Log4j的实现。在JUL出来以前，Log4j就已经成为一项成熟的技术，使得Log4j在选择上占据了一定的优势。
- 接着，Apache推出了Jakarta Commons Logging，JCL只是定义了一套日志接口(其内部也提供一个Simple Log的简单实现)，支持运行时动态加载日志组件的实现，也就是说，在你应用代码里，只需调用Commons Logging的接口，底层实现可以是Log4j，也可以是Java Util Logging。
- 后来(2006年)，Ceki不适应Apache的工作方式，离开了Apache。然后先后创建了Slf4j(日志门面接口，类似于Commons Logging)和Logback(Slf4j的实现)两个项目，并回瑞典创建了QOS公司，QOS官网上是这样描述Logback的：The Generic，Reliable Fast&Flexible Logging Framework(一个通用，可靠，快速且灵活的日志框架)。
- Java日志领域被划分为两大阵营：Commons Logging阵营和Slf4j阵营。
- Commons Logging在Apache大树的笼罩下，有很大的用户基数。但有证据表明，形式正在发生变化。2013年底有人分析了GitHub上30000个项目，统计出了最流行的100个Libraries，可以看出Slf4j的发展趋势更好。
- Apache眼看有被Logback反超的势头，于2012-07重写了Log4j 1.x，成立了新的项目Log4j 2, Log4j 2具有Logback的所有特性。
大神Ceki
log4j
早年，你工作的时候，在日志里使用了log4j框架来输出，于是你代码是这么写的
import org.apache.log4j.Logger;
//省略...
Logger logger = Logger.getLogger(Test.class);
logger.trace("trace");
//省略...
jul
但是，岁月流逝，sun公司对于log4j的出现内心隐隐表示嫉妒。于是在jdk1.4版本后，增加了一个包为java.util.logging，简称为jul，用以对抗log4j。于是，你的领导要你把日志框架改为jul，这时候你只能一行行的将log4j的api改为jul的api，如下所示:
import java.util.logging.Logger；
//省略...
Logger loggger = Logger.getLogger(Test.class.getName());
logger.finest("finest");
//省略...
可以看出，api完全是不同的。那有没有办法，将这些api抽象出接口，这样以后调用的时候，就调用这些接口就好了呢？
jcl
这个时候jcl(Jakarta Commons Logging)出现了，说jcl可能大家有点陌生，讲commons-logging-xx.jar组件，大家总有印象吧。JCL 只提供 log 接口，具体的实现则在运行时动态寻找。这样一来组件开发者只需要针对 JCL 接口开发，而调用组件的应用程序则可以在运行时搭配自己喜好的日志实践工具。JCL可以实现的集成方案如下图所示
jcl默认的配置：如果能找到Log4j 则默认使用log4j 实现，如果没有则使用jul(jdk自带的) 实现，再没有则使用jcl内部提供的SimpleLog 实现。
于是，你在代码里变成这么写了
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
//省略...
Log log =LogFactory.getLog(Test.class);
log.trace('trace');
//省略...
至于这个Log具体的实现类，JCL会在ClassLoader中进行查找。这么做，有三个缺点:
- 缺点一是效率较低
- 二是容易引发混乱
- 三是在使用了自定义ClassLoader的程序中，使用JCL会引发内存泄露。
slf4j
于是log4j的作者（Ceki）觉得jcl不好用，自己又写了一个新的接口api，那么就是slf4j。
我们在代码中需要写日志，变成下面这么写
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
//省略...
Logger logger = LoggerFactory.getLogger(Test.class);
//省略...
logger.info("info");
在代码中，并不会出现具体日志框架的api。程序根据classpath中的桥接器类型，和日志框架类型，判断出logger.info应该以什么框架输出！注意了，如果classpath中不小心引了两个桥接器，那会直接报错的！
因此，在阿里的开发手册上才有这么一条
强制：应用中不可直接使用日志系统（log4j、logback）中的 API ，而应依赖使用日志框架 SLF4J 中的 API 。使用门面模式的日志框架，有利于维护和各个类的日志处理方式的统一。
Slf4j的使用
Slf4j与其它日志组件的关系说明
- Slf4j的设计思想比较简洁，使用了Facade设计模式，Slf4j本身只提供了一个slf4j-api-version.jar包，这个jar中主要是日志的抽象接口，jar中本身并没有对抽象出来的接口做实现。
- 对于不同的日志实现方案(例如Logback，Log4j...)，封装出不同的桥接组件(例如logback-classic-version.jar，slf4j-log4j12-version.jar)，这样使用过程中可以灵活的选取自己项目里的日志实现。
Slf4j与其它日志组件集成图
如图所示，应用调了sl4j-api，即日志门面接口。日志门面接口本身通常并没有实际的日志输出能力，它底层还是需要去调用具体的日志框架API的，也就是实际上它需要跟具体的日志框架结合使用。由于具体日志框架比较多，而且互相也大都不兼容，日志门面接口要想实现与任意日志框架结合可能需要对应的桥接器，上图红框中的组件即是对应的各种桥接器！
Slf4j与其他各种日志组件的桥接说明
具体的介入方式参考下图
转载：《深入掌握Java日志体系，再也不迷路了》
作者公众号：一角钱技术（org_yijiaoqian）
原文：https://www.toutiao.com/a6905026316341527052/
