SLF4J ,全称Simple Logging Facade for Java, 即 “java的简单日志门面”
一,java世界中的日志框架
说明:前两项,即slf4j 和 jcl 是门面日志框架,是两种不同的日志框架接口,下面5项是实现;
好比slf4j 和 jcl是jdbc,而下面5项是各个数据库厂商实现的驱动。
slf4j、log4j、reload4j、log4j2、logback 的作者都是Ceki Gülcü;
jcl这套接口已经很久没更新,几乎不用了;
所以现在的java应用几乎都是使用slf4j做日志接口,在代码中都是面向slf4j的接口编程,
比如获取Logger对象都是导入org.slf4j包下的类:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class LogbackTest {
static Logger logger = LoggerFactory.getLogger(LogbackTest.class);
static Logger logger2 = LoggerFactory.getLogger("com.baidu");
}
二,日志门面框架的好处
一个项目中,我们既要引入spring、又要引入mybatis、mybatis-plus等 ,还可能引入一些其他的jar包,这些jar包中都使用了日志,如果它们不是使用slf4j的接口,假设spring用log4j,mybatis用logback...... 那么这个项目就需要导入各种日志框架的jar包,并且更糟糕的是:
如果要修改spring日志的级别和日志文件的路径,就需要给spring建立一个日志的配置文件,
如果要修改mybatis日志的级别和日志文件的路径,就需要给mybatis建立一个日志的配置文件,
。。。。。。。。。。想想就觉得不太妥当。
而有了slf4j, spring和mybatis都使用slf4j的接口进行编程,我们在使用这两个框架时,想使用任意一个实现了slf4j的日志实现框架都可以,只需要一个日志配置文件,就能同时管理项目中所有jar包内的日志级别、输出文件的路径、日志格式等。
三,什么是适配层
有些日志框架并没有直接实现slf4j,而是用一个适配层(单独一个jar包) 去实现slf4j,然后由适配层调用具体的实现,这样的好处是什么?
我想这个作者是不是不光只想实现slf4j,可能怕日后再出一个很牛的日志门面框架,他想实现那个新框架就只用再写个适配层,而不用改写所有的实现代码吧。
如果考虑适配层,整个日志输出的流程如下:
四,各种日志框架实现关系
日志框架的具体实现与适配层:
五,案例分析
1,slf4j 采用logback的实现(无适配层),工作过程如下:
1.1 在程序中使用slf4j的api获取logger对象,并输出logger
1.2,引入slf4j真正的实现,这里采用logback
1.3,运行结果:
2,slf4j 采用 reload4j 的实现(有适配层),工作过程如下:
2.1 在程序中使用slf4j的api获取logger对象,并输出logger
此步骤与上面一样,略。
2.2 引入依赖
2.3 增加配置文件,不加也可以
2.4 运行结果:
3,总结使用流程
六,slf4J 发现实现类的原理
slf4j 它是怎么知道它的实现类是哪个,是怎么知道实现类的全类名,然后创建它的实例进行使用的呢?
slf4j 1.7.x 及之前,通过JVM类加载机制,发现底层具体的实现类;
slf4j 1.8.x 开始, 通过SPI机制,发现底层具体的实现类;
如果对spi机制不熟悉,看https://blog.csdn.net/weixin_43833851/article/details/129699586
1,slf4j 1.7.x 发现实现类的过程分析
slf4j 的代码中,通过 org.slf4j.impl.StaticLogggerBinder.getSingleton() 获取实现类对象,
但是slf4j 中并没有 org.slf4j.impl.StaticLogggerBinder 这个类,
谁想实现slf4j,谁就在自己的代码里面写一个 org.slf4j.impl.StaticLogggerBinder 类,定义getSingleton()方法返回实现类对象。
比如阿里想写个slf4j的实现,包名肯定是com.alibaba开头,但是还得建个 org.slf4j.impl包,里面放一个StaticLogggerBinder 类。
那slf4j 中没有 org.slf4j.impl.StaticLogggerBinder 这个类是怎么编译通过的呢?
它为了能编译通过,先在代码里面定义这个类,打好jar包后,删除jar包里面的这个类的class文件。
源码如下:
如果一个应用里面引入了多个 slf4j的实现,那么就会有多个 org.slf4j.impl.StaticLogggerBinder 这个类,这时会怎么办呢?
先读取哪个就用哪个,其他忽略,不同虚拟机(如hotspot、JRocket等)可能加载顺序不同,所以在不同虚拟机上可能加载的实现框架不一样。
缺点:
1,对slf4j而言,为了能编译通过,需要写一个org.slf4j.impl.StaticLogggerBinder 类,打成jar包后再删除这个类,感觉怪怪的;
2,对实现者而言,还要额外建个org.slf4j.impl包,里面放一个StaticLogggerBinder 类,比如上面举例的阿里想写个slf4j的实现,就觉得很别扭。
2,slf4j 1.8.x 发现实现类的过程分析
使用SPI机制得到实现类对象:
即由slf4j的实现者,在自己jar包的META-INF/services下定义一个org.slf4j.SLF4JServiceProvider 的文件,文件内写上实现类的全限定名,
slf4j通过java.util.ServiceLoader类解析META-INF/services下所有文件从而获取到实现类对象