2. 程式人生 > >Java日誌框架解析及實戰分析

Java日誌框架解析及實戰分析

阿新 • • 發佈：2018-11-15

轉載自：
https://zhuanlan.zhihu.com/p/24272450
https://zhuanlan.zhihu.com/p/24275518

作為Java程式設計師，幸運的是，Java 擁有功能和效能都非常強大的日誌庫；不幸的是，這樣的日誌庫有不止一個——相信每個人都曾經迷失在JUL(Java Util Log), JCL(Commons Logging), Log4j, SLF4J, Logback，Log4j2 等等的迷宮中。在我見過的絕大多數專案中，都沒有能夠良好的配置和使用日誌庫。
這篇文章先講述Java常見日誌庫的歷史和關係，後續會講日誌使用的最佳實踐。讓我們從頭(Java Util Log)開始說起吧。

Java Util Log

簡稱JUL，是JDK 中自帶的log功能。雖然是官方自帶的log lib，JUL的使用確不廣泛。主要原因:

  1. JUL從JDK1.4 才開始加入(2002年)，當時各種第三方log lib已經被廣泛使用了
  2. JUL早期存在效能問題，到JDK1.5上才有了不錯的進步，但現在和Logback/Log4j2相比還是有所不如
  3. JUL的功能不如Logback/Log4j2等完善，比如Output Handler就沒有Logback/Log4j2的豐富，有時候需要自己來繼承定製，又比如預設沒有從ClassPath里加載配置檔案的功能

Log4j 1.x

Log4j 是在 Logback 出現之前被廣泛使用的 Log Lib, 由 Gülcü 於2001年釋出，後來成為Apache 基金會的頂級專案。Log4j 在設計上非常優秀，對後續的 Java Log 框架有長久而深遠的影響，也產生了Log4c, Log4s, Log4perl 等到其他語言的移植。Log4j 的短板在於效能，在Logback 和 Log4j2 出來之後，Log4j的使用也減少了。

Commons Logging

簡稱JCL，是Apache下面的專案。JCL 是一個Log Facade，只提供 Log API，不提供實現，然後有 Adapter 來使用 Log4j 或者 JUL 作為Log Implementation。

就像之前所說，JDK現在帶了自己的JUL，然後又有第三方的 Log4j 等日誌庫存在，不同的專案可能各自使用了不同的日誌庫。如果你的專案依賴的其他 lib 各自使用了不同的日誌庫，你想控制日誌行為，就需要針對每個日誌庫都寫一個配置檔案，是不是很酸爽?

然後這個時候 JCL 就出現了。在程式中日誌建立和記錄都是用JCL中的介面，在真正執行時，會看當前ClassPath中有什麼實現，如果有Log4j 就是用 Log4j, 如果啥都沒有就是用 JDK 的 JUL。

這樣，在你的專案中，還有第三方的專案中，大家記錄日誌都使用 JCL 的介面，然後最終執行程式時，可以按照自己的需求(或者喜好)來選擇使用合適的Log Implementation。如果用Log4j, 就新增 Log4j 的jar包進去，然後寫一個 Log4j 的配置檔案；如果喜歡用JUL，就只需要寫個 JUL 的配置檔案。如果有其他的新的日誌庫出現，也只需要它提供一個Adapter，執行的時候把這個日誌庫的 jar 包加進去。

image

到這個時候一切看起來都很簡單，很美好。介面和實現做了良好的分離，在統一的JCL之下，不改變任何程式碼，就可以通過配置就換用功能更強大，或者效能更好的日誌庫實現。

這種簡單美好一直持續到SLF4J出現。

SLF4J/Logback

SLF4J(The Simple Logging Facade for Java) 和 Logback 也是Gülcü 創立的專案，其創立主要是為了提供更高效能的實現。其中，SLF4j 是類似於JCL 的Log Facade，Logback 是類似於Log4j 的 Log Implementation。

之前已經說過，Apache 有了個JCL，用來做各種Log lib統一的介面，如果 Gülcü 要搞一個更好的 Log 實現的話，直接寫一個實現就好了，為啥還要搞一個和SLF4J呢?

原因是Gülcü 認為 JCL 的 API 設計得不好，容易讓使用者寫出效能有問題的程式碼。

比如在用 JCL 輸出一個 debug 級別的 log:

logger.debug("start process request, url:" + url);

這個有什麼問題呢？一般生產環境 log 級別都會設到 info 或者以上，那這條 log 是不會被輸出的。然而不管會不會輸出，這其中都會做一個字串連線操作，然後生產一個新的字串。如果這條語句在迴圈或者被呼叫很多次的函式中，就會多做很多無用的字串連線，影響效能。

所以 JCL 的最佳實踐推薦這麼寫：

if (logger.isDebugEnabled()) {
    logger.debug("start process request, url:" + url);
}

然而開發者常常忽略這個問題或是覺得麻煩而不願意這麼寫。所以SLF4J提供了新的API，方便開發者使用:

logger.debug("start process request, url:{}", url);

這樣的話，在不輸出 log 的時候避免了字串拼接的開銷；在輸出的時候需要做一個字串format，代價比手工拼接字串大一些，但是可以接受。

而 Logback 則是作為 Log4j 的繼承者來開發的，提供了效能更好的實現，非同步 logger，Filter等更多的特性。

現在事情變複雜了。我們有了兩個流行的 Log Facade，以及三個流行的 Log Implementation。Gülcü 是個追求完美的人，他決定讓這些Log之間都能夠方便的互相替換，所以做了各種 Adapter 和 Bridge 來連線:

image

可以看到甚至 Log4j 和 JUL 都可以橋接到SLF4J，再通過 SLF4J 適配到到 Logback!

在這裡需要注意不能搞出迴圈的橋接，比如下面這些依賴就不能同時存在:

  1. jcl-over-slf4j 和 slf4j-jcl
  2. log4j-over-slf4j 和 slf4j-log4j12
  3. jul-to-slf4j 和 slf4j-jdk14

總感覺事情在變得更麻煩呢！

Log4j2

現在有了更好的 SLF4J 和 Logback——你會想事情到這裡總該瞭解了吧，讓他們慢慢取代JCL 和 Log4j 好了。

然而維護 Log4j 的人不這樣想，他們不想坐視使用者一點點被 SLF4J /Logback 蠶食，繼而搞出了 Log4j2。

Log4j2 和 Log4j1.x 並不相容，設計上很大程度上模仿了 SLF4J/Logback，效能上也獲得了很大的提升。

Log4j2 也做了 Facade/Implementation 分離的設計，分成了 log4j-api 和 log4j-core。

現在好了，我們有了三個流行的Log 介面和四個流行的Log實現，如果畫出橋接關係的圖來回事什麼樣子呢?

image

（圖中為了說明方便，log4j2-core實際包為log4j-core, log4j2-api實際包為log4j-api）

是不是感覺有點暈呢？同樣，在新增依賴的時候，要小心不要搞成迴圈依賴。

實際專案中的使用

1. 總是使用Log Facade，而不是具體Log Implementation

正如之前所說的，使用 Log Facade 可以方便的切換具體的日誌實現。而且，如果依賴多個專案，使用了不同的Log Facade，還可以方便的通過 Adapter 轉接到同一個實現上。如果依賴專案使用了多個不同的日誌實現，就麻煩的多了。

具體來說，現在推薦使用 Log4j-API 或者 SLF4j，不推薦繼續使用 JCL。

2. 只新增一個 Log Implementation依賴

毫無疑問，專案中應該只使用一個具體的 Log Implementation，建議使用 Logback 或者Log4j2。如果有依賴的專案中，使用的 Log Facade不支援直接使用當前的 Log Implementation，就新增合適的橋接器依賴。具體的橋接關係可以看上一篇文章的圖。

3. 具體的日誌實現依賴應該設定為optional和使用runtime scope

在專案中，Log Implementation的依賴強烈建議設定為runtime scope，並且設定為optional。例如專案中使用了 SLF4J 作為 Log Facade，然後想使用 Log4j2 作為 Implementation，那麼使用 maven 新增依賴的時候這樣設定:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>${log4j.version}</version>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j-impl</artifactId>
    <version>${log4j.version}</version>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

設為optional，依賴不會傳遞，這樣如果你是個lib專案，然後別的專案使用了你這個lib，不會被引入不想要的Log Implementation 依賴；

Scope設定為runtime，是為了防止開發人員在專案中直接使用Log Implementation中的類，而不適用Log Facade中的類。

4. 如果有必要, 排除依賴的第三方庫中的Log Impementation依賴

這是很常見的一個問題，第三方庫的開發者未必會把具體的日誌實現或者橋接器的依賴設定為optional，然後你的專案繼承了這些依賴——具體的日誌實現未必是你想使用的，比如他依賴了Log4j，你想使用Logback，這時就很尷尬。另外，如果不同的第三方依賴使用了不同的橋接器和Log實現，也極容易形成環。

這種情況下，推薦的處理方法，是使用exclude來排除所有的這些Log實現和橋接器的依賴，只保留第三方庫裡面對Log Facade的依賴。

比如阿里的JStorm就沒有很好的處理這個問題，依賴jstorm會引入對Logback和log4j-over-slf4j的依賴，如果你想在自己的專案中使用Log4j或其他Log實現的話，就需要加上excludes:

<dependency>
    <groupId>com.alibaba.jstorm</groupId>
    <artifactId>jstorm-core</artifactId>
    <version>2.1.1</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>log4j-over-slf4j</artifactId>
        </exclusion>
        <exclusion>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
        </exclusion>
    </exclusions>
</dependency>

5. 避免為不會輸出的log付出代價

Log庫都可以靈活的設定輸出界別，所以每一條程式中的log，都是有可能不會被輸出的。這時候要注意不要額外的付出代價。

先看兩個有問題的寫法：

logger.debug("start process request, url: " + url);
logger.debug("receive request: {}", toJson(request));

第一條是直接做了字串拼接，所以即使日誌級別高於debug也會做一個字串連線操作；第二條雖然用了SLF4J/Log4j2 中的懶求值方式來避免不必要的字串拼接開銷，但是toJson()這個函式卻是都會被呼叫並且開銷更大。

推薦的寫法如下:

logger.debug("start process request, url:{}", url); // SLF4J/LOG4J2
logger.debug("receive request: {}", () -> toJson(request)); // LOG4J2
logger.debug(() -> "receive request: " + toJson(request)); // LOG4J2
if (logger.isDebugEnabled()) { // SLF4J/LOG4J2
    logger.debug("receive request: " + toJson(request)); 
}

6. 日誌格式中最好不要使用行號，函式名等欄位

原因是，為了獲取語句所在的函式名，或者行號，log庫的實現都是獲取當前的stacktrace，然後分析取出這些資訊，而獲取stacktrace的代價是很昂貴的。如果有很多的日誌輸出，就會佔用大量的CPU。在沒有特殊需要的情況下，建議不要在日誌中輸出這些這些欄位。

最後， log中不要輸出稀奇古怪的字元！

部分開發人員為了方便看到自己的log，會在log語句中加上醒目的字首，比如:

logger.debug("========================start process request=============");

雖然對於自己來說是方便了，但是如果所有人都這樣來做的話，那log輸出就沒法看了！正確的做法是使用grep 來看只自己關心的日誌。

實戰示例

日誌中不注意exclude的話，經常會報這種錯：

SLF4J: Found binding in [jar:file:/home/work/bin/miui-ad-schedule-web/miui-ad-schedule-web-1.0-SNAPSHOT.jar!/BOOT-INF/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/work/bin/miui-ad-schedule-web/miui-ad-schedule-web-1.0-SNAPSHOT.jar!/BOOT-INF/lib/log4j-slf4j-impl-2.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

這幾行日誌是說，有多個slf4j的實現，最後選擇了org.slf4j.impl.Log4jLoggerFactory。我們可以看到，實際上是slf4j-log4j12 和 log4j-slf4j-impl 這兩條路都走通了，看上面的圖，可以知道，分別對應的是log4j2 和log4j。

實際專案中選擇的是log4j2+ slf4j的組合，所以最好把log4j這條線exclude掉，防止日誌使用了其他實現。

相關推薦

Java日誌框架解析及實戰分析

轉載自： https://zhuanlan.zhihu.com/p/24272450 https://zhuanlan.zhihu.com/p/24275518 作為Java程式設計師，幸運的是，Java 擁有功能和效能都非常強大的日誌庫；不幸的是，這樣的日誌庫有不止一個——相信每個人都曾經迷失在JUL(J

Java日誌框架研究及常見配置

按照基本的定義，日誌即是對程式執行過程中關鍵事件的記錄；大體日誌分為執行日誌和開發日誌，執行日誌在業務層面記錄一些關鍵事件，為後面的跟蹤執行提供幫助，而開發日誌大多數時候是除錯日誌，根據事件流的輸出來除錯程式；因為開發人員本身的關注領域，執行日誌可能製作的比較少，難以達到

Java常用的日誌框架對比和深入分析

Java前言 作為一名資深的開發人員，對於日誌記錄框架一定不會很陌生。而且幾乎在所有應用裏面，一定會用到各種各樣的 日誌框架用來記錄程序的運行信息。而對於一個成熟的java應用，這個是必不可少的。在開發和調試階段，日誌可以幫助我們更快的定位問題；而在應用的運維過程中，日誌系統又可以幫助我們記錄大部分的異常信

java日誌框架log4j詳細配置及與slf4j聯合使用教程

注： 更讓你理解facade門面模式，更讓你理解jvm的run anyway 一、log4j基本用法 　　首先，配置log4j的jar，maven工程配置以下依賴，非maven工程從maven倉庫下載jar新增到“build path” 1 2

Java日誌框架-logback的介紹及配置使用方法（純Java工程）

說明：內容估計有些舊，2011年的，但是大體意思應該沒多大變化，最新的配置可以參考官方文件。 一、logback的介紹 Logback是由log4j創始人設計的又一個開源日誌元件。logback當前分成三個模組：logback-core，logback- classic和

JAVA日誌框架log4j和slf4j

writer class 基本 鏈接 發送 控制 spa com 內容 1 org.apache.log4j.ConsoleAppender（控制臺） 2 org.apache.log4j.FileAppender（文件） 3 org.apache.log4j.Daily

Java日誌框架：slf4j作用及其實現原理

sof cat 打開 系統 aging .get matching ade you 簡單回顧門面模式 slf4j是門面模式的典型應用，因此在講slf4j前，我們先簡單回顧一下門面模式， 門面模式，其核心為外部與一個子系統的通信必須通過一個統一的外觀對象進行，使得子系統更易於

Java 遠端通訊技術及原理分析

//轉自：http://www.codeceo.com/article/java-remoted-communication.html //轉自：https://zhuanlan.zhihu.com/p/21380797 在分散式服務框架中，一個最基礎的問題就是遠端服務是怎麼通

以太坊原始碼解讀（5）BlockChain類的解析及NewBlockChain()分析

一、blockchain的資料結構 type BlockChain struct { chainConfig *params.ChainConfig // 初始化配置 cacheConfig *CacheConfig // 快取配置 db ethdb.Databas

Java日誌框架介紹

一.序言 線上問題的排查 通過日誌資料進行使用者行為分析等 二.日誌框架分類及其歷史 框架的種類： JDK自身帶的 Log4J1及其Log4J2： LogBack： Commons Logging：門面框架 SLF：門面框架 框架歷史： 框架之間關係： SLF與Commons Log

deformable convolution（可變形卷積）演算法解析及程式碼分析

可變形卷積是指卷積核在每一個元素上額外增加了一個引數方向引數，這樣卷積核就能在訓練過程中擴充套件到很大的範圍。 可變形卷積的論文為：Deformable Convolutional Networks【1】 而之前google一篇論文對這篇論文有指導意義：Spatial

Java集合框架之ArrayList原始碼分析

分析： java集合框架主要包括兩種型別的容器，集合（Collection）,儲存元素集合，圖(Map)，儲存鍵值對對映，而Collection介面又有三種子型別：List，Set,Queue,然後是一些抽象類，最後是一些實現類，常用ArrayList,Lin

Java日誌框架——JCL

JCL，全稱為"Jakarta Commons Logging"，也可稱為"Apache Commons Logging"。 一、JCL原理1、基本原理 JCL這個日誌框架跟Log4J，Java Logging API等日誌框架不同。JCL採用了設計模式中的“介面卡模式”

幾種常見的JAVA日誌框架的簡單介紹

介面級別的Java日誌框架：slf4j 和common-log 實現級別的：JDK自帶的, log4j, log4j2, logback(這個是slf4j旗下的具體實現) 為什麼會有介面呢？是為了方便日誌框架的選擇：slf4j 和common-log 都能自動識別你要用的日誌的框

JAVA 日誌框架一覽

日誌門面 日誌實現 JCL（Apache Commons Logging） SLF4j(Simple Logging Facade for Java (SLF4J)) JBoss Logging

MEAN 框架 解析 及安裝步驟

在 2002 年的一本著作中，David Weinberger 將發展迅速的 Web 內容描述成一個 小塊鬆散組合（Small Pieces Loosely Joined）。這個比喻讓我印象深刻，因為大家一般很容易認為 Web 是一個巨大的技術堆疊。實際上，您訪問的每個

FFmpeg框架解析及核心資料結構

ffmpeg關鍵資料結構及對應的協議層 功能 結構體 整個音視訊檔案的抽象(包含下面所有結構體) AVFormatContext 協議層 AVIOContext 封裝格式層 AVInputFormat/AVO

Java 日誌從入門到實戰

之前分享了一篇《Java 異常處理從入門到實戰 》，當時有人提出如果能分享一篇日誌處理相關的文章就更好了。這篇 Chat 就是對之前參加異常處理 Chat 同學的一個迴應，希望能帶給大家一些收穫。日誌在專案中扮演著非常重要的角色，日誌記錄的詳細程度決定系統是否容易維護，Jav

java日誌框架簡介

java常用日誌框架類別 ​ slf4j和commons logging是java領域常用的日誌框架介面，這兩大框架分別對應一些列日誌具體實現框架， commons logging 是Apache 開源組織下的框架，陣營中主要包括： log4j：Apache軟體基金會的 一個ja

Java 日誌框架Log4j簡介、歷史

Log4j簡介 Log4j 是基於Java開發的日誌框架，其作者Ceki Gülcü將Log4j捐獻給了Apache軟體基金會，使之成為了Apache日誌服務的一個子專案。 Log4j雖然是Java