【Log日誌】Java日誌框架:slf4j作用及其實現原理

簡單回顧門面模式

slf4j是門面模式的典型應用,因此在講slf4j前,我們先簡單回顧一下門面模式,

門面模式,其核心爲外部與一個子系統的通信必須通過一個統一的外觀對象進行,使得子系統更易於使用。用一張圖來表示門面模式的結構爲:

門面模式的核心爲Facade即門面對象,門面對象核心爲幾個點:

  • 知道所有子角色的功能和責任
  • 將客戶端發來的請求委派到子系統中,沒有實際業務邏輯
  • 不參與子系統內業務邏輯的實現

大致上來看,對門面模式的回顧到這裏就可以了,開始接下來對SLF4J的學習。

 

我們爲什麼要使用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應用舉例

上面講了,slf4j的直接/間接實現有slf4j-simple、logback、slf4j-log4j12,我們先定義一個pom.xml,引入相關jar包:

<!-- 原文:五月的倉頡http://www.cnblogs.com/xrq730/p/8619156.html -->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
      <modelVersion>4.0.0</modelVersion>

      <groupId>org.xrq.log</groupId>
      <artifactId>log-test</artifactId>
      <version>1.0.0</version>
      <packaging>jar</packaging>

      <name>log-test</name>
      <url>http://maven.apache.org</url>

      <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
      </properties>

      <dependencies>
        <dependency>
            <groupId>junit</groupId>
              <artifactId>junit</artifactId>
              <version>4.11</version>
              <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>1.7.25</version>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.2.3</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-simple</artifactId>
            <version>1.7.25</version>
        </dependency>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.17</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.7.21</version>
        </dependency>
      </dependencies>
</project>

寫一段簡單的Java代碼:

@Test
public void testSlf4j() {
    Logger logger = LoggerFactory.getLogger(Object.class);
    logger.error("123");
}

接着我們首先把上面pom.xml的第30行~第49行註釋掉,即不引入任何slf4j的實現類,運行Test方法,我們看一下控制檯的輸出爲:

 

看到沒有任何日誌的輸出,這驗證了我們的觀點:slf4j不提供日誌的具體實現,只有slf4j是無法打印日誌的

接着打開logback-classic的註釋,運行Test方法,我們看一下控制檯的輸出爲:

看到我們只要引入了一個slf4j的具體實現類,即可使用該日誌框架輸出日誌。

最後做一個測驗,我們把所有日誌打開,引入logback-classic、slf4j-simple、log4j,運行Test方法,控制檯輸出爲:

和上面的差別是,可以輸出日誌,但是會輸出一些告警日誌,提示我們同時引入了多個slf4j的實現,然後選擇其中的一個作爲我們使用的日誌系統。

從例子我們可以得出一個重要的結論,即slf4j的作用:只要所有代碼都使用門面對象slf4j,我們就不需要關心其具體實現,最終所有地方使用一種具體實現即可,更換、維護都非常方便

 

slf4j實現原理

上面看了slf4j的示例,下面研究一下slf4j的實現,我們只關注重點代碼。

slf4j的用法就是常年不變的一句"Logger logger = LoggerFactory.getLogger(Object.class);",可見這裏就是通過LoggerFactory去拿slf4j提供的一個Logger接口的具體實現而已,LoggerFactory的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 " + LOGGER_NAME_MISMATCH_URL + " for an explanation");
        }
    }
    return logger;
}

從第2行開始跟代碼,一直跟到LoggerFactory的bind()方法:

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 " + LOGGER_NAME_MISMATCH_URL + " for an explanation");
        }
    }
    return logger;
}

這個地方第7行是一個關鍵,看一下代碼:

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 " + LOGGER_NAME_MISMATCH_URL + " for an explanation");
        }
    }
    return logger;
}

這個地方重點其實就是第12行的代碼,getLogger的時候會去classpath下找STATIC_LOGGER_BINDER_PATH,STATIC_LOGGER_BINDER_PATH值爲"org/slf4j/impl/StaticLoggerBinder.class",即所有slf4j的實現,在提供的jar包路徑下,一定是有"org/slf4j/impl/StaticLoggerBinder.class"存在的,我們可以看一下:

我們不能避免在系統中同時引入多個slf4j的實現,所以接收的地方是一個Set。大家應該注意到,上部分在演示同時引入logback、slf4j-simple、log4j的時候會有警告:

這就是因爲有三個"org/slf4j/impl/StaticLoggerBinder.class"存在的原因,此時reportMultipleBindingAmbiguity方法控制檯輸出語句:

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 " + LOGGER_NAME_MISMATCH_URL + " for an explanation");
        }
    }
    return logger;
}

那網友朋友可能會問,同時存在三個"org/slf4j/impl/StaticLoggerBinder.class"怎麼辦?首先確定的是這不會導致啓動報錯,其次在這種情況下編譯期間,編譯器會選擇其中一個StaticLoggerBinder.class進行綁定,這個地方sfl4j也在reportActualBinding方法中報告了綁定的是哪個日誌框架:

private static void reportActualBinding(Set<URL> binderPathSet) {
    // binderPathSet can be null under Android
    if (binderPathSet != null && isAmbiguousStaticLoggerBinderPathSet(binderPathSet)) {
        Util.report("Actual binding is of type [" + StaticLoggerBinder.getSingleton().getLoggerFactoryClassStr() + "]");
    }
}

對照上面的截圖,看最後一行,確實是"Actual binding is of type..."這句。

最後StaticLoggerBinder就比較簡單了,不同的StaticLoggerBinder其getLoggerFactory實現不同,拿到ILoggerFactory之後調用一下getLogger即拿到了具體的Logger,可以使用Logger進行日誌輸出。

 

作者:五月的倉頡
鏈接:https://www.cnblogs.com/xrq730/p/8619156.html
來源:掘金
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章