在任何系統(tǒng)中症虑，日志都是非常重要的組成部分缩歪，它是反映系統(tǒng)運行情況的重要依據(jù)，也是排查問題時的必要線索谍憔。絕大多數(shù)人都認(rèn)可日志的重要性匪蝙，但是又有多少人仔細(xì)想過該怎么打日志，日志對性能的影響究竟有多大呢习贫？今天就讓我們來聊聊Java日志性能那些事逛球。
說到Java日志，大家肯定都會說要選擇合理的日志級別苫昌、合理控制日志內(nèi)容颤绕，但是這僅是萬里長征第一步……哪怕一些DEBUG級別的日志在生產(chǎn)環(huán)境中不會輸出到文件中，也可能帶來不小的開銷祟身。我們撇開判斷和方法調(diào)用的開銷奥务，在Log4J 2.x的性能文檔中有這樣一組對比：
logger.debug("Entry number: " + i + " is " +? String.valueOf(entry[i]));
logger.debug("Entry number: {} is {}", i, entry[i]);
上面兩條語句在日志輸出上的效果是一樣的，但是在關(guān)閉DEBUG日志時袜硫，它們的開銷就不一樣了氯葬，主要的影響在于字符串轉(zhuǎn)換和字符串拼接上，無論是否生效婉陷，前者都會將變量轉(zhuǎn)換為字符串并進行拼接帚称，而后者則只會在需要時執(zhí)行這些操作。Log4J官方的測試結(jié)論是兩者在性能上能相差兩個數(shù)量級秽澳。試想一下闯睹，如果某個對象的toString()方法里用了ToStringBuilder來反射輸出幾十個屬性時，這時能省下多少資源担神。
因此瞻坝，某些仍在使用Log4J 1.x或Apache Commons Logging（它們不支持{}模板的寫法）的公司都會有相應(yīng)的編碼規(guī)范，要求在一定級別的日志（比如DEBUG和INFO）輸出前增加判斷：
if (logger.isDebugEnabled()) {
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}
除了日志級別和日志消息杏瞻，通常在日志中還會包含一些其他信息，比如日期衙荐、線程名捞挥、類信息、MDC變量等等忧吟，根據(jù)Takipi的測試砌函，如果在日志中加入class，性能會急劇下降，比起LogBack的默認(rèn)配置讹俊，吞吐量的降幅在6成左右垦沉。如果一定要打印類信息，可以考慮用類名來命名Logger仍劈。
在分布式系統(tǒng)中厕倍，一個請求可能會經(jīng)過多個不同的子系統(tǒng)，這時最好生成一個UUID附在請求中贩疙，每個子系統(tǒng)在打印日志時都將該UUID放在MDC里讹弯，便于后續(xù)查詢相關(guān)的日志≌饨Γ《The Ultimate Guide: 5 Methods For Debugging Production Servers At Scale》一文中就如何在生產(chǎn)環(huán)境中進行調(diào)試給出了不少建議组民，當(dāng)中好幾條是關(guān)于日志的，這就是其中之一悲靴。另一條建議是記錄下所有未被捕獲的日志臭胜，其實拋出異常有開銷，記錄異常同樣會帶來一定的開銷癞尚，主要原因是Throwable類的fillInStackTrace方法默認(rèn)是同步的：
public synchronized native Throwable fillInStackTrace();
一般使用logger.error都會打出異常的堆棧耸三，如果對吞吐量有一定要求，在情況運行時可以考慮覆蓋該方法否纬，去掉synchronized native吕晌，直接返回實例本身。
聊完日志內(nèi)容临燃，再來看看Appender睛驳。在Java中，說起IO操作大家都會想起NIO膜廊，到了JDK 7還有了AIO乏沸，至少都知道讀寫加個Buffer，日志也是如此爪瓜，同步寫的Appender在高并發(fā)大流量的系統(tǒng)里多少有些力不從心蹬跃，這時就該使用AsyncAppender了，同樣是使用LogBack：
在10線程并發(fā)下铆铆，輸出200字符的INFO日志蝶缀，AsyncAppender的吞吐量最高能是FileAppender的3.7倍。在不丟失日志的情況下薄货，同樣使用AsyncAppender翁都，隊列長度對性能也會有一定影響。
如果使用Log4J 2.x谅猾，那么除了有AsyncAppender柄慰，還可以考慮性能更高的異步Logger鳍悠，由于底層用了Disruptor，沒有鎖的開銷坐搔，性能更為驚人藏研。根據(jù)Log4J 2.x的官方測試，同樣使用Log4J 2.x：
64線程下概行，異步Logger比異步Appender快12倍蠢挡，比同步Logger快68倍。
同樣是異步占锯，不同的庫之間也會有差異：
同等硬件環(huán)境下袒哥，Log4J 2.x全部使用異步Logger會比LogBack的AsyncAppender快12倍，比Log4J 1.x的異步Appender快19倍消略。
Log4J 2.x的異步Logger性能強悍堡称，但也有不同的聲音，覺得這只是個看上去很優(yōu)雅艺演，只能當(dāng)成一個玩具却紧。關(guān)于這個問題，還是留給讀者自己來思考吧胎撤。
如果一定要用同步的Appender晓殊，那么可以考慮使用ConsoleAppender，然后將STDOUT重定向到文件里伤提，這樣大約也能有10%左右的性能提升巫俺。
大部分生產(chǎn)系統(tǒng)都是集群部署，對于分布在不同服務(wù)器上的日志肿男，用Logstash之類的工具收集就好了介汹。很多時候還會在單機上部署多實例以便充分利用服務(wù)器資源，這時千萬不要貪圖日志監(jiān)控或者日志查詢方便舶沛，將多個實例的日志寫到同一個日志文件中嘹承，雖然LogBack提供了prudent模式，能夠讓多個JVM往同一個文件里寫日志如庭，但此種方式對性能同樣也有影響叹卷，大約會使性能降低10%。
如果對同一個日志文件有大量的寫需求坪它，可以考慮拆分日志到不同的文件骤竹，做法之一是添加多個Appender，同時修改代碼往毡，不同的情況使用不同Logger瘤载；LogBack提供了SiftingAppender，可以直接根據(jù)MDC的內(nèi)容拆分日志卖擅，Jetty的教程中就有根據(jù)host來拆分日志的范例，而根據(jù)Takipi的測試，SiftingAppender的性能會隨著拆分文件數(shù)的增長一同提升惩阶，當(dāng)拆分為4個文件時挎狸，10并發(fā)下SiftingAppender的吞吐量約是FileAppender的3倍多。
看了上面這么多的數(shù)據(jù)断楷，不知您是否覺得自己的日志有不少改進的余地锨匆，您還沒有把系統(tǒng)優(yōu)化到極致，亦或者您還有其他日志優(yōu)化的方法冬筒，不妨分享給大家恐锣。
