解析混乱的java日志体系-jul,jcl,log4j,log4j2,slf4j,logback

之前老是弄不清commons-logging.jar、log4j.jar、sl4j-api.jar等日志框架之间复杂的关系。今儿特意
研究了一下他们之间的关系。

不要急，不要方！本文带你们弄懂其中的原理，只要你静下心看本文，你就能随心所欲更改你系统里的日志框架，统一日志输出！

1. 日志框架发展史

1. 早年，JDK1.3之前，java 没有任何日志框架，大家更多的是System.out输出，十分不便。

2. 后来，出现了 log4j(已开源)
   在日志里使用了log4j框架来输出，于是你代码是这么写的

import org.apache.log4j.Logger;
\\省略
Logger logger = Logger.getLogger(Test.class);
logger.trace("trace");
\\省略

3. 但是，岁月流逝，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抽象出接口，这样以后调用的时候，就调用这些接口就好了呢？

4. 这个时候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会引发内存泄露。

5. 于是 log4j的作者觉得jcl不好用，自己又写了一个新的接口api，那么就是slf4j。关于slf4j的集成图如下所示
   

如图所示，应用调了sl4j-api，即日志门面接口。日志门面接口本身通常并没有实际的日志输出能力，它底层还是需要去调用具体的日志框架API的，也就是实际上它需要跟具体的日志框架结合使用。由于具体日志框架比较多，而且互相也大都不兼容，日志门面接口要想实现与任意日志框架结合可能需要对应的桥接器，上图红框中的组件即是对应的各种桥接器！
我们在代码中需要写日志，变成下面这么写

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 。使用门面模式的日志框架，有利于维护和各个类的日志处理方式的统一。

6. log4j作者后来又开发出了logback。性能说是比log4j高出几十倍。
7. Apache 坐不住了，模仿logback， 开发出了log4j2。

ok，至此，日志梳理完毕~

2. Spring4和Spring5日志中的不同

1. Spring4日志体系
   构建spring4项目
   　　采用java+注解的方式快速构建，pom中只引入spring-context包

运行下面的代码，可以看到有日志输出


找到打印日志的地方，debug模式下，查看输出日志的Log是什么log

可以看出是jdk14Logger，这个在JCL中说过，这个指的是JUL，也就是说在默认spring日志体系下，采用的是JUL，
　　接下来，我们按照之前的方法引入log4j，debug运行上面的程序，再次查看日志类型

额，这次在增加log4j jar包和配置文件的情况下，spring4有使用了log4j，这么像JCL呢，木错，让我们在idea中打开spring4的日志依赖结构：

common-logging 这不就是JCL使用到的包吗，可以看出，Spring4使用的是原生的JCL，所以在有log4j的时候使用log4j打印日志，没有的时候使用JUL打印日志。

2. Spring5日志体系
   线上依赖结构图：
   
   答题结构没变，只是原来common-logging ，换成了spring-jcl，看名字就知道是spring自造的包，jcl，更是标注了，它使用的是JCL日志体系。
   　　所以还是看源码吧。
   　　按照之前的经验，我们只用debug找到spring内部一个Log，看看他的产生方式和类型。这次我给大家找了AbstractApplicationContext里面找到产生Log的地方

进入这个方法的getLog()中，一直深入，不要怜惜spring，找到LogAdapter中的createLog()方法

可以看出来spring5中对日志的生产，不在像原生JCL中那样使用一个数组，然后进行循环产生，这里用到的是 Switch case,这个关键字段LogApi又是在哪一部分赋值的呢？看图

Duang ,没错是在静态代码块中赋的值，为了验证，我们准备用其中提到的log4j2验证（注意：log4j不行，因为这里的switch没有log4j选项），首先我们准备log4j2的配置文件

<Configuration status="WARN">

	<Appenders>
		<Console name="Console" target="SYSTEM_OUT">
				<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
	   </Console>
	</Appenders>

	<Loggers>
		<Root level="debug">
			<AppenderRef ref="Console"/>
		</Root>
	</Loggers>
	
</Configuration>

然后准备pom

代码还是这一行，直接运行：

结果有日志打印出来了

所以，在spring5中，依然使用的是JCL，但是不是原生的，是经过改造的JCL，默认使用的是JUL，而原生JCL中默认使用的是log4j.

3.结语

世上无难事，只怕有心人，每天积累一点点，fighting！！！
之前对nginx理解不深，经过这次，以后不管前端后端都可以快速部署了~