SLF4J源码分析
介紹
官網：http://www.slf4j.org/
github：https://github.com/qos-ch/slf4j
SLF4J（Simple Logging Facade for Java），它為Java的日志系統提供了一套統一的接口（門面），即：作為各種日志框架（java.util.logging，logback，log4j）的抽象。
通過引入SLF4J，可以使項目與logging具體的實現分離，在提供了一致的接口的同時，提供了靈活選擇logging實現的能力。（引入SLF4J的庫/應用意味著僅添加一個強制性依賴項slf4j-api.jar）
1、為什么要設計出一個日志接口的抽象層？
我們都知道，日志對于一個系統來說非常重要。同樣，我們在開發出了一個庫時，也需要打印一些調試或者運行日志，而我們系統往往會引入大量的第三方庫。這是，就會遇到一個問題：假設我們系統使用的是Log4j日志框架，引入了RMQ庫使用的是Logback框架，這時系統就出現了兩個日志框架，維護起來非常麻煩。
解決這個問題的方法是引入一個適配層。例如：
如果我們都是通過SLF4J這種統一的接口，那么RMQ庫在發布時就無需帶著具體日志框架的實現，這樣我們系統引入RMQ后，仍然使用的是我們系統中引入的日志實現了，這樣就方便了維護。
slf4j只做兩件事情：
- 提供日志接口
- 提供獲取具體日志對象的方法
說明：這種抽象的思想，在軟件開發中很常見。
2、SLF4J和JCL區別：
在SLF4J之前，Apache Common Logging（即Jakarta Commons Logging，簡稱JCL）也提供了類似的功能（即：統一的日志接口）。它與SLF4J的區別在于：
- JCL即提供了統一的接口，也提供了一套默認的實現；SLF4J則只提供了接口層
- JCL采用運行時綁定，通過Classloader體系加載相應的logging實現；SLF4J采用了靜態綁定
- SLF4J在接口易用性上更有優勢，大大減少了不必要的日志拼接：
- JCL為了避免無效的字符串拼接，一般需要通過if判斷：
- SLF4J則提供了占位符"{}"，只在必要的情況下才會進行日志字符串處理和拼接：
推薦使用slf4j中占位符原因主要有兩點：
- 當設置的日志級別高于某條代碼中的日志級別時，使用占位符可以免掉字符串拼接操作；
- 占位符底層使用的是StringBuilder進行的拼接，性能比“+”要好；
注：在SLF4J和JCL中，推薦使用前者。
3、SLF4J使用：
SLF4J的使用非常簡單：
- 引入SLF4J依賴 （slf4j-api.jar）
- 引入一種SLF4J的實現，比如：logback、log4j...
然后：
import org.slf4j.Logger; import org.slf4j.LoggerFactory;public MyClass {Logger logger = LoggerFactory.getLogger(MyClass.class);puhblic void method() {logger.info("hello world...");} }注：從1.6.0開始，如果在類路徑上未找到綁定，則SLF4J將默認為無操作實現；
下圖從SLF4J官網中找到的一個圖，表示了各種實現類和SLF4J的關系：
?
總之，SLF4J接口及其各種適配器非常簡單，不依賴任何類加載器，所以SLF4J不會遇到類加載器問題或Commons Logging（JCL）所觀察??到的內存泄漏。實際上，每個SLF4J綁定在編譯時都進行了硬連線，以使用一個且僅一個特定的日志記錄框架。
靜態綁定原理
和Apache Common Logging不同，SLF4j采用了靜態綁定來確定具體日志庫。靜態綁定就是：
- 每一個具體的日志庫定義一個包名和類名都相同的類： org.slf4j.impl.StaticLoggerBinder，這個類的功能就是調用具體的日志庫，該類存放在Adaptation layer（適配層）或者native implementation of slf4j-api（實現包）的jar包中；（該類在slf4j-api打成jar包時被mvn移除）
- SLF4j的使用者只要把具體日志庫對應的Adaptation layer或者native implementation of slf4j-api的jar包放入classpath中，SLF4j便會裝載(load)對應版本的org.slf4j.impl.StaticLoggerBinder，從而調用具體的日志庫；
- slf4j-api.jar中通過classLoader.getResources("org/slf4j/impl/StaticLoggerBinder.class")來加載classpath中具體的日志庫中的StaticLoggerBinder類；
SLF4J相比JCL的一大優勢是采用了靜態綁定，避免了在OSGI等場景中通過classloader動態綁定造成的困擾。
參考：https://blog.csdn.net/weixin_34248023/article/details/91891106
1、1.7.25版本的slf4j-api.jar靜態綁定過程分析：
1.1）源碼分析：
在demo中可知，使用SLF4J的LoggerFactory.getLogger(Class<?>)方法獲取一個Logger對象，這個過程完成了和具體日志實現類的綁定。通過slf4j-api.jar源碼，SLF4J是調用bind()方法實現的綁定。
1）bind()方法：
?
2）findPossibleStaticLoggerBinderPathSet()方法：
通過jdk提供的ClassLoader.getStstemResources()方法獲取指定資源的URI。
?
可以發現，在slf4j-api.jar包中根本沒有org.slf4j.impl.StaticLoggerBinder 這個類，所以，如果沒有具體的日志實現庫，那么在執行到StaticLoggerBinder.getSingleton()方法時就會拋出NoClassDeffoundException
?
3）日志實現庫：
slf4j-log4j12庫中的org.slf4j.impl.StaticLoggerBinder
1.2）疑問：
通過slf4j源碼，LoggerFactory.java文件有一行import org.slf4j.impl.StaticLoggerBinder; 但是上面我們發現在slf4j-api.jar中居然沒有該org.slf4j.impl.StaticLoggerBinder類，也就是說slf4j-api這個工程是無法編譯通過的，又是如何打成slf4j-api.jar的呢？
寫一個工程A，類似sfl4j-api，然后把StaticLoggerBinder類刪掉，工程雖然報錯，但是可以通過mvn install打包成功；
寫一個工程B，引入A.jar，然后調用其中方法，會發現報錯：Unresolved compilation problem: 從A.jar包中查看相應的LoggerFatory類，居然是這樣的：
可以發現：雖然上面可以用mvn打包成功，但是由于A工程是一個編譯有問題的工程，反編譯字節碼文件可以看到方法全都拋出異常，這說明在打包時，LoggerFactory類生成的字節碼文件是不完整的，帶有錯誤的。
通過slf4j-api源碼可以發現，其實在slf4j-api工程中是有org.slf4j.impl.StaticLoggerBinder.java類的，只是在mvn打包的時候通過ant插件，將org.slf4j.impl.StaticLoggerBinder.class移除掉了。騙過了jdk，使得LoggerFactory.class是一個完整的，可以校驗通過的字節碼文件。
1.3）總結：
先來明確一下 Java 的綁定（Binding）的概念，Java 本身只支持靜態（static）綁定與運行時（runtime）綁定，直到與 JDK 1.6 版本一起發布的 JSR269 才能進行編譯時綁定，編譯時綁定最有代表的是lomok 在編譯過程中修改字節碼。
1.7.25版本的SFL4j 的 logger 實例是 new 出來的（通過StaticLoggerBinder單例），綁定 LogContext 的 StaticLoggerBinder（中介類） 是寫死的，編譯時并沒有處理任何邏輯，也談不上什么編譯時綁定，而且翻遍了 SLF4j 文檔也沒有找到任何有關編譯時綁定的材料，官方只提到了 “static binding”， 所以，SLF4j使用的是 Convention over Configuration（CoC）– 慣例優于配置原則，不管是什么日志框架，只加載org.slf4j.impl.StaticLoggerBinder。這完美契合了軟件設計的 KISS（Keep It Simple, Stupid）原則。
而 Commons-logging 魔法（magic）一樣的動態加載雖然設計很高大上，在應用領域卻直接被打臉，低效率、與 OSGi 共同使用所導致的 ClassLoader 問題更是火上澆油，所以員外與大家共勉，寫代碼切勿炫技。
參考：
https://juejin.im/post/6844903574116237326
https://www.jianshu.com/p/b562b7ff499f
2、1.8版本的slf4j-api.jar靜態綁定過程分析：
SLF4J 1.8中最大的改進就是摒棄了之前的hard code的代碼綁定（要求具體實現日志框架中必須要有一個org.slf4j.impl.StaticLoggerBinder.java），而是使用了更加優雅、耦合更松的SPI方式進行服務發現。我們看看1.8版本slf4j-api中對日志綁定的改進：
- 提供了org.slf4j.spi.SLF4JServiceProvider服務接口用于SPI綁定
- 改進了org.slf4j.LoggerFactory.bind()的實現，采用SPI方式進行SLF4JServiceProvider服務發現和綁定
- 不再支持1.8版本以前的按照約定的類型StaticXxxBinder約定類名進行綁定的方式
由此可見，1.8版本和之前的版本是不兼容的（http://www.slf4j.org/codes.html#version_mismatch）。而且1.8往上的版本都是beta，沒有一個是stable/release的。
說明：（官網）
從客戶端的角度來看，slf4j-api的所有版本都是兼容的。只需要確保綁定的版本與slf4j-api.jar的版本匹配即可。在初始化時，如果SLF4J懷疑可能存在sfl4j-api與綁定版本不匹配的問題，它將發出有關可疑不匹配的警告。
1.1）源碼分析：
1）bind方法：
2）findServiceProviders()方法：
3）日志實現庫：
slf4j-api:1.8.0-beta-2版本，對應的logback-classic版本為logback-classic:1.3.0-alpha4。為了兼容1.8的SLF4J，logback-classic提供了SPI服務配置文件，如下圖。這樣，在啟動階段，SLF4J就可以通過ServiceLoader找到logback-classic并進行注冊了。
同時，最新版的logback也去掉了org.slf.impl包，徹底摒棄了老版本SLF4J的支持。
同樣，在slf4j-log4j12-1.8版本中，也是去掉了org.slf.impl包，提供了SPI服務配置文件：
總結：
slf4j-api1.8版本整個流程和1.7的基本一致，除了采用了更優雅的服務發現機制，在其他方面，SLF4J 1.8與之前版本差別很小。
參考：
https://www.jianshu.com/p/6cf21fb18639
?
總結
- 上一篇： 线上培训！如何添加自定义形态选股策略！股
- 下一篇： 区块链将怎样影响游戏行业