從Log4j遷移到LogBack的理由

英文原文：Reasons to prefer logback over log4j，編譯：oschina

無論從設計上還是實現上，Logback相對log4j而言有了相對多的改進。不過儘管難以一一細數，這裡還是列舉部分理由為什麼選擇logback而不是log4j。牢記logback與log4j在概念上面是很相似的，它們都是有同一群開發者建立。所以如果你已經對log4j很熟悉，你也可以很快上手logback。如果你喜歡使用log4j,你也許會迷上使用logback。

更快的執行速度

基於我們先前在log4j上的工作，logback 重寫了內部的實現，在某些特定的場景上面，甚至可以比之前的速度快上10倍。在保證logback的元件更加快速的同時，同時所需的記憶體更加少。

充分的測試

Logback 歷經了幾年，數不清小時數的測試。儘管log4j也是測試過的，但是Logback的測試更加充分，跟log4j不在同一個級別。我們認為，這正是人們選擇Logback而不是log4j的最重要的原因。人們都希望即使在惡劣的條件下，你的登入依然穩定而可靠。

logback-classic 非常自然的實現了SLF4J

logback-classic中的登陸類自然的實現了SLF4J。當你使用logback-classic作為底層實現時，涉及到LF4J日記系統的問題你完全不需要考慮。更進一步來說，由於 logback-classic強烈建議使用SLF4J作為客戶端日記系統實現，如果需要切換到log4j或者其他，你只需要替換一個jar包即可，不需要去改變那些通過

SLF4J API 實現的程式碼。這可以大大減少更換日記系統的工作量。

擴充套件文件

Logback附帶詳細的和不斷更新的文件。

使用XML配置檔案或者Groovy

配置logback的傳統方法是通過XML檔案。在文件中，大部分例子都是是用XML語法。但是，對於logback版本0.9.22，通過Groovy編寫的配置檔案也得到支援。相比於XML，Groovy風格的配置檔案更加直觀，連貫和簡短的語法。

現在， 已經有一個工具自動把logback.xml檔案遷移至logback.groovy。

自動重新載入配置檔案

Logback-classic可以在配置檔案被修改後，自動重新載入。這個掃描過程很快，無資源爭用，並且可以動態擴充套件支援在上百個執行緒之間每秒上百萬個呼叫。它和應用伺服器結合良好，並且在JEE環境通用，因為它不會呼叫建立一個單獨的執行緒來做掃描。

優雅地從I/O錯誤中恢復

FileAppender和它的子類，包括RollingFileAppender，可以優雅的從I/O錯誤中恢復。所以，如果一個檔案伺服器臨時當機，你再也不需要重啟你的應用，而日誌功能就能正常工作。當檔案伺服器恢復工作，logback相關的appender就會透明地和快速的從上一個錯誤中恢復。

自動清除舊的日誌歸檔檔案

通過設定TimeBasedRollingPolicy 或者 SizeAndTimeBasedFNATP的 maxHistory 屬性，你就可以控制日誌歸檔檔案的最大數量。如果你的回滾策略是每月回滾的，並且你希望儲存一年的日誌，那麼只需簡單的設定maxHistory屬性為12。對於12個月之前的歸檔日誌檔案將被自動清除。

自動壓縮歸檔日誌檔案

RollingFileAppender可以在回滾操作中，自動壓縮歸檔日誌檔案。壓縮通常是非同步執行的，所以即使是很大的日誌檔案，你的應用都不會因此而被阻塞。

謹慎模式

在謹慎模式中，在多個JVM中執行的多個FileAppender例項，可以安全的寫入統一個日誌檔案。謹慎模式可以在一定的限制條件下應用於RollingFileAppender。

Lilith

Lilith是logback的一個記錄和訪問事件檢視器。它相當於log4j的 chainsaw，但是Lilith設計的目的是處理大量的日誌記錄。

配置檔案中的條件處理

開發者通常需要在不同的目標環境中變換logback的配置檔案，例如開發環境，測試環境和生產環境。這些配置檔案大體是一樣的，除了某部分會有不同。為了避免重複，logback支援配置檔案中的條件處理，只需使用<if>,<then>和<else>，那麼同一個配置檔案就可以在不同的環境中使用了。

過濾

Logback擁有遠比log4j更豐富的過濾能力。例如，讓我們假設，有一個相當重要的商業應用部署在生產環境。考慮到大量的交易資料需要處理，記錄級別被設定為WARN，那麼只有警告和錯誤資訊才會被記錄。現在，想象一下，你在開發環境遇到了一個臭蟲，但是在測試平臺中卻很難發現，因為一些環境之間(生產環境/測試環境)的未知差異。

使用log4j，你只能選擇在生產系統中降低記錄的級別到DEBUG，來嘗試發現問題。但是很不幸，這會生成大量的日誌記錄，讓分析變得困難。更重要的是，多餘的日誌記錄會影響到生產環境的效能。

使用logback，你可以選擇保留只所有使用者的WARN級別的日誌，而除了某個使用者，例如Alice，而她就是問題的相關使用者。當Alice登入系統，她就會以DEBUG級別被記錄，而其他使用者仍然是以WARN級別來記錄日誌。這個功能，可以通過在配置檔案的XML中新增4行。請在相關章節中查詢MDCFilter

SiftingAppender

SiftingAppender是一個全能的追加器。它可以基於任何給定的實時屬性分開（或者篩選）日誌。例如，SiftingAppender可以基於使用者會話分開日誌事件，這樣，可以為每一個使用者建立一個獨立的日誌檔案。

堆疊軌跡資訊包含包的資料

當logback列印一個異常，堆疊軌跡資訊將包含包的相關資料。下面是一個通過 logback-demo 生成的堆疊資訊：

從上面的資訊，你可以發現這個應用使用Struts 1.2.9 而且是使用 jetty 6.1.12部署的。所以，堆疊軌跡資訊將快速的告訴讀者，關於異常發生的類還有包和包的版本。當你的客戶傳送一個堆疊軌跡資訊給你，作為一個開發人員，你就不需要讓他們告訴你他們正在使用的包的版本。這項資訊已經包括在堆疊軌跡資訊中。詳細請參考  “%xThrowable” conversion word.

這項功能可以非常有幫助的說明，有些使用者誤以為這是IDE的功能。

Logback-access模組，提供了通過HTTP訪問日誌的能力，是logback不可或缺的部分

最後但絕非最不重要的是，作為logback釋出包的一部分，logback-access模組可與Jetty或者Tomcat進行整合，提供了非常豐富而強大的通過HTTP訪問日誌的功能。因為logback-access模組是logback初期設計方案中的一部分，因此，所有你所喜歡的logback-classic模組所提供的全部特性logback-access同樣也具備。

結束語

我們給出了許多選擇logback而不選擇log4j的理由。簡而言之，既然logback構建於我們先前所構建的log4j之上，logback可以說就是一個更好的log4j。