本文綜合參考，原鏈接已附文章最下。
logback是java的日誌開源組件，是log4j創始人寫的，性能比log4j要好，目前主要分爲3個模塊
logback-core:核心代碼模塊
logback-classic:log4j的一個改良版本，同時實現了slf4j的接口，這樣你如果之後要切換其他日誌組件也是一件很容易的事
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在啓動的時候，會按照下面的順序加載配置文件
如果java程序啓動時指定了logback.configurationFile屬性，就用該屬性指定的配置文件。如java -Dlogback.configurationFile=/path/to/mylogback.xml Test ，這樣執行Test類的時候就會加載/path/to/mylogback.xml配置
在classpath中查找 logback.groovy 文件
在classpath中查找 logback-test.xml 文件
在classpath中查找 logback.xml 文件
如果是 jdk6+,那麼會調用ServiceLoader 查找 com.qos.logback.classic.spi.Configurator接口的第一個實現類
自動使用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節點相關屬性
屬性名稱 默認值 介紹
debug false 要不要打印 logback內部日誌信息，true則表示要打印。建議開啓
scan true 配置發送改變時，要不要重新加載
scanPeriod 1 seconds 檢測配置發生變化的時間間隔。如果沒給出時間單位，默認時間單位是毫秒
configuration子節點介紹
1. contextName節點
設置日誌上下文名稱，後面輸出格式中可以通過定義 %contextName 來打印日誌上下文名稱
2.property節點
用來設置相關變量,通過key-value的方式配置，然後在後面的配置文件中通過 ${key}來訪問
3.appender 節點
日誌輸出組件，主要負責日誌的輸出以及格式化日誌。常用的屬性有name和class
屬性名稱 默認值 介紹
name 無默認值 appender組件的名稱，後面給logger指定appender使用
class 無默認值 appender的具體實現類。常用的有 ConsoleAppender、FileAppender、RollingFileAppender
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的博客，雖然也做了一些簡單的測試，但並不保證全部都是正確的。
簡單的說，Logger可以理解是RootLogger的子類重寫。
Case1:
如果RootLogger的level是error，而Logger的level是debug且additivity是true，那麼當Logger記錄debug日誌的時候，RootLogger也會記錄debug日誌，也就是說Logger的level把RootLogger裏的level也覆蓋了。
Case2:
如上一個Case，如果出現更精確的控制配置的Logger，則其level會覆蓋作用域更大的Logger的配置。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓對以下case3的說法表示懷疑，懷疑作用域說反了↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Case3:
如果三個Logger作用域大小分別爲 Logger1>Logger2>Logger3，如果Logger1的additivity是true而Logger2的additivity是false，則logger3不會記錄日誌。
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑對以上case3的說法表示懷疑，懷疑作用域說反了↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Cas4:
Appender最終能夠決定日誌能不能輸出到控制檯或者文本里，優先級最高。
————————————————
版權聲明：本文爲CSDN博主「仰望星空的塵埃」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u010285974/article/details/108564200
————————————————
版權聲明：本文爲CSDN博主「瘋狂哈丘」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u013332124/article/details/82286573