在任何系統(tǒng)中，日志都是非常重要的組成部分，它是反映系統(tǒng)運(yùn)行情況的重要依據(jù)，也是排查問(wèn)題時(shí)的必要線索。絕大多數(shù)人都認(rèn)可日志的重要性，但是又有多少人仔細(xì)想過(guò)該怎么打日志，日志對(duì)性能的影響究竟有多大呢？今天就讓我們來(lái)聊聊Java日志性能那些事。

DEBUG級(jí)別的日志在生產(chǎn)環(huán)境中不會(huì)輸出到文件中，也可能帶來(lái)不小的開(kāi)銷(xiāo)。我們撇開(kāi)判斷和方法調(diào)用的開(kāi)銷(xiāo)，在Log4J 2.x的性能文檔中 有這樣一組對(duì)比：logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); logger.debug("Entry number: {} is {}", i, entry[i]);

上面兩條語(yǔ)句在日志輸出上的效果是一樣的，但是在關(guān)閉DEBUG日志時(shí)，它們的開(kāi)銷(xiāo)就不一樣了，主要的影響在于字符串轉(zhuǎn)換和字符串拼接上，無(wú)論是否生效，前者都會(huì)將變量轉(zhuǎn)換為字符串并進(jìn)行拼接，而后者則只會(huì)在需要時(shí)執(zhí)行這些操作。Log4J官方的測(cè)試結(jié)論是兩者在性能上能相差兩個(gè)數(shù)量級(jí)。試想一下，如果某個(gè)對(duì)象的toString方法里用了ToStringBuilder來(lái)反射輸出幾十個(gè)屬性時(shí)，這時(shí)能省下多少資源。

因此，某些仍在使用Log4J 1.x或Apache Commons Logging（它們不支持{}模板的寫(xiě)法）的公司都會(huì)有相應(yīng)的編碼規(guī)范，要求在一定級(jí)別的日志（比如DEBUG和INFO）輸出前增加判斷：

if (logger.isDebugEnabled) { logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); }

除了日志級(jí)別和日志消息，通常在日志中還會(huì)包含一些其他信息，比如日期、線程名、類(lèi)信息、MDC變量等等，根據(jù)Takipi的測(cè)試，如果在日志中加入class，性能會(huì)急劇下降，比起LogBack的默認(rèn)配置，吞吐量的降幅在6成左右。如果一定要打印類(lèi)信息，可以考慮用類(lèi)名來(lái)命名Logger。

在分布式系統(tǒng)中，一個(gè)請(qǐng)求可能會(huì)經(jīng)過(guò)多個(gè)不同的子系統(tǒng)，這時(shí)***生成一個(gè)UUID附在請(qǐng)求中，每個(gè)子系統(tǒng)在打印日志時(shí)都將該UUID放在MDC里，便于后續(xù)查詢相關(guān)的日志?！禩he Ultimate Guide: 5 Methods For Debugging Production Servers At Scale》一文中就如何在生產(chǎn)環(huán)境中進(jìn)行調(diào)試給出了不少建議，當(dāng)中好幾條是關(guān)于日志的，這就是其中之一。另一條建議是記錄下所有未被捕獲的日志，其實(shí)拋出異常有開(kāi)銷(xiāo)，記錄異常同樣會(huì)帶來(lái)一定的開(kāi)銷(xiāo)，主要原因是Throwable類(lèi)的fillInStackTrace方法默認(rèn)是同步的：

public synchronized native Throwable fillInStackTrace;一般使用logger.error都會(huì)打出異常的堆棧，如果對(duì)吞吐量有一定要求，在情況運(yùn)行時(shí)可以考慮覆蓋該方法，去掉synchronized native，直接返回實(shí)例本身。聊完日志內(nèi)容，再來(lái)看看Appender。在Java中，說(shuō)起IO操作大家都會(huì)想起NIO，到了JDK 7還有了AIO，至少都知道讀寫(xiě)加個(gè)Buffer，日志也是如此，同步寫(xiě)的Appender在高并發(fā)大流量的系統(tǒng)里多少有些力不從心，這時(shí)就該使用在10線程并發(fā)下，輸出200字符的日志，的吞吐量***能是FileAppender的3.7倍。在不丟失日志的情況下，同樣使用AsyncAppender，隊(duì)列長(zhǎng)度對(duì)性能也會(huì)有一定影響。如果使用Log4J 2.x，那么除了有AsyncAppender，還可以考慮性能更高的異步Logger，由于底層用了Disruptor，沒(méi)有鎖的開(kāi)銷(xiāo)，性能更為驚人。根據(jù)Log4J 2.x的官方測(cè)試，同樣使用Log4J 2.x：64線程下，異步Logger比異步Appender快12倍，比同步Logger快68倍。

同樣是異步，不同的庫(kù)之間也會(huì)有差異：

同等硬件環(huán)境下，Log4J 2.x全部使用異步Logger會(huì)比LogBack的AsyncAppender快12倍，比Log4J 1.x的異步Appender快19倍 

Logger性能強(qiáng)悍，但也有不同的聲音，覺(jué)得這只是個(gè)看上去很優(yōu)雅，只能當(dāng)成一個(gè)玩具。關(guān)于這個(gè)問(wèn)題，還是留給讀者自己來(lái)思考吧。Appender，那么可以考慮使用STDOUT大部分生產(chǎn)系統(tǒng)都是集群部署，對(duì)于分布在不同服務(wù)器上的日志，用Logstash之類(lèi)的工具收集就好了。很多時(shí)候還會(huì)在單機(jī)上部署多實(shí)例以便充分利用服務(wù)器資源，這時(shí)千萬(wàn)不要貪圖日志監(jiān)控或者日志查詢方便，將多個(gè)實(shí)例的日志寫(xiě)到同一個(gè)日志文件中，雖然LogBack提供了prudent模式，能夠讓多個(gè)JVM往同一個(gè)文件里寫(xiě)日志，但此種方式對(duì)性能同樣也有影響，大約會(huì)使性能降低10%。如果對(duì)同一個(gè)日志文件有大量的寫(xiě)需求，可以考慮拆分日志到不同的文件，做法之一是添加多個(gè)Appender，同時(shí)修改代碼，不同的情況使用不同Logger；LogBack提供了SiftingAppender，可以直接根據(jù)MDC的內(nèi)容拆分日志，Jetty的教程中就有根據(jù)host來(lái)拆分日志的范例，而根據(jù)Takipi的測(cè)試，SiftingAppender的性能會(huì)隨著拆分文件數(shù)的增長(zhǎng)一同提升，當(dāng)拆分為4個(gè)文件時(shí)，10并發(fā)下SiftingAppenderFileAppender的3倍多?？戳松厦孢@么多的數(shù)據(jù)，不知您是否覺(jué)得自己的日志有不少改進(jìn)的余地，您還沒(méi)有把系統(tǒng)優(yōu)化到***，亦或者您還有其他日志優(yōu)化的方法，不妨分享給大家。