logback是java的日誌開源元件，是log4j創始人寫的，效能比log4j要好，目前主要分為3個模組

1. logback-core:核心程式碼模組
2. logback-classic:log4j的一個改良版本，同時實現了slf4j的介面，這樣你如果之後要切換其他日誌元件也是一件很容易的事
3. logback-access:訪問模組與Servlet容器整合提供通過Http來訪問日誌的功能

本篇部落格會講解logback的使用、配置詳解、以及logback簡單的一個原理。

一、logback的使用

引入maven依賴

<!--這個依賴直接包含了 logback-core 以及 slf4j-api的依賴-->
 

<dependency>
     <groupId>ch.qos.logback</groupId>
     <artifactId>logback-classic</artifactId>
     <version>1.2.3</version>
</dependency>

然後就可以直接在程式碼中使用slf4j的介面獲取Logger輸出日誌了。（配置在下面的章節介紹）

//這是slf4j的介面，由於我們引入了logback-classic依賴，所以底層實現是logback
private static
 
 final Logger LOGGER = LoggerFactory.getLogger(Test.class);

public static void main(String[] args) throws InterruptedException {
    LOGGER.info("hello world");
}

二、logback的配置

配置獲取順序

logback在啟動的時候，會按照下面的順序載入配置檔案

1. 如果java程式啟動時指定了logback.configurationFile屬性，就用該屬性指定的配置檔案。如java -Dlogback.configurationFile=/path/to/mylogback.xml Test
   ，這樣執行Test類的時候就會載入/path/to/mylogback.xml配置
2. 在classpath中查詢 logback.groovy 檔案
3. 在classpath中查詢 logback-test.xml 檔案
4. 在classpath中查詢 logback.xml 檔案
5. 如果是 jdk6+,那麼會呼叫ServiceLoader 查詢 com.qos.logback.classic.spi.Configurator介面的第一個實現類
6. 自動使用ch.qos.logback.classic.BasicConfigurator,在控制檯輸出日誌

上面的順序表示優先順序，使用java -D配置的優先順序最高，只要獲取到配置後就不會再執行下面的流程。相關程式碼可以看ContextInitializer#autoConfig()方法。

關於SLF4j的日誌輸出級別

在slf4j中，從小到大的日誌級別依舊是trace、debug、info、warn、error。

logback.xml 配置樣例

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="true" scan="true" scanPeriod="1 seconds">

    <contextName>logback</contextName>
    <!--定義引數,後面可以通過${app.name}使用-->
    <property name="app.name" value="logback_test"/>
    <!--ConsoleAppender 用於在螢幕上輸出日誌-->
    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
        <!--定義了一個過濾器,在LEVEL之下的日誌輸出不會被打印出來-->
        <!--這裡定義了DEBUG，也就是控制檯不會輸出比ERROR級別小的日誌-->
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>DEBUG</level>
        </filter>
        <!-- encoder 預設配置為PatternLayoutEncoder -->
        <!--定義控制檯輸出格式-->
        <encoder>
            <pattern>%d [%thread] %-5level %logger{36} [%file : %line] - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!--定義日誌輸出的路徑-->
        <!--這裡的scheduler.manager.server.home 沒有在上面的配置中設定，所以會使用java啟動時配置的值-->
        <!--比如通過 java -Dscheduler.manager.server.home=/path/to XXXX 配置該屬性-->
        <file>${scheduler.manager.server.home}/logs/${app.name}.log</file>
        <!--定義日誌滾動的策略-->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!--定義檔案滾動時的檔名的格式-->
            <fileNamePattern>${scheduler.manager.server.home}/logs/${app.name}.%d{yyyy-MM-dd.HH}.log.gz
            </fileNamePattern>
            <!--60天的時間週期，日誌量最大20GB-->
            <maxHistory>60</maxHistory>
            <!-- 該屬性在 1.1.6版本後 才開始支援-->
            <totalSizeCap>20GB</totalSizeCap>
        </rollingPolicy>
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <!--每個日誌檔案最大100MB-->
            <maxFileSize>100MB</maxFileSize>
        </triggeringPolicy>
        <!--定義輸出格式-->
        <encoder>
            <pattern>%d [%thread] %-5level %logger{36} [%file : %line] - %msg%n</pattern>
        </encoder>
    </appender>

    <!--root是預設的logger 這裡設定輸出級別是debug-->
    <root level="trace">
        <!--定義了兩個appender，日誌會通過往這兩個appender裡面寫-->
        <appender-ref ref="stdout"/>
        <appender-ref ref="file"/>
    </root>

    <!--對於類路徑以 com.example.logback 開頭的Logger,輸出級別設定為warn,並且只輸出到控制檯-->
    <!--這個logger沒有指定appender，它會繼承root節點中定義的那些appender-->
    <logger name="com.example.logback" level="warn"/>

    <!--通過 LoggerFactory.getLogger("mytest") 可以獲取到這個logger-->
    <!--由於這個logger自動繼承了root的appender，root中已經有stdout的appender了，自己這邊又引入了stdout的appender-->
    <!--如果沒有設定 additivity="false" ,就會導致一條日誌在控制檯輸出兩次的情況-->
    <!--additivity表示要不要使用rootLogger配置的appender進行輸出-->
    <logger name="mytest" level="info" additivity="false">
        <appender-ref ref="stdout"/>
    </logger>

    <!--由於設定了 additivity="false" ，所以輸出時不會使用rootLogger的appender-->
    <!--但是這個logger本身又沒有配置appender，所以使用這個logger輸出日誌的話就不會輸出到任何地方-->
    <logger name="mytest2" level="info" additivity="false"/>
</configuration>

配置詳解

configuration節點相關屬性

configuration子節點介紹

1. contextName節點

設定日誌上下文名稱，後面輸出格式中可以通過定義 %contextName 來列印日誌上下文名稱

2.property節點

用來設定相關變數,通過key-value的方式配置，然後在後面的配置檔案中通過 ${key}來訪問

3.appender 節點

日誌輸出元件，主要負責日誌的輸出以及格式化日誌。常用的屬性有name和class

ConsoleAppender：向控制檯輸出日誌內容的元件，只要定義好encoder節點就可以使用。

FileAppender：向檔案輸出日誌內容的元件，用法也很簡單，不過由於沒有日誌滾動策略，一般很少使用

RollingFileAppender：向檔案輸出日誌內容的元件，同時可以配置日誌檔案滾動策略，在日誌達到一定條件後生成一個新的日誌檔案。

appender節點中有一個子節點filter，配置具體的過濾器，比如上面的例子配置了一個內建的過濾器ThresholdFilter，然後設定了level的值為DEBUG。這樣用這個appender輸出日誌的時候都會經過這個過濾器，日誌級別低於DEBUG的都不會輸出來。

在RollingFileAppender中，可以配置相關的滾動策略，具體可以看配置樣例的註釋。

4.logger以及root節點

root節點和logger節點其實都是表示Logger元件。個人覺的可以把他們之間的關係可以理解為父子關係，root是最頂層的logger，正常情況getLogger(“name/class”)沒有找到對應logger的情況下，都是使用root節點配置的logger。

如果配置了logger，並且通過getLogger(“name/class”)獲取到這個logger，輸出日誌的時候，就會使用這個logger配置的appender輸出，同時還會使用rootLogger配置的appender。我們可以使用logger節點的additivity="false"屬性來遮蔽rootLogger的appender。這樣就可以不使用rootLogger的appender輸出日誌了。

關於logger的獲取，一般logger是配置name的。我們再程式碼中經常通過指定的CLass來獲取Logger，比如這樣LoggerFactory.getLogger(Test.class);,其實這個最後也是轉成對應的包名+類名的字串com.kongtrio.Test.class。假設有一個logger配置的那麼是com.kongtrio，那麼通過LoggerFactory.getLogger(Test.class)獲取到的logger就是這個logger。

也就是說，name可以配置包名，也可以配置自定義名稱。

上面說的logger和root節點的父子關係只是為了方便理解，具體的底層實現本人並沒有看，他們之間真正的關係讀者有興趣的話可以去看logback的原始碼

一些特性的支援

在看logback的啟動日誌時，看到下面這句話。

no applicable action for [totalSizeCap], current ElementPath is [[configuration][appender][rollingPolicy][totalSizeCap]]

no applicable action for [maxFileSize], current ElementPath is [[configuration][appender][rollingPolicy][maxFileSize]]

大概意思解析logbck配置時不支援totalSizeCap、maxFileSize的配置。後來查了下，果然，totalSizeCap是在1.1.6之後的版本才開始支援的，切換到1.1.7之後就不會出現這句話了。

maxFileSize比較奇怪，試了目前所有的版本都不支援rollingPolicy—maxFileSize的配置方案，如果配置到triggeringPolicy節點下，又是可以生效的。但是官網給的文件上又有出現rollingPolicy下面的。

Ps:啟動的時候建議多看看日誌，可以及早發現一些問題。比如這些配置沒生效，看到這些日誌就可以馬上調整，而不會因為沒達到預期的效果而造成一些損失。

三、實現原理

slf4j是什麼

slf4j只是一套標準，通俗來講，就是定義了一系列介面，它並不提供任何的具體實現。所以，我們使用這套介面進行開發，可以任意的切換底層的實現框架。

比如，一開始專案用的是log4j的實現，後來發現log4j的效能太差了，想換成logback，由於我們程式碼中都是面向slf4j介面的，這樣我們只要吧log4j的依賴換成logback就可以了。

logback-classic啟動原理

我們在呼叫LoggerFactory.getLogger(Test.class)時，這些介面或者類都是slf4j的，那麼，它是怎麼切換到logback的實現的呢？

為了解決這個問題，我追蹤了一下程式碼，發現logback-classic底下，有一個slf4j的包.

slf4j在初始化時會呼叫org.slf4j.StaticLoggerBinder進行初始化。因此，每個要實現slf4j的日誌元件專案，底下都要有org.slf4j.StaticLoggerBinder的具體實現。這樣slf4j才會在初始化的關聯到具體的實現。

比如logback在自己定義的StaticLoggerBinder做了自己元件的初始化工作。下面是網上找的一個時序圖：

多個依賴包都實現了slf4j

如果引入了多個slf4j的實現依賴包，那麼各個包底下都有org.slf4j.StaticLoggerBinder的實現，這時候slf4j會呼叫哪個包的StaticLoggerBinder實現呢？

這個問題和java的類載入機制有關係，在雙親委派機制的模型中，這些引入的依賴包通常都是由Application ClassLoader來載入的。Application ClassLoader會載入使用者路徑(classpath)上指定的類庫，如果多個org.slf4j.StaticLoggerBinder的jar包實現，類載入器先掃到哪個jar包，就會使用jar包提供的實現。

舉個例子，我們通過 java -classpath a.jar:b.jar Test執行Test類，a.jar和b.jar都定義了org.slf4j.StaticLoggerBinder的實現，那麼執行Test時載入StaticLoggerBinder類就會載入a.jar中的那個定義類。因為a.jar在classpath中排在比較前面。

四、總結

日誌元件的使用一般都非常簡單，幾乎所有的專案中都會用到各種各樣的日誌元件。但是可能就是由於太簡單了，比較少的人會願意深入系統的去了解。本人也只是對logback的配置以及一些簡單的原理做了一些瞭解，並沒有很深入的去看logback的具體實現。

因此，本文的內容大部分都是基於官網的文件以及網上一些其他關於logback的部落格，雖然也做了一些簡單的測試，但並不保證全部都是正確的。