一、寫在前面
- 隨着歷史發展，Java語言湧現了不少優秀的日誌框架，比如Log4j，Jul，Jcl，slf4j，logback等，它們之前存在了複雜的關係；
- 關係複雜: 多個接口、不同實現、各種轉換器、複雜的橋接器；
- 一個應用會依賴各種三方包，三方包各種依賴不同的日誌組件，管理不善會導致原有日誌配置失效、應用啓動失敗；
- 一般情況下偶爾會發生日誌組件相關問題，會經常記不起來各種日誌組件以及基本的依賴關係 、轉換關係等；
- 一直想整理下Java日誌框架，留作備用，終於到了要好好整理的時候，一切爲了提高工作效率；
- 最後也希望能幫助到大家理解日誌框架、快速排查問題；
二、歷史演進
要弄清楚Java日誌框架,就不可避免的要講到日誌框架的歷史發展，下面以時間先後的順序來一一介紹。
2.1 Log4j
在JDK 1.3及以前，Java打日誌依賴System.out.println(), System.err.println()或者e.printStackTrace()，Debug日誌被寫到STDOUT流，錯誤日誌被寫到STDERR流。這樣打日誌有一個非常大的缺陷，即無法定製化，且日誌粒度不夠細。
於是， Gülcü 於2001年發佈了Log4j，後來成爲Apache 基金會的頂級項目。Log4j 在設計上非常優秀，對後續的 Java Log 框架有長久而深遠的影響，它定義的Logger、Appender、Level等概念如今已經被廣泛使用。Log4j 的短板在於性能，在Logback 和 Log4j2 出來之後，Log4j的使用也減少了。
2.2 J.U.L
受Logj啓發，Sun在Java1.4版本中引入了java.util.logging，但是j.u.l功能遠不如log4j完善，開發者需要自己編寫Appenders（Sun稱之爲Handlers），且只有兩個Handlers可用（Console和File），j.u.l在Java1.5以後性能和可用性纔有所提升。
2.3 J.C.L(commons.logging)
由於項目的日誌打印必然選擇兩個框架中至少一個，這時候，Apache的JCL（commons-logging）誕生了。JCL 是一個Log Facade，只提供 Log API，不提供實現，然後有 Adapter 來使用 Log4j 或者 JUL 作爲Log Implementation。
在程序中日誌創建和記錄都是用JCL中的接口，在真正運行時，會看當前ClassPath中有什麼實現，如果有Log4j 就是用 Log4j, 如果啥都沒有就是用 JDK 的 JUL。
這樣，在你的項目中，還有第三方的項目中，大家記錄日誌都使用 JCL 的接口，然後最終運行程序時，可以按照自己的需求(或者喜好)來選擇使用合適的Log Implementation。如果用Log4j, 就添加 Log4j 的jar包進去，然後寫一個 Log4j 的配置文件；如果喜歡用JUL，就只需要寫個 JUL 的配置文件。如果有其他的新的日誌庫出現，也只需要它提供一個Adapter，運行的時候把這個日誌庫的 jar 包加進去。
不過，commons-logging對Log4j和j.u.l的配置問題兼容的並不好，使用commons-loggings還可能會遇到類加載問題，導致NoClassDefFoundError的錯誤出現。
一切看起來很完美，做到了接口統一和實現分離，項目可以在log4j和Jul之間自由的切換，想用誰就用誰，很簡單，但是現實很殘酷。
2.4 Slf4j & Logback
SLF4J（Simple Logging Facade for Java）和 Logback 也是Gülcü 創立的項目，目的是爲了提供更高性能的實現。
從設計模式的角度說，SLF4J 是用來在log和代碼層之間起到門面作用，類似於 JCL 的 Log Facade。對於用戶來說只要使用SLF4J提供的接口，即可隱藏日誌的具體實現，SLF4J提供的核心API是一些接口和一個LoggerFactory的工廠類，用戶只需按照它提供的統一紀錄日誌接口，最終日誌的格式、紀錄級別、輸出方式等可通過具體日誌系統的配置來實現，因此可以靈活的切換日誌系統。
Logback是log4j的升級版，當前分爲三個目標模塊：
- logback-core：核心模塊，是其它兩個模塊的基礎模塊
- logback-classic：是log4j的一個改良版本，同時完整實現 SLF4J API 使你可以很方便地更換成其它日記系統如log4j 或 JDK14 Logging
- logback-access：訪問模塊與Servlet容器集成提供通過Http來訪問日記的功能，是logback不可或缺的組成部分
Logback相較於log4j有更多的優點：
- 更快的執行速度
- 更充分的測試
- logback-classic 非常自然的實現了SLF4J
- 使用XML配置文件或者Groovy
- 自動重新載入配置文件
- 優雅地從I/O錯誤中恢復
- 自動清除舊的日誌歸檔文件
- 自動壓縮歸檔日誌文件
- 謹慎模式
- Lilith
- 配置文件中的條件處理
- 更豐富的過濾
到這裏，你可能會問：Apache 已經有了個JCL，用來做各種Log lib統一的接口，如果 Gülcü 要搞一個更好的 Log 實現的話，直接寫一個實現就好了，爲啥還要搞一個和SLF4J呢?原因是Gülcü 認爲 JCL 的 API 設計得不好，容易讓使用者寫出性能有問題的代碼。關於這點，你可以參考這篇文章獲得更詳細的介紹：https://zhuanlan.zhihu.com/p/24272450
現在事情就變複雜了。我們有了兩個流行的 Log Facade，以及三個流行的 Log Implementation。Gülcü 是個追求完美的人，他決定讓這些Log之間都能夠方便的互相替換，所以做了各種 Adapter 和 Bridge 來連接:
可以看到甚至 Log4j 和 JUL 都可以橋接到SLF4J，再通過 SLF4J 適配到到 Logback！需要注意的是不能有循環的橋接，比如下面這些依賴就不能同時存在:
- jcl-over-slf4j 和 slf4j-jcl
- log4j-over-slf4j 和 slf4j-log4j12
- jul-to-slf4j 和 slf4j-jdk14
然而，事情在變得更麻煩！
2.5 Log4j2
現在有了更好的 SLF4J 和 Logback，慢慢取代JCL 和 Log4j ，事情到這裏總該大統一圓滿結束了吧。然而維護 Log4j 的人不這樣想，他們不想坐視用戶一點點被 SLF4J / Logback 蠶食，繼而搞出了 Log4j2。
Log4j2 和 Log4j1.x 並不兼容，設計上很大程度上模仿了 SLF4J/Logback，性能上也獲得了很大的提升。Log4j2 也做了 Facade/Implementation 分離的設計，分成了 log4j-api 和 log4j-core。現在好了，我們有了三個流行的Log 接口和四個流行的Log實現，如果畫出橋接關係的圖來回事什麼樣子呢?
三、實戰演示
3.1.Spring Boot環境
3.2. Log4j、JUL、JCL演示
3.3. Log4j2使用
3.4. sl4j 和 logback、log4j
3.5. Log4j2使用
3.6. 最佳實戰
參考文檔
[1] Java的日誌框架梳理 https://www.jianshu.com/p/5326b5cc7d6c
[2]
[3]