1.現(xiàn)有日志打印情況

??日志作為軟件工程實踐中的重要基礎(chǔ)設(shè)施，在系統(tǒng)監(jiān)控、異常診斷及行為追溯等關(guān)鍵環(huán)節(jié)發(fā)揮著不可替代的作用。Apache Log4j2作為當(dāng)前主流的日志框架，憑借其模塊化架構(gòu)和高度可擴展的特性，為開發(fā)者提供了靈活的多維度日志管理方案。然而若未能深入理解其異步日志機制、緩沖區(qū)策略等核心原理，或存在配置參數(shù)與業(yè)務(wù)場景匹配度不足等問題，則可能導(dǎo)致日志I/O阻塞、內(nèi)存資源過度消耗等負面效應(yīng)，甚至引發(fā)嚴重的服務(wù)性能瓶頸。因此，在實際工程實踐中需遵循科學(xué)合理的使用準則，通過日志分級管理、輸出格式優(yōu)化、滾動策略定制等手段，方能充分發(fā)揮其技術(shù)優(yōu)勢，有效規(guī)避潛在風(fēng)險。

1）日志阻塞

??日志導(dǎo)致線程Block的問題，相信你或許已經(jīng)遇到過，對此應(yīng)該深有體會；或許你還沒遇到過，但不代表沒有問題，只是可能還沒有觸發(fā)而已。常見的現(xiàn)象是出現(xiàn)大量的block線程，查看jstack常常是下圖現(xiàn)象：

2）從調(diào)試到生產(chǎn)，日志策略的抉擇

??在軟件項目的全生命周期中，從開發(fā)階段到生產(chǎn)環(huán)境的演進過程中，日志管理往往面臨著微妙的平衡。開發(fā)階段我們傾向于采用詳盡的日志策略：業(yè)務(wù)接口的入?yún)⒊鰠⒈煌暾涗?，跨系統(tǒng)的調(diào)用鏈路被清晰標注，甚至非核心邏輯的輔助性信息也得以留存——這些詳實的日志如同開發(fā)者的雙目，為聯(lián)調(diào)排障與功能驗證提供了不可或缺的洞察。

??然而當(dāng)服務(wù)邁向生產(chǎn)環(huán)境時，過度日志帶來的問題便逐漸顯現(xiàn)。冗余的調(diào)試信息不僅會影響系統(tǒng)性能，更可能淹沒真正關(guān)鍵的業(yè)務(wù)軌跡。盡管我們嘗試在上線前進行日志裁剪，但總存在令人躊躇的灰色地帶：某些開發(fā)期輔助日志是否暗含未來的診斷價值？那些看似非核心的流程記錄會否在某個異常場景下成為關(guān)鍵線索？這種取舍的困境，本質(zhì)上反映了我們對系統(tǒng)可觀測性與運行效能之間永續(xù)的權(quán)衡。

2.問題出現(xiàn)原因

2.1 日志打印原理分析

??在我們使用的log4j的應(yīng)用中采用的是異步日志配置，簡單的說明一下一條日志打印在log4j中的處理流程如下圖所示：

圖片

??簡單點來說，就是多線程通過 log4j2 的門面類進行日志的打印，日志經(jīng)過一系列的處理（過濾，包裝）后放入到Disruptor的環(huán)形 buffer 中，在服務(wù)器的消費端會單啟一個線程進行這些日志的消費，最終放入到我們指定的文件中。

2.2 log4j2 Disruptor 的初始化

??當(dāng)LoggerContext啟動時，所有AsyncLoggerConfig會通過start()方法初始化其Disruptor：

圖片

??其中Disruptor 是一個環(huán)形 buffer，官方做了很多的性能優(yōu)化，這里有興趣的可以了解其實現(xiàn)原理，這里不進行深入的討論，其中在我們的應(yīng)用log4j.xml配置中，沒對RingBuffer進行自定義的配置，使用的是默認的大小256K。

2.3 隊列滿導(dǎo)致日志阻塞

??Disruptor 的 RingBuffer 是一個固定大小的環(huán)形隊列，其發(fā)布邏輯：

圖片

??隊列滿時的默認行為：AsyncLoggerConfig.SynchronizeEnqueueWhenQueueFull=true，此時會等待著消費出下一個可以生產(chǎn)的環(huán)形 buffer 槽；此時所有打印日志的線程會嘗試獲取全局鎖。此時會阻塞線程，也就是我們上述堆棧中看到的異常。

2.4 產(chǎn)生的根本原因

??生產(chǎn)者速度 > 消費者速度：

??AsyncAppender 的后臺線程從隊列中取出事件并交給實際 Appender（如 FileAppender）處理，如果實際 Appender 的寫入速度慢（如磁盤 I/O 高），消費者線程無法及時清空隊列，導(dǎo)致隊列積壓。其實log4j消費時會調(diào)用多次 flush，這些flush的調(diào)用根本在文件寫入的 native 調(diào)用，當(dāng)這種native調(diào)用太多時，系統(tǒng)寫入不過來。

3 應(yīng)對方案

3.1 方案選擇

??上述問題情況解決，大致分成兩個方向：生產(chǎn)者方向&消費者方向，具體行為如下圖簡述：

圖片

??在應(yīng)對日志管理的挑戰(zhàn)時，除了調(diào)整日志隊列容量等基礎(chǔ)優(yōu)化（需警惕OOM風(fēng)險），更核心的問題在于如何平衡日志的詳實性與系統(tǒng)穩(wěn)定性。開發(fā)者往往陷入兩難：若詳盡記錄日志，可能引發(fā)阻塞風(fēng)險；若過度精簡，則排查問題時如盲人摸象，難溯根源。

為此，可考慮將日志劃分為兩類：

功能日志（必須）：如埋點數(shù)據(jù)、核心流程記錄，確保業(yè)務(wù)可觀測性；

業(yè)務(wù)排查日志（非必須）：如RPC入?yún)?出參、調(diào)試斷點等，按需動態(tài)啟停；

??通過這種分層策略，既能在高并發(fā)場景下保障核心日志的穩(wěn)定輸出，又能靈活控制輔助日志的打印量，使系統(tǒng)整體具備更強的適應(yīng)性與可控性。如此，我們既能從容應(yīng)對生產(chǎn)環(huán)境的嚴苛要求，又能在需要時快速激活詳盡的診斷信息，實現(xiàn)運維效率與系統(tǒng)性能的兼得。

3.2 技術(shù)選擇

??在日志打印的精細化控制中，核心在于靈活性與精準度的平衡。傳統(tǒng)的全局級別過濾（如INFO/WARN/ERROR）雖能粗放管理，卻難以適配復(fù)雜多變的業(yè)務(wù)場景。理想的方案應(yīng)突破層級限制，實現(xiàn)行級細粒度控制——無論是核心鏈路的關(guān)鍵節(jié)點，還是特定業(yè)務(wù)場景的臨時調(diào)試，均可針對單行日志動態(tài)啟停。

??這種設(shè)計賦予開發(fā)者更高的自主權(quán)：業(yè)務(wù)視角：按需捕獲特定模塊的完整上下文；鏈路視角：精準聚焦某次調(diào)用的全生命周期軌跡；應(yīng)急場景：即時激活深層診斷日志，無需重啟或改碼。

??通過將控制粒度細化至代碼行，我們既能維持生產(chǎn)環(huán)境的日志精簡，又能隨時按業(yè)務(wù)訴求“點亮”關(guān)鍵路徑，使系統(tǒng)可觀測性兼具嚴謹與彈性。

3.2.1 區(qū)分必要日志和非必要日志打?。?/span>

?自定義封裝日志打印的方式如下圖所示：

圖片

3.2.2 如何對非必要日志進行行級別控制

?1）自定義Appender中的filter：

??在實現(xiàn)行級日志控制時，若需精確控制特定代碼行（如第133行）的日志輸出，采用自定義Appender過濾機制是一種可行方案。其核心思路在于：通過解析日志調(diào)用的堆棧信息，動態(tài)判斷當(dāng)前行號是否符合預(yù)設(shè)的打印條件，若不符合則直接過濾。

??然而，該方案存在若干固有局限： 堆棧解析的可靠性問題：Lambda表達式中的日志調(diào)用往往難以準確獲取行號信息，即使通過堆棧緩存優(yōu)化，仍存在定位失準的風(fēng)險；性能損耗隱患：頻繁的堆棧遍歷操作會引入不可忽視的性能開銷，在高并發(fā)場景下可能成為新的瓶頸；分類管理缺失：該機制難以與既有的日志分級體系（必需/非必需日志）形成有機協(xié)同，增加了運維復(fù)雜度。

?2）在打印日志前獲取日志的行信息：

??最簡單的方式是人工的形式，在寫日志的時候同時將日志的行信息寫入進去，比如：這種方式在可擴展性和可觀測性維度存在設(shè)計缺陷。

?3）在編譯的時候獲取日志的行信息：

??我們想使用LogUtils.debug(()->log.info("業(yè)務(wù)日志"));這種方式，但是我們不會在代碼中明顯的寫入，可以在代碼編譯期間將行信息獲取到后使用字節(jié)碼修改這行代碼，利用Java的重寫。將它轉(zhuǎn)變成 LogUtils.debug("類+行",()->log.info("業(yè)務(wù)日志")); 然后再這個方法執(zhí)行中進行條件判斷。

字節(jié)碼技術(shù)選擇：

圖片

??在本次實現(xiàn)中需要更靈活的方式操作字節(jié)碼，還要考慮性能的問題，以及對應(yīng)用框架的支持， 我們選擇ASM的形式。

4）如何隨心控制開啟和關(guān)閉：

??這里我們采用的是ider插件的方式，有idea插件上報我們的對這行日志的控制行為，如下圖所示：

圖片

3.3 落地實現(xiàn)

3.3.1 Maven編譯插件

??目的：獲取日志所在的類和行信息。

??運行時獲取的方式：在 Logger 配置中啟用 includeLocation，代碼從 LogEvent通過堆棧分析獲取行號。這種方式存在很大的弊端，堆棧跟蹤生成開銷很大，每次調(diào)用 getStackTrace() 時，JVM 需要遍歷當(dāng)前線程的調(diào)用棧，生成完整的堆棧信息，這是一個 同步且耗時 的操作（尤其在深調(diào)用鏈中），如果每秒有數(shù)萬次日志調(diào)用，頻繁生成堆棧跟蹤可能導(dǎo)致 CPU 使用率飆升，直接影響吞吐量。

?? Maven的process-classes階段獲?。和ㄟ^Maven編譯之后獲取到字節(jié)碼文件時，對字節(jié)碼文件進行修改，存放日志的類和行信息。對運行期間無額外消耗。處理邏輯如下圖所示：

圖片

3.3.2 Idea插件

??目的：精準的控制某一行日志是否進行打印。

??利用Idea的插件能力，將我們對某一行日志的開啟和關(guān)閉狀態(tài)進行上報，整個過程不阻塞主線程，保持Idea操作流暢性。提供定時能力，保障線上我們可以更靈活的控制日志是否打印的狀態(tài)。處理邏輯如下圖所示；

圖片

3.3.3 整體流程

??使用方式：通過在項目中使用上述Maven插件對項目進行編譯部署，使用Idea插件對目標日志的是否開啟打印狀態(tài)進行上報，存儲狀態(tài)采用的Apollo的能力，通過自定義打印工具類中對Apollo配置內(nèi)容的分析，進一步做判斷邏輯，最終將日志進行打印或者不打印。處理邏輯如下圖所示：

圖片

4.總結(jié)

??在分布式系統(tǒng)日益復(fù)雜的今天，日志管理已從簡單的信息記錄演進為系統(tǒng)可觀測性的核心支柱。本文揭示的日志阻塞與策略困境，折射出現(xiàn)代化服務(wù)在穩(wěn)定性與可維護性之間的深層博弈。通過剖析Log4j2異步日志機制的內(nèi)在原理，我們識別出隊列積壓導(dǎo)致線程阻塞的關(guān)鍵癥結(jié)，并由此展開對日志治理體系的深度重構(gòu)。

??本次優(yōu)化方案突破傳統(tǒng)日志分級思維的桎梏，創(chuàng)新性地提出雙軌制日志管理體系：將日志劃分為功能型與診斷型兩類，前者確保核心業(yè)務(wù)脈絡(luò)的持續(xù)可見，后者實現(xiàn)按需動態(tài)管控。通過編譯期字節(jié)碼增強技術(shù)，我們實現(xiàn)代碼行級別的精準控制，配合IDE插件的可視化操作，使開發(fā)人員能夠像調(diào)試斷點般自由啟停日志輸出。這種"外科手術(shù)式"的日志管理，既避免了傳統(tǒng)方案"一刀切"的弊端，又賦予系統(tǒng)在高負載場景下的彈性適應(yīng)能力。

關(guān)于作者：蔡夢輝 平臺技術(shù)部后端