日志框架Slf4j作用及其实现原理

﹏ヽ暗。殇╰゛Y 2024-03-08 08:07 100阅读 0赞

#### 目录 ####

*   *  1 设计模式门面模式
     *  2 slf4j源码解析

--------------------

### 1 设计模式门面模式 ###

设计模式之门面模式与装饰器模式详解和应用：`https://blog.csdn.net/ZGL_cyy/article/details/129073521`

slf4j是门面模式的典型应用，因此在讲slf4j前，我们先简单回顾一下门面模式，

门面模式，其核心为`外部与一个子系统的通信必须通过一个统一的外观对象进行，使得子系统更易于使用。`

用一张图来表示门面模式的结构为：

![img][]

门面模式的核心为Facade即门面对象，门面对象核心为几个点：

*  知道所有子角色的功能和责任
 *  将客户端发来的请求委派到子系统中，没有实际业务逻辑
 *  不参与子系统内业务逻辑的实现

大致上来看，对门面模式的回顾到这里就可以了，开始接下来对SLF4J的学习。

### 2 slf4j源码解析 ###

我们为什么要使用slf4j，举个例子：

我们自己的系统中使用了logback这个日志系统
    我们的系统使用了A.jar，A.jar中使用的日志系统为log4j
    我们的系统又使用了B.jar，B.jar中使用的日志系统为slf4j-simple
    
    这样，我们的系统就不得不同时支持并维护logback、log4j、slf4j-simple三种日志框架，非常不便。

解决这个问题的方式就是引入一个适配层，由适配层决定使用哪一种日志系统，而调用端只需要做的事情就是打印日志而不需要关心如何打印日志，slf4j或者commons-logging就是这种适配层，slf4j是本文研究的对象。

从上面的描述，我们必须清楚地知道一点：**slf4j只是一个日志标准，并不是日志系统的具体实现**。理解这句话非常重要，slf4j只做两件事情：

*  提供日志接口
 *  提供获取具体日志对象的方法

slf4j-simple、logback都是slf4j的具体实现，log4j并不直接实现slf4j，但是有专门的一层桥接slf4j-log4j12来实现slf4j。

为了更理解slf4j，我们先看例子，再读源码，相信读者朋友会对slf4j有更深刻的认识。

**slf4j应用举例**

上面讲了，我们先定义一个pom.xml，引入相关jar包：

<dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.2.3</version>
      <scope>compile</scope>
    </dependency>
    ...
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>jul-to-slf4j</artifactId>
      <version>1.7.30</version>
      <scope>compile</scope>
    </dependency>

研究的便是slf4j及其实现logback的关系。

而我们的slf4j便是相当于一个Facade层，所用的日志打印都是通过slf4j来转发，但是具体的功能实现是由logback来实现，当然也可以由别的依赖来实现，比如slf4j-simple。

首先我们看springboot框架默认实现：

import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
     
    public class TestLogger {
        
        private static final Logger log = LoggerFactory.getLogger(TestLogger.class);
     
        public static void main(String[] args) {
        
            log.info("test---------->>>>>>>>>>>><<<<<<<");
        }
    }

归根结底，所有的用法都只是片面，我们要理解原理，还是要从源码入手。进入getLogger方法：

public static Logger getLogger(Class<?> clazz) {
        
            Logger logger = getLogger(clazz.getName());
            if (DETECT_LOGGER_NAME_MISMATCH) {
        
                Class<?> autoComputedCallingClass = Util.getCallingClass();
                if (autoComputedCallingClass != null && nonMatchingClasses(clazz, autoComputedCallingClass)) {
        
                    Util.report(String.format("Detected logger name mismatch. Given name: \"%s\"; computed name: \"%s\".", logger.getName(), autoComputedCallingClass.getName()));
                    Util.report("See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation");
                }
            }
     
            return logger;
        }

重点关注

getLogger(clazz.getName())

继续点击：

public static Logger getLogger(String name) {
        
            ILoggerFactory iLoggerFactory = getILoggerFactory();
            return iLoggerFactory.getLogger(name);
        }

日志打印的具体实现便在

public static ILoggerFactory getILoggerFactory() {
        
            if (INITIALIZATION_STATE == 0) {
        
                Class var0 = LoggerFactory.class;
                synchronized(LoggerFactory.class) {
        
                    if (INITIALIZATION_STATE == 0) {
        
                        INITIALIZATION_STATE = 1;
                        performInitialization();
                    }
                }
            }
     
            switch(INITIALIZATION_STATE) {
        
            case 1:
                return SUBST_FACTORY;
            case 2:
                throw new IllegalStateException("org.slf4j.LoggerFactory in failed state. Original exception was thrown EARLIER. See also http://www.slf4j.org/codes.html#unsuccessfulInit");
            case 3:
                return StaticLoggerBinder.getSingleton().getLoggerFactory();
            case 4:
                return NOP_FALLBACK_FACTORY;
            default:
                throw new IllegalStateException("Unreachable code");
            }
        }

日志打印的重点便在于返回

StaticLoggerBinder.getSingleton().getLoggerFactory()

这个对象来实现具体的日志打印工作，那StaticLoggerBinder这个类又是从哪里来，是要干什么的呢？

我们通过实际代码执行可以知道，StaticLoggerBinder便是logback这个jar包提供对slf4j日志接口LoggerFactoryBinder的具体实现，也就是说实际的日志打印slf4j不能执行，只能通过接口的实现类StaticLoggerBinder来进行执行。

`这样的好处便在于slf4j相当于只是提供一个接口或者说标准，但是具体的执行可以由其实现类来执行，这样只要是实现了slf4j标准接口的任意日志框架便都可以来执行日志打印。`

`通过这种方式slf4j可以同时支持多种日志框架，且无需任何配置，只需要引入特定的jar包让其拥有指定全类名的StaticLoggerBinder类即可。`

那么这样也会导致另一个问题，如果系统引入了多个同时实现slf4j接口的类，那么系统怎么办，是否会报错？

这种特殊情况，slf4j也有做处理，其处理方式便是通过打印所有的引入实现类，然后由JVM虚拟机选择一个合适的实现类来执行日志打印。

这样既不会影响系统日志执行，也能使程序员通过日志，清楚的看出系统中存在哪些日志的实现类。

其具体代码在上

private static final void performInitialization() {
        
            bind();
            if (INITIALIZATION_STATE == 3) {
        
                versionSanityCheck();
            }
     
        }

在bind执行：

private static final void bind() {
        
            try {
        
                String msg;
                try {
        
                    Set<URL> staticLoggerBinderPathSet = null;
                    if (!isAndroid()) {
        
                        staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
                        reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
                    }
     
                    StaticLoggerBinder.getSingleton();
                    INITIALIZATION_STATE = 3;
                    reportActualBinding(staticLoggerBinderPathSet);
                } catch (NoClassDefFoundError var7) {
        
    ......

重点便在于

findPossibleStaticLoggerBinderPathSet();//找到潜在的slf4j实现类  
reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);//打印所有的实现类全类名  
reportActualBinding(staticLoggerBinderPathSet);//打印实际的实现类全类名

详细方法如下：

static Set<URL> findPossibleStaticLoggerBinderPathSet() {
        
            LinkedHashSet staticLoggerBinderPathSet = new LinkedHashSet();
     
            try {
        
                ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
                Enumeration paths;
                if (loggerFactoryClassLoader == null) {
        
                    paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
                } else {
        
                    paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
                }
     
                while(paths.hasMoreElements()) {
        
                    URL path = (URL)paths.nextElement();
                    staticLoggerBinderPathSet.add(path);
                }
            } catch (IOException var4) {
        
                Util.report("Error getting resources from path", var4);
            }
     
            return staticLoggerBinderPathSet;
        }

可以看到，其是通过

STATIC_LOGGER_BINDER_PATH

即，

private static String STATIC_LOGGER_BINDER_PATH = "org/slf4j/impl/StaticLoggerBinder.class

也就是指定的全限定类名来进行加载的。

这样就涉及到一个问题， 不同的jar包依赖是可以创建同样的全限定类名的，这样会导致

paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);

出现多个具有同样全限定类名的类被重复找到。

那么在slf4j有多个实现的时候，如何保证其加载指定的实现呢？

`实测：如果有多个日志实现的话，默认使用先导入的实现`

[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/30f0f2eb0d8948faa0a5f3d9b8396acf.png