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下所有文件从而获取到实现类对象