logback那些事 – JAVA編程語言程序開發技術文章

logback:

logback可以認為是log4j的升級版,依然出自Ceki Gülcü,使用簡單,隻需要在你的classpath裡包含slf4j-api.jar、logback-core.jar以及logback-classic.jar即可。

簡單代碼示例如下:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.core.util.StatusPrinter;
public class LogTest {

    public static void main(String[] args) {

        Logger logger = LoggerFactory
                .getLogger(LogTest .class.getName());
        logger.debug("Hello world.");

}

其中的logger對象和LoggerFactory都來自slf4j項目,slf4j是一個很好的facade,包裝瞭接口,就像之前寫的一篇文章中的提到的commons-logging框架。

同樣也可以認為logback+slf4j是log4j+commons-logging的升級版吧。

logback的架構:

logback包含3個子工程——classic、core和access。core是其他兩個的基礎,也是logback的核心;classic擴展瞭core,內置瞭slf4j,但也支持各種其他log門面。同log4j一樣,logback的主要構成也是Logger、Appender和Layout。Logger是核心控制器及調用入口,Appender主管配置和寫日志實際process,Layout控制日志樣式,是Appender的重要配置。值得註意的是,3個基本核心居然不都在core模塊中,Logger是在classic裡的。

對於Logger來講,和Log4j一樣,Logger是一個層次結構,每個logger都有一個name屬性在LoggerFactory中被一個map管理著。對於Logback來說,這個factory就是classic下的LoggerContext。這裡插一段自我理解,在做facade模式的時候,代碼結構可能會引入一個占位性質的類,就像slf4j中的StaticLoggerBinder,這個類在org.slf4j.impl包下,是一個單例,但是私有構造函數卻拋出瞭一個異常,這個在不熟悉這種寫法時會產生困惑。其實這是很合理的,logback的classic中也有org.slf4j.impl這個包,其中也有StaticLoggerBinder這個類,但是內容完整瞭許多。這就完成瞭slf4j的任務,同時解除瞭耦合。我認為這種解耦合方式非常好,plugin的感覺。

再回來說LoggerContext,這個對應瞭log4j的LogManager和Hierarchy,用一個hashtable來維護logger的cache。代碼真的是簡潔瞭很多,再回頭看看log4j中LogManager的getLogger方法,就知道logback的簡潔瞭,一個while遍歷省去瞭一個hierarchy。當然這裡得補充一句,log4j包括logback的整個日志框架對於logger對象,是一個層次結構,這也是為什麼log4j中有個Hierarchy的東西的原因。是一個層次的話,對於通過包名來管理日志記錄等級的管理方式來說,就存在著level的控制,也就是說,你某個包名的類被設定瞭日志級別是什麼,那麼對應級別以下的日志才會被打印出來。有這樣一個規則,logger的日志記錄有效level由hierarchy中離它最近且方向向上(upwards)的一個logger的級別決定。如官網上的例子:

 
這裡有4個logger,但是隻有root被設定瞭level是DEBUG,其他幾個logger由於沒有被設定,依照規則,就都是root的level瞭。

第二個例子中,每個logger都自己設定瞭level,那麼依據規則,離它最近的被使用,當然自己離自己最近瞭。

第三個例子裡,X.Y沒有設定level,那麼離它最近且upwards的一個是X,那麼X.Y的level就和X的一樣。
  
level控制是日志框架的基礎,什麼樣的日志在什麼環境下被打印出來,這種設定可以配置才是一個合理的日志系統。一貫的level控制規則如下顯示:

appender這個東西,和log4j是一樣的,支持一個logger有多個appender,在AppenderAttachableImpl裡會維護一個CopyOnWriteArrayList來存放一個logger的appender。每次log的時候都會遍歷這個list裡的appender然後調用對應的doAppend方法。我們在配置的時候每個logger的配置上有個additivity屬性,默認為true。appender這個東西同logger一樣有繼承性。additivity屬性就是控制這種繼承的,true代表開啟,false代表關閉,一般使用都會設置false,因為如果是true,那麼如果appender比較多的話可能日志打的就有點太離譜瞭。 

 

Layout和log4j一樣,我沒有細研究過,但是我認為這是控制輸出的一大法寶,下次研究layout的時候做一個詳細的分享,一般大傢都使用patternLayout,寫個表達式足以。

在之前的那篇寫log的文章中,提到過一個優化寫法,就是不要直接寫出這樣的代碼:

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
構造string參數是復雜且耗時的。要用if判斷一下。而slf4j提供瞭比較合適的解決方法:

Object entry = new SomeObject(); logger.debug("The entry is {}.", entry);
這樣的代碼就更符合程序設計人員的編寫習慣,而且可讀性我認為要遠遠高於用+號連接。但是遺憾的是,這種編碼風格作者並沒有持續貫徹下去,沒有用變長參數,而是用的object[]終止瞭參數的個數。也就是說,你對於多個變量的log的話,隻能這麼寫:

Object[] paramArray = {newVal, below, above};logger.debug("Value {} was inserted between {} and {}.", paramArray);
在執行log的時候,會有一個判斷流程,依據官網上的介紹,我簡要翻譯一下:

1,Get the filter chain decision:如果存在,嘗試調用TurboFilter ,TurboFilter 會設置一個整個上下文范圍的閾值或者過濾掉每個log請求的相關參數。如果這個filter返回的參數是FilterReply.DENY ,那麼log結束;如果FilterReply.NEUTRAL返回,則進入第2步,如果FilterReply.ACCEPT ,直接第3步。

2, Apply the basic selection rule,如果log請求的閾值和高於配置的閾值,那麼放棄處理該log。

3, Create a LoggingEvent object,logback會構建一個LoggingEvent對象,包含瞭所有的請求參數。其中有些參數可能是延遲加載的。

4, Invoking appenders,logback調用doAppend方法。

5, Formatting the output,layout會把LoggingEvent對象按固定格式格式化並返回字符串形式,像SocketAppender這樣的方法不會返回字符串,相似的隻會把它序列化。

6,  Sending out the LoggingEvent,把最終形式打印到對應的目的地址。

流程圖見這裡http://logback.qos.ch/manual/underTheHood.html

最後還是通過性能討論結束這篇短文,性能的東西,我們不去看代碼的話,是無法估計復雜度的變化的。那麼就官網上給出的3條提示,第一點針對參數構建,第二點針對level的定位,這個在看過代碼後,發現確實精簡瞭,尤其是那種復雜的hierarchy結構沒有瞭,線性的鏈條運行起來明顯會快,算是去除冗餘做瞭優化吧。第3條針對說format和write會快,尤其是format被大力投入改進,這個在看過代碼後,可以做個比較。

本文算是一篇半自主半翻譯的文章吧,重在學習。

參考文獻:

http://logback.qos.ch/manual/introduction.html

 

摘自   Change Dir

 

發佈留言