北京軟件開發公司log4j 2.6免垃圾收集，Java語言中流行的日志庫Log4j的較新版本Log4j 2.6，将引入一系列選項以運行在免垃圾回收模式。該發布繼續跟随前幾個發布版，嘗試提升日志庫的性能，並且已經得到業界的積極響應。據性能改進倡議的引導者Remko Popm透露，下一步将會增加log4j可以運行在免垃圾回收模式的場景數量。

　　2014年7月，log4j 2.0在日志框架領域革命性地引入瞭(le)異步記錄器，相比於(yú)同步記錄器将吞吐率提升瞭(le)6至68倍。這些結果可能令人影響深刻，但日志框架的性能損耗仍然占據瞭(le)部分高吞吐率、低延時應用響應時間的很大一部分，這常常導緻開發者在部署時排除日志框架。對於(yú)高性能應用程序進行微調以避免垃圾回收導緻的暫停能夠達到非常好的效果，log4j團隊斷定這些性能提升能夠帶來更多的用戶。通過性能和Java專家Kirk Pepperdine的評論來判斷，該假設是成立的：

　　Java中的日志框架形勢不容樂觀。到今天爲止，我很少碰到客戶反饋他們的系統沒有因爲日志框架導緻的負面影響。我與到的一個極端例子是，一個客戶面臨4.5秒的時限，但是日志記錄占用瞭(le)其中的4.2秒(很大一部分壓力來自於(yú)異步追加器)。我将對次版本發布非常感興趣。

　　防止垃圾回收是通過避免創(chuàng)建臨時對象來實現的，這意味著(zhe)需要盡可能的複用已經存在的對象。然而在較初發布的時候，整個庫沒有能夠做到免垃圾回收，因此開發者如果希望實現該功能，需要注意追加器(appenders)、日志記錄器(loggers)、格式化布局(formatting layouts)和API使用時的限制。

　　應用程序類型

　　部分被複用的對象保存在ThreadLocal區域中。這樣的設計對獨立的應用程序來說沒有問題，但是對於(yú)web應用可能會引起内存洩漏。應用服務器可能會将ThreadLocal保存在線程池中，這意味著(zhe)即使應用被卸載，用於(yú)日志記錄的對象仍然會保持引用。因此，通過ThreadLOcal來複用對象的功能在web應用程序中默認是關閉的，既log4j無法完全運行在免垃圾回收模式。

　　日志記錄器

　　log4j防止觸(chù)發垃圾回收的另一個方式是在将文本轉換爲字符數組的時候複用緩沖(chōng)區。所有類型的應用程序都可因此受益，且該功能默認是開啓的。然而使用同步日志記錄器的多線程應用程序可能會有性能影響，因爲不同的線程需要競争共享的緩沖(chōng)區。如果遇到這種情況，應該優先使用異步日志記錄器，或者禁用共享緩沖(chōng)區。

　　追加器

　　隻有部分追加器已經修改以避免創建臨時對象：Console(控制台)、File(文件)、RandomAccessFile(随機訪問文件)、上述追加器的回卷追加器、MemoryMappedFile(内存映射文件)。任何其他追加器都會産(chǎn)生垃圾，並(bìng)且需要被回收。然而需要注意的是，這些追加器本身可以免垃圾回收，仍然會有其他I/O相關的因素會影響它們的性能。

　　格式化布局

　　格式化布局可能是開發者在試圖配置達(dá)到免垃圾回收時較棘手的部分，因爲他們不僅需要關注所需使用的布局，還需要關注布局中的選項。GelfLayout(Graylog Extended Log Format)布局隻有在壓縮選項禁用時才支持免垃圾回收，而PatternLayout隻支持限定的轉換模式，任何其他轉換模式都會創(chuàng)建臨時對象。

　　API使用

　　API本身也已經爲避免創建臨時對象而修改。除瞭(le)之前支持簡單可變(biàn)長度參數(這樣會創建一個臨時數據)的方法之外，log4j新增瞭(le)所有方法的重載版本，較多支持10個參數。調用方法超過10個參數仍然會使用可變(biàn)長度參數，這将會創建臨時數組。

　　這個限制對於通過SLF4J使用log4j的場景影響較大，因爲這個門面庫隻提供瞭(le)較多兩個參數的非變長參數。用戶如果希望使用超過兩個參數，並(bìng)運行在免垃圾回收模式，就需要抛棄SLF4J。

　　對代碼的影響

　　雖然已經做瞭(le)向下兼容，以避免開發者更新代碼，有一類臨時對象的創建和log4j框架本身無關：對基本數據類型的自動裝箱。爲瞭(le)確(què)保JVM不将基本數據類型裝換成對應的對象，開發者在給log4j傳遞基本數據類型時，可以使用靜态方法Unboxer.box()。該方法可以允許log4j直接處理基本數據類型而無需創建不必要的對象。

　　盡管有一系列的限制條件，這些改變(biàn)已經有潛力在嚴格性能需求的場(chǎng)景下顯著提升日志記錄的體驗。那些因爲當前限制無法使用免垃圾回收特性的開發者，可以繼續關注變(biàn)更列表，在未來的發布版本中可能會提供進一步的改進。