1. 項(xiàng)目概述為什么LoggerFactory.getLogger是Java日志的基石干了這么多年Java開發(fā)我敢說只要你寫過Java代碼就絕對(duì)繞不開日志這一關(guān)。而說到Java日志LoggerFactory.getLogger這個(gè)方法就像是空氣和水無處不在卻又常常被我們習(xí)以為常以至于忽略了它背后那些至關(guān)重要的細(xì)節(jié)。你可能每天都在用它打日志但有沒有想過為什么是LoggerFactory為什么是getLogger傳進(jìn)去的Class對(duì)象和字符串到底有什么區(qū)別為什么別人的日志輸出格式清晰、定位精準(zhǔn)而你的日志卻像一團(tuán)亂麻出了問題連個(gè)鬼影子都找不到這不僅僅是一個(gè)簡單的API調(diào)用問題。它關(guān)系到你整個(gè)應(yīng)用的可觀測性。線上系統(tǒng)半夜報(bào)警你是想花三分鐘從日志里精準(zhǔn)定位到問題所在的類和方法然后安心回去睡覺還是想對(duì)著幾百M(fèi)B的日志文件用grep命令大海撈針熬到天亮答案顯而易見。LoggerFactory.getLogger就是你構(gòu)建清晰、有效日志體系的第一塊也是最關(guān)鍵的一塊基石。它決定了日志記錄器的上下文、繼承關(guān)系以及最終的輸出行為。無論是剛?cè)胄械男率诌€是有一定經(jīng)驗(yàn)的開發(fā)者深入理解這個(gè)方法都能讓你在編碼、調(diào)試和系統(tǒng)維護(hù)中事半功倍。它直接關(guān)聯(lián)到SLF4J、Logback、Log4j2這些主流日志框架的核心機(jī)制。接下來我就結(jié)合十多年的踩坑經(jīng)驗(yàn)把這個(gè)看似簡單的方法里里外外、掰開揉碎了講給你聽。2. 核心機(jī)制深度解析SLF4J的門面與綁定在直接跳到getLogger的使用之前我們必須先搞清楚它所在的舞臺(tái)——SLF4J。很多人混淆了SLF4J和Logback/Log4j2的關(guān)系這是理解后續(xù)所有內(nèi)容的前提。2.1 門面模式為什么需要SLF4J想象一下如果你的項(xiàng)目依賴了十個(gè)第三方庫其中五個(gè)用Log4j1.x打日志三個(gè)用java.util.logging兩個(gè)用Logback。那么你的應(yīng)用日志輸出就會(huì)變得五花八門格式不統(tǒng)一級(jí)別控制混亂最終都混在同一個(gè)文件里簡直是一場災(zāi)難。SLF4J就是為了解決這個(gè)“日志框架戰(zhàn)國時(shí)代”的問題而生的。SLF4J本身不負(fù)責(zé)具體的日志記錄它只是一個(gè)門面Facade提供了一套統(tǒng)一的API。你的業(yè)務(wù)代碼只依賴SLF4J的API比如org.slf4j.Logger和LoggerFactory。至于底層真正干活的是誰Logback還是Log4j2則由你引入的相應(yīng)綁定器Binding來決定。這就是著名的“面向接口編程”思想在日志領(lǐng)域的完美實(shí)踐。當(dāng)你調(diào)用LoggerFactory.getLogger時(shí)SLF4J門面會(huì)根據(jù)類路徑下的綁定器找到一個(gè)具體的日志實(shí)現(xiàn)框架例如Logback然后創(chuàng)建并返回該框架的Logger實(shí)例。這個(gè)過程中你的代碼完全不知道底層是誰在干活實(shí)現(xiàn)了完美的解耦。2.2 getLogger的底層運(yùn)作流程當(dāng)你寫下Logger logger LoggerFactory.getLogger(MainClass.class);這行代碼時(shí)背后發(fā)生了一系列精密的操作獲取調(diào)用者信息SLF4J會(huì)獲取調(diào)用getLogger方法的堆棧信息以確定傳入的類如果傳入的是Class對(duì)象。這一步對(duì)于后續(xù)確定Logger名稱至關(guān)重要。初始化綁定在JVM生命周期中LoggerFactory類首次被加載時(shí)會(huì)執(zhí)行靜態(tài)初始化塊。它會(huì)遍歷類路徑尋找org/slf4j/impl/StaticLoggerBinder.class這個(gè)文件。這個(gè)類就是具體的綁定器。創(chuàng)建ILoggerFactory找到StaticLoggerBinder后調(diào)用其getLoggerFactory()方法獲得一個(gè)真正的、底層日志框架的ILoggerFactory實(shí)例。對(duì)于Logback這個(gè)實(shí)例是ch.qos.logback.classic.LoggerContext對(duì)于Log4j2則是另一個(gè)適配器。獲取或創(chuàng)建Logger將傳入的參數(shù)類名或字符串轉(zhuǎn)化為一個(gè)Logger名稱Name然后向這個(gè)ILoggerFactory請(qǐng)求獲取一個(gè)Logger。底層工廠會(huì)檢查是否已存在同名Logger如果有則直接返回沒有則創(chuàng)建一個(gè)新的并管理其生命周期如級(jí)別、附加器Appender的繼承關(guān)系。注意這里有一個(gè)非常重要的性能優(yōu)化點(diǎn)。LoggerFactory.getLogger方法內(nèi)部是有緩存機(jī)制的。獲取到的Logger實(shí)例會(huì)被緩存起來下次以相同名稱請(qǐng)求時(shí)直接返回緩存實(shí)例。這意味著你可以在類的靜態(tài)變量中安全地持有這個(gè)Logger引用而不用擔(dān)心重復(fù)創(chuàng)建的性能開銷。這是一種標(biāo)準(zhǔn)的、被鼓勵(lì)的做法。2.3 名稱Name的繼承樹與級(jí)別繼承這是理解日志配置生效的關(guān)鍵。Logger不是孤立的它們通過名稱Name組織成一個(gè)樹形結(jié)構(gòu)類似于Java包的繼承關(guān)系。假設(shè)你有以下Loggercom.example對(duì)應(yīng)LoggerFactory.getLogger(“com.example”)com.example.service對(duì)應(yīng)LoggerFactory.getLogger(“com.example.service”)com.example.service.UserService對(duì)應(yīng)LoggerFactory.getLogger(UserService.class)在樹形結(jié)構(gòu)中com.example.service.UserService是com.example.service的子節(jié)點(diǎn)而com.example.service又是com.example的子節(jié)點(diǎn)。級(jí)別繼承規(guī)則如果一個(gè)Logger沒有顯式設(shè)置日志級(jí)別Level它會(huì)自動(dòng)繼承離它最近的、顯式設(shè)置了級(jí)別的祖先Logger的級(jí)別。如果所有祖先都未設(shè)置則繼承根LoggerROOT的級(jí)別。配置示例Logback.xml:configuration !-- 根Logger設(shè)置為INFO -- root levelINFO appender-ref refCONSOLE / /root !-- 為com.example包下的所有類設(shè)置DEBUG級(jí)別 -- logger namecom.example levelDEBUG / !-- 特別地將com.example.service.UserService的級(jí)別設(shè)為WARN覆蓋繼承的DEBUG -- logger namecom.example.service.UserService levelWARN / /configuration在這個(gè)配置下com.example.service.OrderService屬于com.example.service包的Logger沒有單獨(dú)配置因此繼承com.example的DEBUG級(jí)別。com.example.service.UserService的Logger由于單獨(dú)配置為WARN因此級(jí)別就是WARN不再繼承DEBUG。com.example.dao包下的Logger同樣繼承com.example的DEBUG級(jí)別。com.other包下的Logger與com.example無關(guān)因此直接繼承根Logger的INFO級(jí)別。理解這個(gè)繼承樹你就能通過精煉的配置靈活地控制應(yīng)用中不同模塊、不同類別的日志輸出粒度這是實(shí)現(xiàn)高效日志管理的基礎(chǔ)。3. 使用方法全解與實(shí)戰(zhàn)場景剖析知道了原理我們來看看具體怎么用。getLogger方法主要有兩種參數(shù)形式用途和影響有細(xì)微差別。3.1 兩種參數(shù)形式Class vs String1. 傳入Class對(duì)象最常用、最推薦public class UserService { // 標(biāo)準(zhǔn)做法使用當(dāng)前類的Class對(duì)象 private static final Logger logger LoggerFactory.getLogger(UserService.class); }優(yōu)點(diǎn)安全重構(gòu)如果你使用IDE如IntelliJ IDEA的重命名功能修改類名這個(gè)參數(shù)會(huì)自動(dòng)更新。如果傳入字符串則需要手動(dòng)修改極易遺漏導(dǎo)致日志上下文錯(cuò)誤。明確清晰一目了然地知道這個(gè)Logger是屬于哪個(gè)類的代碼可讀性極高。名稱準(zhǔn)確獲取的是完整的類名如com.example.service.UserService直接對(duì)應(yīng)Logger繼承樹中的節(jié)點(diǎn)。適用場景絕大多數(shù)情況為某個(gè)具體的業(yè)務(wù)類、工具類、控制器等聲明Logger時(shí)使用。2. 傳入字符串// 場景1為某個(gè)功能模塊統(tǒng)一命名 private static final Logger metricsLogger LoggerFactory.getLogger(METRICS); // 場景2使用某個(gè)固定的名稱 private static final Logger auditLogger LoggerFactory.getLogger(AUDIT); // 場景3動(dòng)態(tài)構(gòu)造名稱需謹(jǐn)慎 public Logger getLoggerForEntity(String entityType, String id) { return LoggerFactory.getLogger(ENTITY. entityType . id); }優(yōu)點(diǎn)靈活性高可以自由定義任何名稱不局限于類名。功能分類可以按功能如審計(jì)、監(jiān)控、性能指標(biāo)而非代碼結(jié)構(gòu)來組織日志。缺點(diǎn)與風(fēng)險(xiǎn)容易出錯(cuò)字符串拼寫錯(cuò)誤在編譯期無法發(fā)現(xiàn)運(yùn)行時(shí)日志會(huì)輸出到錯(cuò)誤的Logger名下導(dǎo)致配置失效或日志丟失。不利于重構(gòu)與代碼結(jié)構(gòu)脫鉤。適用場景跨類別的功能日志比如將所有與數(shù)據(jù)審計(jì)相關(guān)的日志輸出到名為AUDIT的Logger便于統(tǒng)一收集和處理。動(dòng)態(tài)上下文日志在非常復(fù)雜的業(yè)務(wù)中可能需要為每個(gè)業(yè)務(wù)流程實(shí)例或用戶會(huì)話創(chuàng)建獨(dú)立的日志上下文通常結(jié)合MDC使用此時(shí)可以使用動(dòng)態(tài)構(gòu)造的名稱。第三方庫或遺留代碼適配當(dāng)某些組件強(qiáng)制要求使用特定名稱的Logger時(shí)。實(shí)操心得我個(gè)人的原則是默認(rèn)永遠(yuǎn)使用Class.class參數(shù)。只有在明確需要將多個(gè)不同類的日志聚合到同一個(gè)功能類別下進(jìn)行輸出和管理時(shí)才考慮使用字符串參數(shù)。并且用于字符串參數(shù)的名稱應(yīng)該定義為全局常量避免在代碼中散落著魔法字符串。3.2 日志級(jí)別Level的正確使用獲取到Logger實(shí)例后我們通過不同級(jí)別的方法來記錄日志。級(jí)別決定了日志的重要性。SLF4J定義了5個(gè)核心級(jí)別從低到高依次是TRACEDEBUGINFOWARNERROR。各級(jí)別使用指南與實(shí)戰(zhàn)場景級(jí)別方法使用場景與示例輸出時(shí)機(jī)建議ERRORlogger.error(...)系統(tǒng)錯(cuò)誤需要立即關(guān)注并處理。例如數(shù)據(jù)庫連接失敗、外部API調(diào)用致命異常、導(dǎo)致核心業(yè)務(wù)流程中斷的異常。logger.error(“Failed to process order {}”, orderId, e);必須立即告警接入監(jiān)控平臺(tái)并需人工介入排查。WARNlogger.warn(...)潛在問題或異常情況但系統(tǒng)仍可降級(jí)運(yùn)行。例如緩存命中率過低、使用了即將廢棄的API、業(yè)務(wù)參數(shù)校驗(yàn)未通過非惡意請(qǐng)求。logger.warn(“Cache miss rate exceeds threshold: {}%”, rate);需要監(jiān)控和定期檢查可能預(yù)示著未來會(huì)發(fā)生ERROR。INFOlogger.info(...)重要的業(yè)務(wù)流程節(jié)點(diǎn)信息。例如系統(tǒng)啟動(dòng)/關(guān)閉、用戶登錄/登出、核心業(yè)務(wù)操作創(chuàng)建訂單、支付成功。logger.info(“User [{}] logged in from IP [{}]”, username, ip);用于跟蹤系統(tǒng)主要運(yùn)行狀態(tài)和業(yè)務(wù)流水是線上日志的主體。DEBUGlogger.debug(...)詳細(xì)的調(diào)試信息用于開發(fā)或線上問題深度排查。例如方法入?yún)⒊鰠?、?fù)雜的中間計(jì)算過程、條件分支的判斷結(jié)果。logger.debug(“Querying user with criteria: {}”, criteria);線上環(huán)境默認(rèn)關(guān)閉。僅在排查特定問題時(shí)動(dòng)態(tài)調(diào)整某個(gè)類或包的級(jí)別為DEBUG后開啟。TRACElogger.trace(...)最細(xì)粒度的信息比DEBUG更詳細(xì)。例如循環(huán)體內(nèi)每一步的狀態(tài)、高度頻繁調(diào)用的工具方法詳情。logger.trace(“Entering method calculate, thread: {}”, Thread.currentThread().getName());性能開銷最大通常只在本地開發(fā)環(huán)境開啟用于追蹤極其細(xì)微的程序流。一個(gè)關(guān)鍵的性能優(yōu)化點(diǎn)即使日志級(jí)別高于當(dāng)前配置例如在INFO級(jí)別下調(diào)用debug方法構(gòu)造日志參數(shù)本身也可能產(chǎn)生開銷。SLF4J通過參數(shù)化占位符{}和條件判斷來優(yōu)化。錯(cuò)誤示例有性能損耗// 即使INFO級(jí)別不輸出DEBUG日志字符串拼接”User: ” user ” requested: ” request也會(huì)執(zhí)行 logger.debug(“User: ” user ” requested: ” request);正確示例惰性求值// 使用占位符只有在DEBUG級(jí)別啟用時(shí)才會(huì)調(diào)用user.toString()和request.toString() logger.debug(“User: {} requested: {}”, user, request);更極致的優(yōu)化復(fù)雜參數(shù)構(gòu)造// 如果構(gòu)造參數(shù)cost很高可以先進(jìn)行級(jí)別判斷 if (logger.isDebugEnabled()) { logger.debug(“Expensive log message: {}”, expensiveOperation()); }3.3 參數(shù)化日志與異常記錄這是體現(xiàn)日志專業(yè)性的地方。好的日志信息應(yīng)該結(jié)構(gòu)化、易于搜索。1. 參數(shù)化日志Parameterized Logging始終使用{}占位符而不是字符串拼接。// 好 logger.info(“Order [{}] created for user [{}], amount: [{}]”, orderId, userId, amount); // 不好難以閱讀且性能差 logger.info(“Order ” orderId “ created for user ” userId “, amount: ” amount);參數(shù)化日志不僅性能好更重要的是當(dāng)日志被收集到ELK、Splunk等系統(tǒng)時(shí)可以通過解析模式輕松地提取出orderId、userId等字段進(jìn)行聚合分析和查詢。2. 異常記錄Exception Logging記錄異常時(shí)務(wù)必將異常對(duì)象作為最后一個(gè)參數(shù)傳入。try { // some code } catch (BusinessException e) { // 正確異常信息清晰包含堆棧 logger.error(“Failed to execute business process [{}]”, processId, e); // 錯(cuò)誤只記錄了消息沒有堆棧等于沒記 logger.error(“Failed to execute business process [{}], error: ” e.getMessage(), processId); // 更錯(cuò)誤吞掉了異常 logger.error(“Something went wrong with process {}”, processId); }將異常對(duì)象e作為參數(shù)傳入日志框架會(huì)自動(dòng)打印完整的異常堆棧軌跡StackTrace這是定位問題的生命線。4. 高級(jí)應(yīng)用與最佳實(shí)踐配置掌握了基礎(chǔ)用法我們來看看如何通過一些高級(jí)技巧和配置讓日志系統(tǒng)變得更強(qiáng)大、更高效。4.1 MDCMapped Diagnostic Context實(shí)現(xiàn)請(qǐng)求鏈路追蹤在Web應(yīng)用或分布式系統(tǒng)中一個(gè)請(qǐng)求會(huì)經(jīng)過多個(gè)線程、多個(gè)服務(wù)。如何將散落在各處的日志串聯(lián)起來MDC就是答案。MDC是一個(gè)線程本地的Map你可以在其中存放鍵值對(duì)然后日志輸出格式中可以引用這些鍵。典型應(yīng)用追蹤請(qǐng)求ID// 在請(qǐng)求入口處如Servlet Filter、Spring Interceptor import org.slf4j.MDC; public class LoggingFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { // 生成唯一請(qǐng)求ID String requestId UUID.randomUUID().toString(); // 放入MDC MDC.put(“REQUEST_ID”, requestId); try { chain.doFilter(request, response); } finally { // 務(wù)必在finally塊中清除防止內(nèi)存泄漏和上下文污染 MDC.clear(); } } }在業(yè)務(wù)代碼中你無需再傳遞requestIdLogger會(huì)自動(dòng)從MDC獲取。logger.info(“Processing user order”); // 這條日志會(huì)自動(dòng)帶上REQUEST_ID在Logback配置中配置輸出格式appender name“CONSOLE” class“ch.qos.logback.core.ConsoleAppender” encoder pattern%d{yyyy-MM-dd HH:mm:ss} [%thread] [%X{REQUEST_ID}] %-5level %logger{36} - %msg%n/pattern /encoder /appender%X{REQUEST_ID}就會(huì)從MDC中取出對(duì)應(yīng)的值輸出。這樣同一個(gè)請(qǐng)求的所有日志無論來自哪個(gè)類、哪個(gè)線程都擁有了相同的REQUEST_ID在日志分析系統(tǒng)中可以輕松過濾和追蹤。4.2 性能調(diào)優(yōu)與異步日志日志I/O操作尤其是寫文件是同步的可能會(huì)阻塞業(yè)務(wù)線程。在高并發(fā)場景下啟用異步日志是提升性能的關(guān)鍵手段。Logback異步配置示例configuration !-- 先定義一個(gè)同步的文件Appender -- appender name“FILE” class“ch.qos.logback.core.FileAppender” fileapp.log/file encoder pattern%msg%n/pattern /encoder /appender !-- 再定義一個(gè)異步Appender包裝上面的FILE Appender -- appender name“ASYNC_FILE” class“ch.qos.logback.classic.AsyncAppender” !-- 不丟失日志的配置如果隊(duì)列剩余容量小于這個(gè)值則會(huì)丟棄TRACE/DEBUG/INFO級(jí)別的日志只保留WARN/ERROR -- discardingThreshold0/discardingThreshold !-- 隊(duì)列容量生產(chǎn)環(huán)境建議調(diào)大 -- queueSize512/queueSize !-- 引用同步的Appender -- appender-ref ref“FILE” / /appender root level“INFO” appender-ref ref“ASYNC_FILE” / /root /configuration關(guān)鍵參數(shù)queueSize阻塞隊(duì)列的大小。隊(duì)列滿時(shí)AsyncAppender會(huì)阻塞調(diào)用線程直到有空位。根據(jù)應(yīng)用吞吐量調(diào)整通常256-1024。discardingThreshold當(dāng)隊(duì)列剩余容量小于此閾值時(shí)默認(rèn)會(huì)丟棄TRACE,DEBUG,INFO級(jí)別的日志以避免阻塞。設(shè)置為0則永不丟棄可能引起阻塞。includeCallerData默認(rèn)為false。設(shè)置為true會(huì)收集調(diào)用者信息類、方法、行號(hào)有性能損耗非必要不開啟。注意事項(xiàng)異步日志雖然提升了性能但存在日志丟失的風(fēng)險(xiǎn)。在JVM非正常關(guān)閉如kill -9時(shí)隊(duì)列中未處理的日志可能會(huì)丟失。對(duì)于要求絕對(duì)不丟失日志的場景如金融交易審計(jì)需要權(quán)衡或采用更可靠的方案如直接寫入Kafka。4.3 按大小和時(shí)間滾動(dòng)歸檔策略日志文件不能無限增長。Logback和Log4j2都提供了強(qiáng)大的滾動(dòng)策略。Logback按時(shí)間和大小滾動(dòng)的經(jīng)典配置appender name“ROLLING_FILE” class“ch.qos.logback.core.rolling.RollingFileAppender” filelogs/app.log/file encoder pattern%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder rollingPolicy class“ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy” !-- 歸檔文件命名模式按天和文件大小滾動(dòng) -- fileNamePatternlogs/archived/app-%d{yyyy-MM-dd}.%i.log.gz/fileNamePattern !-- 每個(gè)日志文件最大大小 -- maxFileSize100MB/maxFileSize !-- 保留30天的歷史日志 -- maxHistory30/maxHistory !-- 所有日志文件總大小上限 -- totalSizeCap10GB/totalSizeCap /rollingPolicy /appender這個(gè)配置意味著當(dāng)前日志寫到logs/app.log。當(dāng)文件大小達(dá)到100MB或到了第二天零點(diǎn)就會(huì)觸發(fā)滾動(dòng)。滾動(dòng)后的文件會(huì)被壓縮成.gz格式并按照app-2023-10-27.0.log.gz這樣的模式命名如果同一天有多個(gè).i會(huì)遞增。最多保留30天的日志文件且所有歸檔日志總大小不超過10GB超過則會(huì)刪除最老的。5. 常見問題排查與避坑指南在實(shí)際使用中你會(huì)遇到各種各樣奇怪的問題。這里我總結(jié)了一些最典型的“坑”和解決方法。5.1 日志不輸出或級(jí)別不對(duì)這是最常見的問題通常由依賴沖突或配置錯(cuò)誤引起。問題現(xiàn)象代碼調(diào)用了logger.debug()但控制臺(tái)或文件里看不到輸出。排查步驟檢查依賴首先確認(rèn)沒有引入多個(gè)日志框架的綁定。執(zhí)行mvn dependency:tree或查看項(xiàng)目的依賴圖確保只存在一個(gè)SLF4J綁定如logback-classic并且排除了其他日志框架的直接依賴如log4j-core,commons-logging。經(jīng)典的依賴沖突是同時(shí)引入了logback-classic和log4j-over-slf4j或者引入了多個(gè)綁定器。檢查配置文件位置和名稱Logback默認(rèn)在類路徑下查找logback.xml或logback-spring.xmlSpring Boot。確認(rèn)文件在src/main/resources目錄下且沒有被其他配置文件覆蓋。檢查Logger級(jí)別確認(rèn)你的Logger名稱在配置文件中是否被正確設(shè)置。使用logger name“com.example.YourClass” level“DEBUG”/來顯式設(shè)置。記住繼承規(guī)則檢查其父Logger的級(jí)別。啟用內(nèi)部狀態(tài)日志在logback.xml的configuration標(biāo)簽中添加statusListener class“ch.qos.logback.core.status.OnConsoleStatusListener” /。這會(huì)在啟動(dòng)時(shí)打印Logback內(nèi)部的詳細(xì)狀態(tài)信息包括加載的配置文件、發(fā)現(xiàn)的Logger和Appender非常有助于診斷。檢查Appender配置確認(rèn)Logger是否關(guān)聯(lián)了正確的Appender。root或logger標(biāo)簽內(nèi)需要有appender-ref ref“你的Appender名稱” /。5.2 性能問題日志成為瓶頸問題現(xiàn)象應(yīng)用在壓測下響應(yīng)變慢CPU或I/O等待高線程堆棧顯示阻塞在日志記錄相關(guān)方法。排查與優(yōu)化檢查日志級(jí)別線上環(huán)境務(wù)必確保DEBUG和TRACE級(jí)別關(guān)閉。一個(gè)在循環(huán)體內(nèi)被頻繁調(diào)用的DEBUG日志即使不輸出參數(shù)構(gòu)造如調(diào)用對(duì)象的toString()方法也可能產(chǎn)生巨大開銷。使用if (logger.isDebugEnabled())進(jìn)行防護(hù)。啟用異步日志如4.2節(jié)所述將文件、網(wǎng)絡(luò)等I/O密集型Appender改為異步。評(píng)估序列化開銷檢查日志消息中是否包含了需要復(fù)雜序列化的大對(duì)象如完整的DTO、集合。盡量避免或者只記錄其關(guān)鍵ID。檢查磁盤I/O日志文件是否寫在了慢速磁盤上多個(gè)應(yīng)用實(shí)例的日志是否寫到了同一個(gè)物理磁盤導(dǎo)致競爭考慮使用更快的SSD或者將日志先寫入內(nèi)存緩沖區(qū)/消息隊(duì)列。5.3 日志格式混亂或中文亂碼問題現(xiàn)象日志文件中的中文顯示為問號(hào)??或亂碼或者輸出的格式不符合pattern的定義。解決方案統(tǒng)一編碼確保你的日志配置文件、源代碼文件、操作系統(tǒng)終端/文件查看器的編碼一致推薦全部使用UTF-8。在Logback配置中指定編碼appender name“FILE” class“ch.qos.logback.core.FileAppender” fileapp.log/file encoder charsetUTF-8/charset !-- 關(guān)鍵 -- pattern%msg%n/pattern /encoder /appender檢查控制臺(tái)編碼如果是在IDE或服務(wù)器控制臺(tái)看到亂碼需要檢查運(yùn)行環(huán)境的JVM參數(shù)。可以添加-Dfile.encodingUTF-8確保JVM使用UTF-8編碼。5.4 內(nèi)存泄漏MDC未清理問題現(xiàn)象在使用了線程池如Tomcat的HTTP線程池、Async異步任務(wù)的應(yīng)用中隨著運(yùn)行時(shí)間增長內(nèi)存逐漸升高。根本原因MDC內(nèi)部使用ThreadLocal存儲(chǔ)數(shù)據(jù)。如果線程來自線程池在執(zhí)行完任務(wù)后線程不會(huì)被銷毀而是放回池中復(fù)用。如果不在任務(wù)結(jié)束時(shí)清理MDC那么之前任務(wù)設(shè)置的MDC內(nèi)容會(huì)殘留隨著線程的反復(fù)復(fù)用ThreadLocalMap中的條目可能積累導(dǎo)致內(nèi)存泄漏。嚴(yán)格遵循的編程范式// 在任何可能被線程池線程執(zhí)行的代碼塊中 MDC.put(“key”, “value”); try { // 業(yè)務(wù)邏輯 logger.info(“Processing...”); } finally { // 無論如何一定要在finally塊中清理 MDC.clear(); // 或者 MDC.remove(“key”); }對(duì)于Web應(yīng)用最佳實(shí)踐是在統(tǒng)一的過濾器或攔截器中處理MDC的放入和清理。5.5 日志框架橋接與沖突在大型老項(xiàng)目中經(jīng)常會(huì)遇到多種日志API并存的情況。場景項(xiàng)目依賴了一個(gè)老舊的庫它直接調(diào)用了org.apache.commons.logging.LogFactoryJCL或者org.apache.log4j.Logger。目標(biāo)將這些第三方庫的日志調(diào)用也路由到你的SLF4JLogback體系中。解決方案使用SLF4J提供的橋接包。橋接JCL (commons-logging)引入jcl-over-slf4j依賴并排除原有的commons-logging依賴。橋接Log4j 1.x引入log4j-over-slf4j依賴并排除原有的log4j:log4j依賴。橋接java.util.logging (JUL)引入jul-to-slf4j依賴并在應(yīng)用啟動(dòng)早期如Spring Boot的ApplicationRunner中執(zhí)行SLF4JBridgeHandler.install()。Maven依賴排除示例dependency groupIdorg.springframework/groupId artifactIdspring-core/artifactId exclusions exclusion groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /exclusion /exclusions /dependency dependency groupIdorg.slf4j/groupId artifactIdjcl-over-slf4j/artifactId /dependency重要警告橋接包和原API包絕對(duì)不能共存例如log4j-over-slf4j和log4j:log4j在同一個(gè)類路徑下會(huì)導(dǎo)致棧溢出錯(cuò)誤。務(wù)必通過依賴管理工具徹底排除原包。