原文地址?譯者：劉小劉

本文漫談java中的日志：以前怎樣使用日志，以及類似SLF4J的庫為我們帶來了什么。

日志是創建軟件時的基本需求之一，常見的用例如：

• 軟件開發過程中的調試
• 生產環境下診斷bug
• 出于安全目的而跟蹤訪問
• 創建統計使用的數據
• 等等

無論用途為何，日志都應該是詳盡、可配置和可靠的。
歷史
在早期，java日志使用System.out.println(), System.err.println() 或 e.printStackTrace()。調試信息輸出到標準輸出System.out，錯誤信息輸出到標準錯誤System.err。在生產環境中，二者都被重定向：前者重定向到null（注：不輸出），后者重定向到需要的日志文件。這種做法夠用但有很大的缺點：不可配置。它是個是或否的開關，要么全記錄要么完全不，不能在某一層或某個包上關注具體的日志。

Log4J充當了救星，它滿足了人們對日志框架的幾乎所有需求。它引入了許多日志框架中今天仍在使用的概念（它是我首個使用的框架所以請原諒我若某個概念其實不是它發明的）：

• Logger的概念,每個logger可以單獨配置
• Appender的概念,每個appender可以將日志輸出到它想要的任何地方（文件、數據庫、消息等等）
• Level的概念,開發人員可以單獨配置是否輸出每條日志

之后，Sun意識到需要在JDK中提供日志特性，它沒有直接使用Log4J，而是模仿Log4J創建了自己的API。然而，新API的完成度不及Log4J。如果你想使用JDK1.4的日志API，你可能必須創建自己的Appender-在java API中叫Handler-因為能直接用的日志目的地只有控制臺和文件。

使用這些框架都需要多份配置，因為不管你選擇哪個，至少有一個你的依賴會使用另一個。Apache Commons Logging是一個將它自己與日志框架連接的API橋梁。庫應該調用commons-logging，這樣庫使用的實際框架和你的工程是相同的，而不是它強制使用的。現實不總是這樣，所以Commons Logging沒有解決雙重配置問題。此外，Commons Logging還會遇到類加載的問題，導致NoClassDefFoundError報錯。

最后，Log4J核心的開發者由于此處不便細說的原因退出了Log4J工程。他創建了另一個日志框架，這個本應成為Log4J第二版的日志框架被命名為SLF4J。

一些奇怪的事實

以下是前述框架困擾我的一些事實，它們不一定都是缺陷但值得指出來：

• Log4J通過maven強制依賴JMS， Mail和JMX，意味著如果你不嫌麻煩特意排除它們那這些就會出現在你工程的類路徑中。
• 類似地，Commons Logging通過maven強制依賴Avalon(另一個日志框架)，Log4J, LogKit和Servlet API(!)
• Log4J中始終包含一個Swing日志查看器，即使它是用在無需展現的環境中，例如批處理或應用服務器。
• Log4J 1.3版的主頁重定向到1.2版，而2.0版還在實驗室階段。

選擇哪個框架？

Log4J是可以選擇的框架（對大多數）但它不再開發了。1.2版是參考，1.3版廢棄了而2.0還處在它的早期階段。
Commons Logging是作為庫的好選擇（相比應用），但我無法忍受類加載器的問題，一次就夠了（最后，我拋開Commons Logging直接用了Log4J）.
JDK1.4日志是標準而且不存在多版本共用的問題，但它缺少太多特性，如果不二次開發如數據庫適配器或其它就不能使用。太糟了。。。但仍未回答這個問題：選擇哪個框架？

最近，我公司的架構師決定使用SLF4J，為什么會選擇它？

SLF4J
SLF4J不及Log4J使用普遍，因為許多架構師和開發者熟悉Log4J而不知道SLF4J，或不關注SLF4J而堅持使用Log4J。此外，Log4J滿足了許多工程的所有日志需求。不過，有趣的是，Hibernate使用了SLF4J。它擁有一些Log4J沒有的美好特性。

簡單的語法

看這個Log4J示例：
Logger.debug("Hello " + name);
由于字符串拼接的問題（注：上述語句會先拼接字符串，再根據當前級別是否低于debug決定是否輸出本條日志，即使不輸出日志，字符串拼接操作也會執行），許多公司強制使用下面的語句，這樣只有當前處于DEBUG級別時才會執行字符串拼接：
if (logger.isDebugEnabled()) {

LOGGER.debug(“Hello ” + name);
}

它避免了字符串拼接問題，但有點太繁瑣了是不是？相對地，SLF4J提供下面這樣簡單的語法:
LOGGER.debug("Hello {}", name);
它的形式類似第一條示例，而又沒有字符串拼接問題，也不像第二條那樣繁瑣。

SLF4J API和實現
此外，SLF4J很好地解耦了API和實現，所以你在開發環境和生產環境中使用它的API都可以極佳地適配。例如，你可以強制使用SLF4J的API，而保持生產環境中用了幾年的舊的Log4J.properties文件。SLF4J的日志實現是LogKit。

SLF4J橋接
SLF4J具有橋接的特性，你可以移除你的工程及其依賴組件使用的所有Log4J和commons-logging包，只使用SLF4J。
SLF4J為每一種日志框架提供一個JAR包：它模仿其它日志框架的API但將實現引向SLF4J的API（進而使用環境中真實的框架）。一點警告：小心不要讓classpath中同時出現同一種日志的橋接庫和實現庫，否則會陷入循環。例如，使用Log4J橋接庫時，每個Log4J的API被引向SLF4J，如果SLF4J的Log4J實現同時存在，會再次引向Log4J，這樣循環下去。

SLF4JAPI和Log4J實現
綜合所有考慮，我的建議是使用SLF4J的API和Log4J的實現。這樣，你仍像以前一樣配置Log4J，但調用更簡單的SLF4J接口。要這樣做，你需要：

操作 位置 描述

加入classpath	slf4j-api.jar*	主API，沒有它就無法使用SLF4J
	slf4j-log4j.jar*	SLF4J的Log4J實現
	jul-to-slf4j.jar*	允許重定向 JDK 1.4日志到 SLF4J
	jcl-over-slf4j.jar*	重定向commons-logging調用到SLF4J
從classpath移除	commons-logging.jar*	會跟 jcl-over-slf4j.jar里的commons-logging API沖突
SLF4JBridgeHandler.install()**	主應用	重定向JDK 1.4日志調用到SLF4J
* Jar名可能包含版本
**只在你需要單一入口或少量調用

如果你的應用在應用服務器中運行，你可能需要修改它的庫和/或配置來達成以上修改。
更多：
SLF4J項目
Log4J項目
Commons Logging項目
Commons Logging類加載問題

原創文章，轉載請注明：?轉載自并發編程網 – ifeve.com本文鏈接地址:?java日志和SLF4J隨想

from:?http://ifeve.com/java-slf4j-think/

總結

以上是生活随笔為你收集整理的java日志和SLF4J随想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。