背景

在Java系統(tǒng)實(shí)現(xiàn)過程中，我們不可避免地會借助大量開源功能組件。然而，這些組件往往功能豐富且體系龐大，官方文檔常常詳盡至數(shù)百頁。而在實(shí)際項目中，我們可能僅需使用其中的一小部分功能，這就造成了一個挑戰(zhàn)：如何在有限的時間和精力下，高效地掌握并使用這些組件的核心功能，以實(shí)現(xiàn)投入產(chǎn)出最大化？

針對這一問題，我基于二八原則，整理編寫本文。

首先，我會聚焦于組件的常見和核心功能，這些功能通常是我們在日常開發(fā)中頻繁使用到的，也是構(gòu)建穩(wěn)定、高效系統(tǒng)的基石。通過深入了解這些核心功能的使用方法和最佳實(shí)踐，我們可以確保在關(guān)鍵點(diǎn)上投入足夠的精力，從而避免在實(shí)際使用中掉入陷阱。

其次，我會以問題為導(dǎo)向，將實(shí)用性作為第一要素，對組件的功能進(jìn)行篩選和整理。這意味著我會優(yōu)先關(guān)注那些在項目中實(shí)際需要用到的功能，而對于那些特定場景下才會用到的功能，我會在文中提及但不做詳細(xì)展開。這樣做的好處是，我們可以在保證核心功能得到充分理解的同時，減少不必要的閱讀負(fù)擔(dān)，提高學(xué)習(xí)效率，降低投入成本。

最后，我會注重內(nèi)容的精煉和易讀性。通過簡明扼要的文字描述和直觀的示例代碼，幫助讀者快速理解并掌握組件的核心用法。

同時，我也會結(jié)合經(jīng)驗(yàn)指出常見的問題和注意事項，以便讀者在使用過程中能夠規(guī)避一些常見的錯誤和陷阱。

綜上所述，通過這個系列的內(nèi)容整理，我希望能夠幫助讀者在有限的時間和精力下，高效地掌握并使用這些開源功能組件的核心功能，滿足系統(tǒng)實(shí)現(xiàn)的需要。

注：部分內(nèi)容章節(jié)由AI輔助生成草稿，我對其進(jìn)行了復(fù)核和修訂，修復(fù)了有問題和有錯誤的部分。

理論

日志有什么用？

在Java開發(fā)中，日志記錄是一個不可或缺的部分。它能幫助我們了解程序的運(yùn)行狀態(tài)，追蹤和定位代碼中的錯誤。特別是在生產(chǎn)環(huán)境異常排查，日志是非常重要的手段，甚至某些情況下是唯一的途徑。

日志級別有哪些？

在Java開發(fā)中，日志級別是一個重要的概念。

常見的日志級別由低到高分別為TRACE、DEBUG、INFO、WARN、ERROR和FATAL。

每個級別都對應(yīng)著不同的日志輸出內(nèi)容和場景。

例如，TRACE級別通常用于記錄詳細(xì)的程序執(zhí)行流程，而ERROR級別則用于記錄程序運(yùn)行時的錯誤信息。

主流的日志組件有哪些？

日志功能具有通用性，與具體的業(yè)務(wù)系統(tǒng)無關(guān)，因此誕生了眾多的日志組件，我們不需要也不應(yīng)該去重復(fù)“造輪子”，而是拿來使用。

在選擇和集成日志組件時，我們需要考慮組件的性能、穩(wěn)定性以及兼容性等因素。當(dāng)前主流在使用的日志組件主要有兩個，一是logback，二是log4j2。這些組件都提供了豐富的功能和靈活的配置選項，可以根據(jù)項目的需求進(jìn)行選擇。

什么是日志門面？

雖然我們也可以直接使用上面說的logback或log4j2，但更好的方式是使用日志門面組件。

在Java中，SLF4J（Simple Logging Facade for Java）是一個為Java程序提供日志輸出的簡單門面或抽象層。它提供了一套統(tǒng)一的日志接口，使得開發(fā)者可以無需關(guān)心具體日志實(shí)現(xiàn)，并可以輕松切換日志組件。

注：這里雖然稱之為門面，但使用到的設(shè)計模式并不是門面模式，而是適配器模式。

SLF4J的主要特點(diǎn)和優(yōu)勢是什么？

SLF4J的主要特點(diǎn)和優(yōu)勢包括：

統(tǒng)一的日志接口：SLF4J為各種日志組件提供了統(tǒng)一的調(diào)用方式，從而簡化了日志記錄的過程。

靈活性：由于SLF4J是一個抽象層，它可以與多種日志實(shí)現(xiàn)組件（如Logback、Log4j2等）集成。這意味著即使更改底層日志實(shí)現(xiàn)，應(yīng)用程序代碼也不需要做出任何更改。

參數(shù)化日志：SLF4J提供了參數(shù)化日志功能，這有助于減少字符串拼接操作，從而提高了日志記錄的效率。

易于使用和學(xué)習(xí)：SLF4J的API設(shè)計得相對簡潔，降低了學(xué)習(xí)成本，并且無需復(fù)雜的配置。

SLF4J的應(yīng)用場景有哪些？

在項目中，SLF4J的應(yīng)用場景包括但不限于：

為開發(fā)者提供統(tǒng)一的日志接口，減少開發(fā)過程中的代碼侵入性。

結(jié)合不同的日志組件實(shí)現(xiàn)對日志進(jìn)行定制輸出。

替換不同的日志組件，使得日志輸出更易于管理和控制。

SLF4J是一個非常有用的工具，它可以幫助開發(fā)人員更好地管理和記錄應(yīng)用程序的日志。

實(shí)戰(zhàn)

如何引入SLF4J？

在Maven項目中，你可以在pom.xml文件中添加依賴：

<dependencies><dependency><groupId>org.slf4j</groupId><artifactId>slf4j-api</artifactId><version>1.7.30</version></dependency>
</dependencies>

實(shí)際上，因?yàn)镾LF4J應(yīng)用非常廣泛，大量的功能組件、中間件都使用并已經(jīng)引入了它，所以通常不再需要單獨(dú)引入，如下圖所示，druid、easyexcel、mybatisplus都使用到了slf4j。

如何引入logback？

前文說過，slf4j只是接口定義而不是實(shí)現(xiàn)，日志功能需要具體的日志組件logback或log4j2等來實(shí)現(xiàn)。

以logback為例，在slf4j已添加的情況下，引入如下包：

<dependencies><dependency><groupId>ch.qos.logback</groupId><artifactId>logback-classic</artifactId><version>1.2.3</version></dependency>
</dependencies>

注意，因?yàn)镾pringBoot 2.x版本默認(rèn)使用的日志組件就是logback，所以引入包的操作也省了。

如何記錄日志？

在引入slf4j和logback后，就可以按照以下方式來記錄日志了。

public class PlatformBootApplication {private static final Logger logger = LoggerFactory.getLogger(PlatformBootApplication.class);public static void main(String[] args) {logger.info("當(dāng)前時間: {}", System.currentTimeMillis());}
}

上面這種方式，需要在每個類中通過LoggerFactory構(gòu)造一個logger對象，并且需要將當(dāng)前類名傳入，一方面比較繁瑣；另一方面，從別的類中粘貼過來后容易忘記修改類名，結(jié)果就是日志輸出的來源出現(xiàn)張冠李戴。

更簡便的方法，是結(jié)合lombok注解使用，在類名上直接添加@slf4j注解，然后直接調(diào)用log.info即可。

@Slf4j
public class PlatformBootApplication {public static void main(String[] args) {log.info("當(dāng)前時間: {}", System.currentTimeMillis());}
}

運(yùn)行程序，控制臺輸出如下：

16:09:03.823 [main] INFO tech.abc.platform.boot.PlatformBootApplication - 當(dāng)前時間: 1718093343816

如何進(jìn)行配置？

前文我們通過logback在開發(fā)環(huán)境的控制臺輸出了info信息，使用的實(shí)際是logback的默認(rèn)配置。

在實(shí)際使用過程中，特別是生產(chǎn)環(huán)境，我們需要對日志輸出進(jìn)行定制化，包括日志輸出的格式、日志的級別、輸出到哪（文件、控制臺）……這就需要進(jìn)行配置了。

logback的默認(rèn)配置文件查找順序是在類路徑下依次查找logback.groovy、logback-test.xml、logback.xml文件。

在springboot項目的resources目錄下新建一個logback.xml文件，我們來進(jìn)一步做日志輸出的定制化。

如何配置輸出到控制臺？

使用IDE開發(fā)時，輸出到控制臺是最常用的功能，配置也是最簡單的，以此為例我們來說下配置。

先上一份配置：

<?xml version="1.0" encoding="UTF-8"?>
<configuration><!--控制臺日志輸出--><appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"><!--格式及編碼--><encoder><pattern>%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!-- 輸出 --><root level="INFO"><appender-ref ref="STDOUT"/></root>
</configuration>

日志功能組件中，負(fù)責(zé)輸出的稱之為appender，用來進(jìn)行定制化配置。

然后root節(jié)點(diǎn)來做全局管理，啟用哪些輸出，以及輸出的最低日志級別。

如何控制輸出日志的格式？

appender的encoder 部分的pattern屬性設(shè)置日志輸出的格式，包括時間戳、日志級別、線程名、logger名、日志消息等，需要按照規(guī)范來寫。

這些格式項具有特定的約定，用來控制輸出日志的樣式和內(nèi)容。

以下是一些常用的格式項及其意義：

%d{HH:mm:ss.SSS}：表示日期時間格式，其中HH小時、mm分鐘、ss秒、SSS毫秒。

%-5level：日志級別，如DEBUG、INFO、WARN、ERROR等，-5表示左對齊并至少占用5個字符寬度。

[%-5thread]：當(dāng)前線程名稱，同樣左對齊并至少占用5個字符寬度。

%logger{36} 或簡寫為 %logger：記錄器（Logger）的名稱，通常對應(yīng)類名，{36}指定了最大長度為36個字符，超出部分省略。

%msg：日志消息本身。

%n：換行符。

其他可能用到但上述示例未包含的格式項還包括：

%r：自應(yīng)用程序啟動到創(chuàng)建該日志事件所經(jīng)過的毫秒數(shù)。

%M：發(fā)出日志調(diào)用的方法名。

%F：發(fā)出日志調(diào)用的源文件名。

%L：發(fā)出日志調(diào)用的源文件中的行號。

%c 或 %C：完整的類名或僅類名（不包含包名）。

我們可以根據(jù)需要定制這些格式項來達(dá)到期望的日志輸出格式。

將其調(diào)整如下：

<pattern>%d{HH:mm:ss.SSS} %-5level %r [%-5thread] %logger %M %F %L %C - %msg%n
</pattern>          

控制臺輸入如下：

09:14:43.830 INFO  282 [main ] tech.abc.platform.boot.PlatformBootApplication main PlatformBootApplication.java 35 tech.abc.platform.boot.PlatformBootApplication - 當(dāng)前時間: 1718154883827

如何配置輸出到文件？

系統(tǒng)開發(fā)調(diào)試環(huán)節(jié)，我們更關(guān)注即時結(jié)果，通常只需要將日志輸出到控制臺就行了。

系統(tǒng)部署到服務(wù)器后，無論是測試環(huán)境還是生產(chǎn)環(huán)境，我們都希望日志持久化，以文件的方式輸出到磁盤，便于較長時間段的日志查看和分析。

我們增加一個appender，來將日志輸出到文件。

<?xml version="1.0" encoding="UTF-8"?>
<configuration><!--控制臺日志輸出--><appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"><!--格式及編碼--><encoder><pattern>%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!-- 輸出到文件 --><appender name="FILE" class="ch.qos.logback.core.FileAppender"><!-- 日志文件的路徑 --><file>c:\logs\myApplication.log</file><!-- 設(shè)置追加模式 --><append>true</append><!-- 定義日志格式 --><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder></appender><!-- 全局配置 --><root level="INFO"><!--輸出到控制臺--><appender-ref ref="STDOUT"/><!--輸出到文件--><appender-ref ref="FILE"/></root>
</configuration>

我們定義了一個名為FILE的appender，使用的類是FileAppender。

file節(jié)點(diǎn)指定輸出日志文件的路徑。

append屬性指定追加模式，為true是在末尾追加，為false則會清空原內(nèi)容，通常會設(shè)置為true。

encoder屬性配置與前面控制臺相同，與之不同的是我們把年月日給加上了。

啟動應(yīng)用，在磁盤上生成了日志文件，內(nèi)容如下：

如何配置只輸出指定級別的日志？

logback的默認(rèn)配置是輸出指定級別及以上的日志。

在上面的示例中，我們配置了日志級別時info，輸出的日志文件中，不僅僅是info，warn和error也會輸出。

在系統(tǒng)訪問量比較大的情況下，info日志會輸出大量內(nèi)容，系統(tǒng)運(yùn)維和異常排查時，我們往往只關(guān)注warn或error級別的日志，不希望info的大量內(nèi)容混在其中形成干擾，如何做呢？

一種便捷的方式就是調(diào)整全局配置，將root節(jié)點(diǎn)的level屬性調(diào)整為warn，此時所有的appender輸出的最低級別日志就是warn，不過error也會輸出，即warn和error日志還是輸出到同一個文件中。此外，該調(diào)整是對所有appender生效，一定程度上也會影響開發(fā)測試環(huán)境希望輸出info的設(shè)置。

如要實(shí)現(xiàn)精確的日志輸出，則需要為appender配置filter，如下所示：

<appender name="FILE" class="ch.qos.logback.core.FileAppender"><!-- 此日志文件只記錄warn級別的 --><filter class="ch.qos.logback.classic.filter.LevelFilter"><level>warn</level><onMatch>ACCEPT</onMatch><onMismatch>DENY</onMismatch></filter><!-- 日志文件的路徑 --><file>c:\logs\myApplication.log</file><!-- 設(shè)置追加模式 --><append>true</append><!-- 定義日志布局 --><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder>
</appender>

將level設(shè)置為warn，注意，只做這一步?jīng)]用，會顯示root定義的級別以上所有日志，還需要進(jìn)一步配置下面兩個屬性。

onMatch代表匹配時接受，只配這一個屬性，會顯示warn級別以上的所有日志。

onMismatch設(shè)置為不匹配時拒絕，最終結(jié)果就是只會記錄warn這一種類型的日志，不會有更高級別的error也混進(jìn)來。

這時候停下來想一想，如果我們想只輸出warn日志，是不是只配置onMismatch為DENY就可以了，并不需要配置onMatch為ACCEPT？

動手嘗試了下，果然是這樣。

總結(jié)下過濾器的用法：

只設(shè)置level沒有任何用處。

設(shè)置onMismatch為DENY，可以只輸出該級別的日志。

設(shè)置onMatch為ACCEPT，可以輸出該級別及其以上的日志。

日志需要保留多久？

這不是一個技術(shù)問題，而是一個管理問題。

客觀地說，日志具有一定時效性，幾乎沒有查看1個月以前的日志的需求，因此長時間保留意義不大。一般情況下，一周左右的日志就能滿足大多數(shù)場景下系統(tǒng)異常問題的排查需要了。某些特殊業(yè)務(wù)場景或監(jiān)管要求下，如重要的業(yè)務(wù)系統(tǒng)，需要保留操作痕跡用于審計，會要求保留一個月甚至3個月等長時間段的日志。

如何解決日志過大的問題？

通過上面的操作，我們把日志輸出到一個文件中，新日志記錄會追加到文件末尾。隨著時間的累積，會帶來兩個問題，一是日志文件越來越大，從最初的幾兆增加到數(shù)百兆甚至于好幾個G，此時查看日志打開速度會很慢，以致于普通的文本編輯器都沒法打開，搜索指定內(nèi)容也難以實(shí)現(xiàn)，更不用說分析了；二是因?yàn)槿罩镜呐蛎?#xff0c;可能會占用大量的磁盤空間，進(jìn)而導(dǎo)致磁盤空間耗盡引發(fā)應(yīng)用系統(tǒng)異常、卡頓甚至宕機(jī)。

解決思路也有多個，最簡單的就是人工定期清理，缺點(diǎn)就是帶來了額外的運(yùn)維工作量，且容易發(fā)生因疏忽導(dǎo)致的工作漏做。在這基礎(chǔ)上可以做成自動化，通過定時任務(wù)+腳本或開發(fā)來實(shí)現(xiàn)清理。

實(shí)際上，最佳的實(shí)踐是配置logback來實(shí)現(xiàn)滾動日志，新日志自動覆蓋舊日志。

如何配置日志滾動覆蓋？

我們再新增一個滾動日志的appender，如下：

<!-- 滾動日志 -->
<appender name="FILE_ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender"><filter class="ch.qos.logback.classic.filter.LevelFilter"><level>INFO</level></filter><rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"><!-- 按天滾動覆蓋 --><fileNamePattern>c:\logs\info\%d{yyyy-MM-dd}.%i.log</fileNamePattern><maxHistory>5</maxHistory><maxFileSize>1KB</maxFileSize></rollingPolicy><!-- 設(shè)置追加模式 --><append>true</append><!-- 定義日志布局 --><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder>
</appender>

與普通文件日志相比，實(shí)現(xiàn)類發(fā)生了變化，由FileAppender變更為RollingFileAppender。

然后增加了滾動策略的配置：

SizeAndTimeBasedRollingPolicy，用于控制日志文件的滾動和管理，基于文件大小和時間兩個維度來復(fù)合控制。

元素指定了日志文件的命名規(guī)則，%d{yyyy-MM-dd}.%i.log表示按日期進(jìn)行回滾，每天生成一個新文件，文件名格式為yyyy-MM-dd.log，其中%i表示按大小進(jìn)行滾動的索引編號。

元素指定了保留的歷史日志文件的最大天數(shù)，這里設(shè)置為5，意味著只會保留最近5天的日志文件，舊的日志文件將會被刪除。

元素指定了每個日志文件的最大體積，這里設(shè)置為1KB，當(dāng)單個日志文件的體積超過1KB時，將會生成新的日志文件進(jìn)行滾動。

上面的配置定義了一個基于大小和時間的滾動策略，用于按天回滾日志文件，并限制了歷史日志文件的保留天數(shù)和單個日志文件的大小。

注意：這里有個誤區(qū)，以為maxHistory是設(shè)定日志文件的數(shù)量，實(shí)際是日志天數(shù)。

上面為了測試效果，我設(shè)置了很小的值，輸出如下：

文件數(shù)量明顯超出了5個。

至于設(shè)置了1KB，實(shí)際2KB，這是操作系統(tǒng)的估算而已。

正常使用也不會設(shè)置單日志文件限制大小1KB，可忽略。

如何嚴(yán)格控制日志的磁盤占用？

從上面測試結(jié)果來看，實(shí)際仍有可能發(fā)生某一天因?yàn)橄到y(tǒng)異常產(chǎn)生了大量日志，導(dǎo)致磁盤耗盡的可能性，如何來解決呢？

實(shí)際logback提供了多種滾動策略，上面SizeAndTimeBasedRollingPolicy是基于大小和時間兩個維度復(fù)合控制，還有兩個類，分別實(shí)現(xiàn)基于大小和基于時間單個維度來控制。

基于時間的滾動策略 (TimeBasedRollingPolicy):

允許根據(jù)時間（如每小時、每天）滾動日志文件。

通過配置滾動后的文件名格式，例如%d{yyyy-MM-dd}.log表示每天生成一個新日志文件。

基于大小的滾動策略 (SizeBasedTriggeringPolicy):

當(dāng)日志文件達(dá)到指定大小時觸發(fā)滾動。

需要與其他滾動策略結(jié)合使用，比如與時間策略一起確保文件不會無限增長。

另有兩個策略，分別是固定窗口滾動策略 (FixedWindowRollingPolicy) 和 滾動計數(shù)器策略 (RollingFixedWindowTriggeringPolicy)。

這兩個策略常一起使用，基于固定窗口大小（如每10個文件一組）進(jìn)行滾動。

不直接指定文件大小或時間，而是通過窗口和計數(shù)器控制文件數(shù)量。

來個實(shí)例：

<appender name="FILE_ROLLING_FIXED_WINDOW" class="ch.qos.logback.core.rolling.RollingFileAppender"><!-- 定義日志文件路徑及基礎(chǔ)文件名 --><file>c:\logs\app\app.log</file><!-- 使用固定窗口滾動策略 --><rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"><!-- 指定窗口大小，比如每5個文件一組 --><minIndex>1</minIndex><maxIndex>5</maxIndex><!-- 文件命名模式，%i 代表窗口索引 --><fileNamePattern>c:\logs\app\app.%i.log</fileNamePattern></rollingPolicy><!-- 配合使用的滾動計數(shù)器策略，定義何時觸發(fā)滾動 --><triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"><!-- 每個日志文件最大大小 --><maxFileSize>1KB</maxFileSize></triggeringPolicy><!-- 日志內(nèi)容格式化 --><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder><!-- 設(shè)置追加模式 --><append>true</append></appender>

啟動應(yīng)用，運(yùn)行效果如下：

查看日志內(nèi)容，發(fā)現(xiàn)app.1.log里的時間要晚于app.5.log里的時間，說明已經(jīng)發(fā)生了日志覆蓋情況，符合預(yù)期。

注意，除了編號1-5的日志外，還有一個無編號的本尊。在這種配置模式下，去除 c:\logs\app\app.log配置通不過logback驗(yàn)證。

進(jìn)一步測試，發(fā)現(xiàn)情況有了變化，如下圖：

日志大小超出了我們設(shè)置的1KB，推測是因?yàn)槲覀內(nèi)罩敬笮≡O(shè)置的值過小，而logback出于性能考慮，往往會分批往磁盤里寫日志，每批次遠(yuǎn)大于1KB，這個值設(shè)置成5M或者更大，則不會存在問題。

通過固定窗口滾動策略+滾動計數(shù)器策略這兩個組合，我們就能嚴(yán)格限定日志單個大小上限以及日志總個數(shù)，比如設(shè)置單個日志文件不能超出10M，日志文件最大為20個，那么占用磁盤空間上限就是（20+1）*10=210M。

另外你可能也想到了這種方式的一個弊端，就是異常情況下如產(chǎn)生了大量日志，新日志會覆蓋舊日志，有可能造成你想查看問題發(fā)生初期甚至昨天的日志，因?yàn)楸桓采w而無法實(shí)現(xiàn)的問題。

還有一個小問題，就是我們?nèi)粘Ｍ粫鲃尤ゲ榭慈罩?#xff0c;而是收到了系統(tǒng)異常反饋后，才會根據(jù)日志排查，這時基本可以確定異常發(fā)生的時間范圍，而上述配置產(chǎn)生的日志通過文件名是無法確定相應(yīng)的日志在哪個文件里（文件修改時間可以提供一定的參考），往往需要打開多個日志文件才能定位。

如何使用變量？

配置過程中，有些值需要多次使用，例如上面例子中，日志文件路徑及基礎(chǔ)文件名，在滾動策略命名中也會用到，最好是將其定義成參數(shù)，一次定義，多次使用。如果需要修改，也只修改一個地方就好了，而不是到處找哪些地方用到，既麻煩，也容易遺漏。

logback是支持變量的，定義方式如下：

 <property name="MAX_SIZE" value="10MB"/>

使用方式如下：

 <maxFileSize>${MAX_SIZE}</maxFileSize>

如何避免寫日志操作影響業(yè)務(wù)處理？

默認(rèn)配置下，寫日志操作跟業(yè)務(wù)處理是在同一個進(jìn)程（或線程）中的，在系統(tǒng)負(fù)荷大，特別是高并發(fā)情況下，寫日志操作對系統(tǒng)性能還是有一定影響。

通常日志的重要性要遠(yuǎn)低于業(yè)務(wù)處理，所以我們可以采用異步方式。

logback自身支持異步，需要配置如下：

   <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"><!-- 設(shè)置異步日志隊列的大小為1000，即最多可以緩存1000個日志事件 --><queueSize>1000</queueSize><!-- 設(shè)置丟棄閾值為0，表示當(dāng)隊列滿時不會丟棄任何日志事件 --><discardingThreshold>0</discardingThreshold><!-- 設(shè)置為true，表示當(dāng)隊列滿時，寫入日志的操作不會被阻塞，而是直接返回 --><neverBlock>true</neverBlock><!-- 引用的appender將作為異步日志輸出的目標(biāo)，即實(shí)際輸出日志的地方 --><appender-ref ref="SOME_OTHER_APPENDER"/></appender>

實(shí)際上，就是定義一個異步的appender，然后使用appender-ref指向默認(rèn)或者說同步的appender就好了，類似于套接了一層，是不是很靈活？記得最后在全局配置root節(jié)點(diǎn)下，啟用的是這個異步appender，而不是原先的被套接的appender。

注意，異步日志的配置有坑點(diǎn)，下面來具體說一下。

queueSize是日志隊列長度，底層實(shí)現(xiàn)是BlockingQueue，默認(rèn)長度是256，設(shè)置過大有可能造成OOM。

discardingThreshold的默認(rèn)設(shè)置是queueSize的20%，隊列長1000，默認(rèn)就是200，這個參數(shù)什么意思呢？

就是當(dāng)隊列中剩余的容量不足200時，會丟棄掉info級別及以下的日志。設(shè)置為0則代表永不丟棄。

AsyncAppender的異步機(jī)制的出現(xiàn)本來就是優(yōu)化日志阻塞問題的，但是使用不當(dāng)反而容易出現(xiàn)阻塞問題。

neverBlock的默認(rèn)值是false，當(dāng)隊列滿了的時候**或剩余容量達(dá)到閾值discardingThreshold就會出現(xiàn)阻塞問題**。設(shè)置為true時，明面上代表永不堵塞業(yè)務(wù)處理，實(shí)際意味著丟棄日志。

這三個參數(shù)實(shí)際是相互作用的，在具體項目中，需要好好權(quán)衡下取舍，是性能優(yōu)先還是日志完整性優(yōu)先。

如果性能排在首位，能接受一定的日志丟失，則將neverBlock設(shè)置為true。

如果完全不能接受日志丟失，需要將discardingThreshold 設(shè)置為0。

兼顧性能和日志不丟，將discardingThreshold 設(shè)置為0，把queueSize值設(shè)置的大一點(diǎn)。

所以異步日志一定注意合理配置，并且如果系統(tǒng)的并發(fā)訪問量不大，也沒必要啟用異步日志。

典型配置什么樣？

經(jīng)過上述一步步從簡單到復(fù)雜的探索，我們了解了logback的常用配置。

考慮到日志通常不會占用大量磁盤，而且服務(wù)器通常會有監(jiān)控，磁盤不足時會進(jìn)行報警。

從運(yùn)維便利性角度考慮，我們采用的還是基于時間維度，限制單個文件大小的滾動覆蓋的日志策略。

最終我們綜合運(yùn)用，輸出一個典型配置如下：

<?xml version="1.0" encoding="UTF-8"?>
<configuration><!--設(shè)置系統(tǒng)日志目錄--><property name="LOG_PATH" value="c:/logs/"/><!--設(shè)置應(yīng)用日志目錄--><property name="APP_DIR" value="platform"/><!--日志保留天數(shù)--><property name="MAX_HISTORY" value="30"/><!--單個日志最大體積--><property name="MAX_SIZE" value="10MB"/><!-- 僅錯誤日志 --><appender name="FILE_ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender"><!-- 此日志文件只記錄error級別的 --><filter class="ch.qos.logback.classic.filter.LevelFilter"><level>error</level><onMismatch>DENY</onMismatch></filter><rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"><!--  按天滾動覆蓋 --><fileNamePattern>${LOG_PATH}/${APP_DIR}/error/%d{yyyy-MM-dd}.%i.log</fileNamePattern><maxHistory>${MAX_HISTORY}</maxHistory><maxFileSize>${MAX_SIZE}</maxFileSize></rollingPolicy><!-- 追加方式記錄日志 --><append>true</append><!-- 日志文件的格式 --><encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!-- 僅警告日志 --><appender name="FILE_WARN" class="ch.qos.logback.core.rolling.RollingFileAppender"><filter class="ch.qos.logback.classic.filter.LevelFilter"><level>warn</level><onMismatch>DENY</onMismatch></filter><rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"><!--  按天滾動覆蓋 --><fileNamePattern>${LOG_PATH}/${APP_DIR}/warn/%d{yyyy-MM-dd}.%i.log</fileNamePattern><maxHistory>${MAX_HISTORY}</maxHistory><maxFileSize>${MAX_SIZE}</maxFileSize></rollingPolicy><!-- 追加方式記錄日志 --><append>true</append><!-- 日志文件的格式 --><encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!-- 所有日志 --><appender name="FILE_INFO" class="ch.qos.logback.core.rolling.RollingFileAppender"><filter class="ch.qos.logback.classic.filter.LevelFilter"><level>info</level><onMatch>ACCEPT</onMatch></filter><rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"><!--  按天滾動覆蓋 --><fileNamePattern>${LOG_PATH}/${APP_DIR}/info/%d{yyyy-MM-dd}.%i.log</fileNamePattern><maxHistory>${MAX_HISTORY}</maxHistory><maxFileSize>${MAX_SIZE}</maxFileSize></rollingPolicy><!-- 追加方式記錄日志 --><append>true</append><!-- 日志文件的格式 --><encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!--控制臺日志輸出--><appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"><!--格式及編碼--><encoder><pattern>%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n</pattern><charset>utf-8</charset></encoder></appender><!-- 全局配置 --><root level="INFO"><!--僅錯誤日志--><appender-ref ref="FILE_ERROR"/><!--僅警告日志--><appender-ref ref="FILE_WARN"/><!--信息日志--><appender-ref ref="FILE_INFO"/><!--輸出到控制臺--><appender-ref ref="STDOUT"/></root>
</configuration>

上述配置將日志輸出到兩個地方，一個是控制臺，STDOUT，用于開發(fā)環(huán)境；另外一個是磁盤文件，并且按日志級別進(jìn)行了區(qū)分對待，單個日志文件不超過10M，按天滾動覆蓋，最多不超過30天。

在配置的日志文件路徑下，顯示如下：

注意，以上配置文件設(shè)置中，info、warn和error分別建立目錄，info代表是info及其級別以上的信息，即不僅包含info日志，warn和error日志也存在。warn和error日志使用了filter過濾器控制，分別只記錄嚴(yán)格匹配的警告和錯誤信息。按照上述配置，warn類型的日志會記錄兩遍，一遍在warn中，一遍在info中，error也是一樣的。

開發(fā)環(huán)境，建議全局配置中只保留控制臺日志輸出即可。

測試環(huán)境，建議完全按照上面配置，控制臺和磁盤文件都輸出，便于上生產(chǎn)前發(fā)現(xiàn)和排查問題。

生產(chǎn)環(huán)境，建議將全局日志級別的root level="INFO"調(diào)整為ERROR或者WARN，并注釋掉info輸出 以及控制臺輸出。

在系統(tǒng)異常的時候，僅靠warn和error日志難以排查時，在流量較小的情況下，短時間打開info日志，收集完日志數(shù)據(jù)后及時關(guān)閉。