common-logging是apache提供的一個通用的日誌接口。用戶能夠自由選擇第三方的日誌組件做爲具體實現,像log4j,或者jdk自帶的logging, common-logging會經過動態查找的機制,在程序運行時自動找出真正使用的日誌庫。固然,common-logging內部有一個Simple logger的簡單實現,可是功能很弱。因此使用common-logging,一般都是配合着log4j來使用。使用它的好處就是,代碼依賴是common-logging而非log4j, 避免了和具體的日誌方案直接耦合,在有必要時,能夠更改日誌實現的第三方庫。java
使用common-logging的常見代碼:apache
import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; public class A { private static Log logger = LogFactory.getLog(this.getClass()); }
動態查找原理:Log 是一個接口聲明。LogFactory 的內部會去裝載具體的日誌系統,並得到實現該Log 接口的實現類。LogFactory 內部裝載日誌系統的流程以下:編程
首先,尋找org.apache.commons.logging.LogFactory 屬性配置。api
不然,利用JDK1.3 開始提供的service 發現機制,會掃描classpah 下的META-INF/services/org.apache.commons.logging.LogFactory文件,若找到則裝載裏面的配置,使用裏面的配置。框架
不然,從Classpath 裏尋找commons-logging.properties ,找到則根據裏面的配置加載。工具
不然,使用默認的配置:若是能找到Log4j 則默認使用log4j 實現,若是沒有則使用JDK14Logger 實現,再沒有則使用commons-logging 內部提供的SimpleLog 實現。性能
從上述加載流程來看,只要引入了log4j 並在classpath 配置了log4j.xml ,則commons-logging 就會使log4j 使用正常,而代碼裏不須要依賴任何log4j 的代碼。this
slf4j全稱爲Simple Logging Facade for JAVA,java簡單日誌門面。相似於Apache Common-Logging,是對不一樣日誌框架提供的一個門面封裝,能夠在部署的時候不修改任何配置便可接入一種日誌實現方案。可是,他在編譯時靜態綁定真正的Log庫。使用SLF4J時,若是你須要使用某一種日誌實現,那麼你必須選擇正確的SLF4J的jar包的集合(各類橋接包)。spa
使用slf4j的常見代碼:開放源代碼
import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class A { private static Log logger = LogFactory.getLog(this.getClass()); }
slf4j靜態綁定原理:SLF4J 會在編譯時會綁定import org.slf4j.impl.StaticLoggerBinder; 該類裏面實現對具體日誌方案的綁定接入。任何一種基於slf4j 的實現都要有一個這個類。如:org.slf4j.slf4j-log4j12-1.5.6: 提供對 log4j 的一種適配實現。注意:若是有任意兩個實現slf4j 的包同時出現,那麼就可能出現問題。
common-logging經過動態查找的機制,在程序運行時自動找出真正使用的日誌庫。因爲它使用了ClassLoader尋找和載入底層的日誌庫, 致使了象OSGI這樣的框架沒法正常工做,由於OSGI的不一樣的插件使用本身的ClassLoader。 OSGI的這種機制保證了插件互相獨立,然而卻使Apache Common-Logging沒法工做。
slf4j在編譯時靜態綁定真正的Log庫,所以能夠再OSGI中使用。另外,SLF4J 支持參數化的log字符串,避免了以前爲了減小字符串拼接的性能損耗而不得不寫的if(logger.isDebugEnable()),如今你能夠直接寫:logger.debug(「current user is: {}」, user)。拼裝消息被推遲到了它可以肯定是否是要顯示這條消息的時候,可是獲取參數的代價並無倖免。
Apache的一個開放源代碼項目,經過使用Log4j,咱們能夠控制日誌信息輸送的目的地是控制檯、文件、GUI組件、甚至是套接口服務 器、NT的事件記錄器、UNIX Syslog守護進程等;用戶也能夠控制每一條日誌的輸出格式;經過定義每一條日誌信息的級別,用戶可以更加細緻地控制日誌的生成過程。這些能夠經過一個 配置文件來靈活地進行配置,而不須要修改程序代碼。
LogBack
Logback是由log4j創始人設計的又一個開源日記組件。logback當前分紅三個模塊:logback-core,logback- classic和logback-access。logback-core是其它兩個模塊的基礎模塊。logback-classic是log4j的一個 改良版本。此外logback-classic完整實現SLF4J API使你能夠很方便地更換成其它日記系統如log4j或JDK14 Logging。logback-access訪問模塊與Servlet容器集成提供經過Http來訪問日記的功能。
Log4j 與 LogBack 比較
LogBack做爲一個通用可靠、快速靈活的日誌框架,將做爲Log4j的替代和SLF4J組成新的日誌系統的完整實現。LOGBack聲稱具備極佳的性能,「 某些關鍵操做,好比斷定是否記錄一條日誌語句的操做,其性能獲得了顯著的提升。這個操做在LogBack中須要3納秒,而在Log4J中則須要30納秒。 LogBack建立記錄器(logger)的速度也更快:13微秒,而在Log4J中須要23微秒。更重要的是,它獲取已存在的記錄器只需94納秒,而 Log4J須要2234納秒,時間減小到了1/23。跟JUL相比的性能提升也是顯著的」。 另外,LOGBack的全部文檔是全面免費提供的,不象Log4J那樣只提供部分免費文檔而須要用戶去購買付費文檔。
slf4j與其餘各類日誌組件的橋接
應用代碼中使用slf4j接口,接入具體實現的方法
Java 界裏有許多實現日誌功能的工具,最先獲得普遍使用的是 log4j,許多應用程序的日誌部分都交給了 log4j,不過做爲組件開發者,他們但願本身的組件沒關係緊依賴某一個工具,畢竟在同一個時候還有不少其餘不少日誌工具,假如一個應用程序用到了兩個組件,剛好兩個組件使用不一樣的日誌工具,那麼應用程序就會有兩份日誌輸出了。爲了解決這個問題,Apache Commons Logging (以前叫 Jakarta Commons Logging,JCL)粉墨登場,JCL 只提供 log 接口,具體的實現則在運行時動態尋找。這樣一來組件開發者只須要針對 JCL 接口開發,而調用組件的應用程序則能夠在運行時搭配本身喜愛的日誌實踐工具。因此即便到如今你仍會看到不少程序應用 JCL + log4j 這種搭配,不過當程序規模愈來愈龐大時,JCL的動態綁定並非總能成功,具體緣由你們能夠 Google 一下,這裏就再也不贅述了。解決方法之一就是在程序部署時靜態綁定指定的日誌工具,這就是 SLF4J 產生的緣由。跟 JCL 同樣,SLF4J 也是隻提供 log 接口,具體的實現是在打包應用程序時所放入的綁定器(名字爲 slf4j-XXX-version.jar)來決定,XXX 能夠是 log4j12, jdk14, jcl, nop 等,他們實現了跟具體日誌工具(好比 log4j)的綁定及代理工做。舉個例子:若是一個程序但願用 log4j 日誌工具,那麼程序只需針對 slf4j-api 接口編程,而後在打包時再放入 slf4j-log4j12-version.jar 和 log4j.jar 就能夠了。如今還有一個問題,假如你正在開發應用程序所調用的組件當中已經使用了 JCL 的,還有一些組建可能直接調用了 java.util.logging,這時你須要一個橋接器(名字爲 XXX-over-slf4j.jar)把他們的日誌輸出重定向到 SLF4J,所謂的橋接器就是一個假的日誌實現工具,好比當你把 jcl-over-slf4j.jar 放到 CLASS_PATH 時,即便某個組件本來是經過 JCL 輸出日誌的,如今卻會被 jcl-over-slf4j 「騙到」SLF4J 裏,而後 SLF4J 又會根據綁定器把日誌交給具體的日誌實現工具。過程以下Component|| log to Apache Commons LoggingVjcl-over-slf4j.jar --- (redirect) ---> SLF4j ---> slf4j-log4j12-version.jar ---> log4j.jar ---> 輸出日誌看到上面的流程圖可能會發現一個有趣的問題,假如在 CLASS_PATH 裏同時放置 log4j-over-slf4j.jar 和 slf4j-log4j12-version.jar 會發生什麼狀況呢?沒錯,日誌會被踢來踢去,最終進入死循環。因此使用 SLF4J 的比較典型搭配就是把 slf4j-api、JCL 橋接器、java.util.logging(JUL)橋接器、log4j 綁定器、log4j 這5個 jar 放置在 CLASS_PATH 裏。不過並非全部APP容器都是使用 log4j 的,好比 Google AppEngine 它使用的是 java.util.logging(JUL),這時應用 SLF4J 的搭配就變成 slf4j-api、JCL橋接器、logj4橋接器、JUL綁定器這4個 jar 放置在 WEB-INF/lib 裏。