slf4j原理学习

Slf4j是什么

     SLF4J 是 Simple Logging Facade for Java 的缩写（for≈4），也就是简易的日志门面，以外观模式（Facade pattern，一种设计模式，为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用）实现。

slf4j桥接到具体日志框架

    

      可以看到slf4j与具体日志框架结合的方案有很多种。当然，每种方案的最上层（绿色的应用层）都是统一的，它们向下都是直接调用slf4j提供的API（浅蓝色的抽象API层），依赖slf4j-api.jar。然后slf4j API向下再怎么做就非常自由了，几乎可以使用所有的具体日志框架。注意图中的第二层是浅蓝色的，看左下角的图例可知这代表抽象日志API，也就是说它们不是具体实现。如果像左边第一种方案那样下层没有跟任何具体日志框架实现相结合，那么日志是无法输出来的（这里不确定是否可能会默认输出到标准输出）。
      图中第三层明显就不如第一、二层那么整齐划一了，因为这里已经开始涉及到了具体的日志框架。
      首先看第三层中间的两个湖蓝色块，这是适配层，也就是桥接器。左边的slf4j-log4j12.jar桥接器看名字就知道是slf4j到log4j的桥接器，通过适配器模式，适配器向上实现slf4j的接口，向下调用log4j的具体写日志的方法。同样，右边的slf4j-jdk14.jar就是slf4j到Java原生日志实现的桥接器了。它们的下一层分别是对应的日志框架实现，log4j的实现代码是log4j.jar，而jul实现代码已经包含在了JVM runtime中，不需要单独的jar包。
      再看第三层其余的三个深蓝色块。它们三个也是具体的日志框架实现，但是却不需要桥接器，因为它们本身就已经直接实现了slf4j API。slf4j-simple.jar和slf4j-nop.jar这两个不用多说，看名字就知道一个是slf4j的简单实现，一个是slf4j的空实现，平时用处也不大。而logback之所以也实现了slf4j API，据说是因为logback和slf4j出自同一人之手，这人同时也是log4j的作者。
      第三层所有的灰色jar包都带有红框，这表示它们都直接实现了slf4j API，只是湖蓝色的桥接器对slf4j API的实现并不是直接输出日志，而是转去调用别的日志框架的API。

其它日志框架API转调回slf4j

      上图展示了目前为止能安全地从别的日志框架API转调回slf4j的所有三种情形。
      以左上角第一种情形为例，当slf4j底层桥接到logback框架的时候，上层允许桥接回slf4j的日志框架API有log4j和jul。jcl虽然不是什么日志框架的具体实现，但是它的API仍然是能够被转调回slf4j的。要想实现转调，方法就是图上列出的用特定的桥接器jar替换掉原有的日志框架jar，包名类目一致内容不同，通过这种方式实现 slf4j标准。需要注意的是这里不包含logback API到slf4j API的转调，因为logback本来就是slf4j API的实现。
      看完三种情形以后，会发现几乎所有其他日志框架的API，包括jcl的API，都能够随意的转调回slf4j。但是有一个唯一的限制就是转调回slf4j的日志框架不能跟slf4j当前桥接到的日志框架相同。这个限制就是为了防止A-to-B.jar跟B-to-A.jar同时出现在类路径中，从而导致A和B一直不停地互相递归调用，最后堆栈溢出。目前这个限制并不是通过技术保证的，仅仅靠开发者自己保证，这也是为什么slf4j官网上要强调所有合理的方式只有上图的三种情形。

Slf4j搭配Log4j运行方式

Logger logger = LoggerFactory.getLogger(demo.class);//获取日志对象实例

• getLogger提供两个接口getLogger(Class<?> clazz)和getLogger(String name)。getLogger(Class<?> clazz)，最终还是会调用getLogger(String name);

​​​​​​​

• 接下来要获取IloggerFactory的具体实现类LoggerFactory。

• 获取LoggerFactory首先要绑定staticLoggerBinder，每个日志实现jar都会有org.slf4j.impl.StaticLoggerBinder类的实现；SLF4J会通过ClassLoad扫描当前classpath下有多少个org.slf4j.impl.StaticLoggerBinder类，也就找到了有多少个日志实现（通过这样，我们只需在项目中加入日志实现的jar包，编译时即可自动加载，业务代码无须显式依赖，实现解耦）。

​​​​​​​

• 如果有多个org.slf4j.impl.StaticLoggerBinder类，SLF4J会在LoggerFactory.bind()里调用StaticLoggerBinder.getSingleton()随机加载一个日志实现jar的StaticLoggerBinder(饿汉式的单例模式),new StaticLoggerBinder的同时便获得了Log4jLoggerFactory。

• 最后创建并返回LoggerFactory中的logger对象。

public static Logger getLogger(String name) {

    ILoggerFactory iLoggerFactory = getILoggerFactory();

    return iLoggerFactory.getLogger(name);

}

附: 发现一个有趣的现象，在本地idea上运行时，是加载pom.xml里声明的第一个日志实现；但是如果打包好后通过java -jar启动时，其加载的日志实现确实是随机的（是在编译打包时随机加载一个日志实现，所以一旦编译打包好后其加载的那个日志实现就会固定不变）。所以，我们在具体使用时一定要通过排除依赖的方式来确定日志实现，不要由于日志实现的不确定性引入难以排查、不必要的坑。