Java日誌之Slf4j,Log4J,logback原理總結

幾乎任何應用,一定是需要日誌的。

那麼,面對種類繁多的日誌框架和配置,我們該何去何從?

1.前奏:我是在研究mybatis源碼的過程中才意識到需要搞明白日誌原理這回事,因為mybatis(和一些其他開源框架,比如rocketmq)都有自己的日誌系統,他們在框架內部都使用的是自己的日誌API,那麼,為什麼他們不像我們平常那樣配置一個log4j呢?根本原因我也不太清楚,不過我猜測可能有這麼一些理由,這些框架比較老,當初還沒有slf4j這種事實上的標準,另一方面,有一些特殊的定製化的日誌。徹底研究清楚mybatis的日誌系統之後,個人覺得這一塊設計得不太好,至少今天看來,不太優雅,因為本來一個slf4j就能搞定所有,非得在源碼中加入自己的org.apache.ibatis.logging這個包,裡面包含一些適配器,雖然代碼並不複雜,但是有點多此一舉。

2.原理:slf4j是標準,也是門面,他對用戶提供統一的API,而下方對接各個日誌框架。這有點類似JVM,我們Java開發者使用統一的API,而JVM對接各個操作系統。嚴格意義上說slf4j自身並不提供日誌具體實現。圖片來自:https://www.cnblogs.com/hanszhao/p/9754419.html

Java日誌之Slf4j,Log4J,logback原理總結

3.slf4j採用的是SPI機制,指定一個標準的目錄結構:org.slf4j.impl.StaticLoggerBinder,然第三方的框架都必須存在一個這樣的類,用於和slf4j建立關係,比如slf4j-simple.jar,logback,這兩個直接實現了slf4j的接口,而對於log4j這種則需要一箇中間適配器slf4j-log4j12。於是乎,當調用slf4j的Logger logger = LoggerFactory.getLogger(XXX.class)的時候,雖然使用的是slf4j的api,但是真正輸出日誌的是具體的日誌框架,這樣子做的好處就是,當某一天你希望更換日誌框架了,只需要把具體日誌框架的jar包替換掉,不需要更改任何一行代碼,就能實現日誌框架的切換。

4.slf4j是如何發現具體日誌框架的,這就得意於spi機制,前面說每個日誌框架都需要存在一個org.slf4j.impl.StaticLoggerBinder類,log4j則是通過中間適配器slf4j-log4j12。當調用LoggerFactory.getLogger的時候,就會去classpath中尋找StaticLoggerBinder這個類,如果不存在或者存在超過1個,那麼會報錯,classpath有且只能存在一個StaticLoggerBinder類。

5.分析mybatis的日誌框架:mybatis有一套屬於自己的日誌系統,日誌api是:Log log = LogFactory.getLog(xxx.class),於此同時,封裝了幾個主流的日誌框架適配器,包括:SLF4J | LOG4J | LOG4J2 | JDK_LOGGING | COMMONS_LOGGING | STDOUT_LOGGING | NO_LOGGING,當調用Log log = LogFactory.getLog(xxx.class)時,會初始化眾多適配器中的一個,可以在mybatis的配置文件中通過logImpl指定具體的一個,如果不指定那麼默認使用SLF4J,因為這裡在LogFactory類中的靜態代碼快第一個就是SLF4J:

 static {
tryImplementation(LogFactory::useSlf4jLogging);
tryImplementation(LogFactory::useCommonsLogging);

tryImplementation(LogFactory::useLog4J2Logging);
tryImplementation(LogFactory::useLog4JLogging);
tryImplementation(LogFactory::useJdkLogging);
tryImplementation(LogFactory::useNoLogging);
}

假設使用默認配置,那麼就會初始化Slf4jImpl類,這個類內部有個代理log,這個代理log就是Logger logger = LoggerFactory.getLogger(clazz),這就回歸到slf4j的標準使用方式上面來了,mybatis打印日誌,其實就是代理對象在打印,而代理對象就是classpath中配置的具體日誌框架。

6.分析log4j是如何與slf4j整合的:前面說到,要使用log4j就必須引入slf4j-log4j12這個jar包,而這個jar包中同樣存在一個StaticLoggerBinder類,當我們調用LoggerFactory.getLogger(clazz)的時候,同樣是初始化StaticLoggerBinder,然後調用利用ILoggerFactory創建一個log4j的Logger實例,代碼如下:

 1 public class Log4jLoggerFactory implements ILoggerFactory {
2
3 // key: name (String), value: a Log4jLoggerAdapter;
4 ConcurrentMap<string> loggerMap;
5
6
7 public Log4jLoggerFactory() {
8 loggerMap = new ConcurrentHashMap<string>();
9 }
10
11 /*
12 * (non-Javadoc)
13 *
14 * @see org.slf4j.ILoggerFactory#getLogger(java.lang.String)
15 */
16 public Logger getLogger(String name) {
17 Logger slf4jLogger = loggerMap.get(name);
18 if (slf4jLogger != null) {
19 return slf4jLogger;
20 } else {
21 org.apache.log4j.Logger log4jLogger;
22 if(name.equalsIgnoreCase(Logger.ROOT_LOGGER_NAME))
23 log4jLogger = LogManager.getRootLogger();

24 else
25 log4jLogger = LogManager.getLogger(name);
26
27 Logger newInstance = new Log4jLoggerAdapter(log4jLogger);
28 Logger oldInstance = loggerMap.putIfAbsent(name, newInstance);
29 return oldInstance == null ? newInstance : oldInstance;
30 }
31 }
32 }
/<string>/<string>

最關鍵的一行就是第27行Logger newInstance = new Log4jLoggerAdapter(log4jLogger),slf4j的Logger對象實際上是一個log4j的適配器對象(也是代理對象),當slf4j調用比如debug方法的時候,實際上是代理對象(也就是真實的log4j對象)在調用debug方法。


分享到:


相關文章: