關於java的日誌框架

　　

Log4j

　　Log4j是Apache的一個開放源代碼項目，Spring Boot1.4以及以後的版本已經不支持log4j ，log4j也好久沒有更新了，如今已經有不少其餘的日誌框架對Log4j進行了改良，好比說SLF4J、Logback等。

Log4j2

　　並且Log4j 2在各個方面都與Logback很是類似，那麼爲何咱們還須要Log4j 2呢

       1. 插件式結構。Log4j 2支持插件式結構。咱們能夠根據本身的須要自行擴展Log4j 2. 咱們能夠實現本身的appender、logger、filter。 
　　2. 配置文件優化。在配置文件中能夠引用屬性，還能夠直接替代或傳遞到組件。並且支持json格式的配置文件。不像其餘的日誌框架，它在從新配置的時候不會丟失以前的日誌文件。 
　　3. Java 5的併發性。Log4j 2利用Java 5中的併發特性支持，儘量地執行最低層次的加鎖。解決了在log4j 1.x中存留的死鎖的問題。 
　　4. 異步logger。Log4j 2是基於LMAX Disruptor庫的。在多線程的場景下，和已有的日誌框架相比，異步的logger擁有10倍左右的效率提高。

　　官方建議通常程序員查看的日誌改爲異步方式，一些運營日誌改爲同步。日誌異步輸出的好處在於，使用單獨的進程來執行日誌打印的功能，能夠提升日誌執行效率，減小日誌功能對正常業務的影響。

       異步日誌在程序的classpath須要加載disruptor-3.0.0.jar或者更高的版本。

　　　　<dependency>

 <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.3.6</version> </dependency>

異步日誌分爲兩種： 

a.全異步模式 
　　這種異步日誌方式，不須要修改修改原理的配置文件，Logger仍然使用<root> and <logger> 
　　只須要在主程序代碼開頭，加一句系統屬性的代碼：

 　System.setProperty("Log4jContextSelector", "org.apache.logging.log4j.core.async.AsyncLoggerContextSelector"); 

b.異步和非異步混合輸出模式 

   在配置文件中Logger使用<asyncRoot> or <asyncLogger>

<loggers> <AsyncLogger name="AsyncLogger" level="trace" includeLocation="true"> <appender-ref ref="Console" /> <appender-ref ref="debugLog" /> <appender-ref ref="errorLog" /> </AsyncLogger> <asyncRoot level="trace" includeLocation="true"> <appender-ref ref="Console" /> </asyncRoot> </loggers> 

引入log4j2依賴 
　　在建立Spring Boot工程時，咱們引入了spring-boot-starter，其中包含了spring-boot-starter-logging，該依賴內容就是Spring Boot默認的日誌框架Logback，

因此咱們在引入log4j2以前，須要先排除該包的依賴，再引入log4j2的依賴。

　　log4j2.xml配置 
有一點須要注意的是，假如想要在application.properties中指定日誌文件存放路徑或日誌文件名，在log4j2.xml中使用${LOG_PATH}或者${LOG_FILE}來引用，是沒法獲取到的（在logback中能夠盡情使用）。

 log4j2支持xml、json、yaml等格式的配置文件。

 

SLF4J

SLF4J，即簡單日誌門面（Simple Logging Facade for Java），不是具體的日誌解決方案，而是經過Facade Pattern提供一些Java logging API，它只服務於各類各樣的日誌系統。
按照官方的說法，SLF4J是一個用於日誌系統的簡單Facade，容許最終用戶在部署其應用時使用其所但願的日誌系統。做者建立SLF4J的目的是爲了替代Jakarta Commons-Logging。 
實際上，SLF4J所提供的核心API是一些接口以及一個LoggerFactory的工廠類。在使用SLF4J的時候，不須要在代碼中或配置文件中指定你打算使用那個具體的日誌系統。
相似於Apache Common-Logging，SLF4J是對不一樣日誌框架提供的一個門面封裝，能夠在部署的時候不修改任何配置便可接入一種日誌實現方案。
可是，他在編譯時靜態綁定真正的Log庫。使用SLF4J時，若是你須要使用某一種日誌實現，那麼你必須選擇正確的SLF4J的jar包的集合（各類橋接包）。
SLF4J提供了統一的記錄日誌的接口，只要按照其提供的方法記錄便可，最終日誌的格式、記錄級別、輸出方式等經過具體日誌系統的配置來實現，所以能夠在應用中靈活切換日誌系統。

那麼何時使用SLF4J比較合適呢？ 
若是你開發的是類庫或者嵌入式組件，那麼就應該考慮採用SLF4J，由於不可能影響最終用戶選擇哪一種日誌系統。在另外一方面，若是是一個簡單或者獨立的應用，

肯定只有一種日誌系統，那麼就沒有使用SLF4J的必要。假設你打算將你使用log4j的產品賣給要求使用JDK 1.8 Logging的用戶時，面對成千上萬的log4j調用的修改，

相信這絕對不是一件輕鬆的事情。可是若是開始便使用SLF4J，那麼這種轉換將是很是輕鬆的事情。

Logback

Logback，一個「可靠、通用、快速而又靈活的Java日誌框架」。

logback當前分紅三個模塊：

            logback-core，

            logback- classic

            logback-access。

logback-core是其它兩個模塊的基礎模塊。

logback-classic是log4j的一個改良版本。

　　此外logback-classic完整實現SLF4J API使你能夠很方便地更換成其它日誌系統如log4j或JDK Logging。

　　logback-access訪問模塊與Servlet容器集成提供經過Http來訪問日誌的功能。 

　選擇logback的理由： 
1. logback比log4j要快大約10倍，並且消耗更少的內存。 
2. logback-classic模塊直接實現了SLF4J的接口，因此咱們遷移到logback幾乎是零開銷的。 
3. logback不只支持xml格式的配置文件，還支持groovy格式的配置文件。相比之下，Groovy風格的配置文件更加直觀，簡潔。 
4. logback-classic可以檢測到配置文件的更新，而且自動從新加載配置文件。 
5. logback可以優雅的從I/O異常中恢復，從而咱們不用從新啓動應用程序來恢復logger。 
6. logback可以根據配置文件中設置的上限值，自動刪除舊的日誌文件。 
7. logback可以自動壓縮日誌文件。 
8. logback可以在配置文件中加入條件判斷（if-then-else)。能夠避免不一樣的開發環境（dev、test、uat…）的配置文件的重複。 
9. logback帶來更多的filter。 
10. logback的stack trace中會包含詳細的包信息。 
11. logback-access和Jetty、Tomcat集成提供了功能強大的HTTP-access日誌。 
配置文件：須要在項目的src目錄下創建一個logback.xml。 
注：（1）logback首先會試着查找logback.groovy文件； 
（2）當沒有找到時，繼續試着查找logback-test.xml文件； 
（3）當沒有找到時，繼續試着查找logback.xml文件； 
（4）若是仍然沒有找到，則使用默認配置（打印到控制檯）。

 

 

Apache Commons Logging

Apache Commons Logging ，以前叫 Jakarta Commons Logging（JCL）提供的是一個日誌(Log)接口(interface)，同時兼顧輕量級和不依賴於具體的日誌實現工具。它提供給中間件/日誌工具開發者一個簡單的日誌操做抽象，容許程序開發人員使用不一樣的具體日誌實現工具。用戶被假定已熟悉某種日誌實現工具的更高級別的細節。JCL提供的接口，對其它一些日誌工具，包括Log4J, Avalon LogKit, and JDK 1.4+等，進行了簡單的包裝，此接口更接近於Log4J和LogKit的實現。 common-logging是apache提供的一個通用的日誌接口。用戶能夠自由選擇第三方的日誌組件做爲具體實現，像log4j，或者jdk自帶的logging， common-logging會經過動態查找的機制，在程序運行時自動找出真正使用的日誌庫。固然，common-logging內部有一個Simple logger的簡單實現，可是功能很弱。因此使用common-logging，一般都是配合着log4j來使用。使用它的好處就是，代碼依賴是common-logging而非log4j， 避免了和具體的日誌方案直接耦合，在有必要時，能夠更改日誌實現的第三方庫。 使用common-logging的常見代碼：