Java語言中流行的日志庫Log4j的最新版本Log4j 2.6，將引入一系列選項以運行在免垃圾回收模式。該發布繼續跟隨前幾個發布版，嘗試提升日志庫的性能，並且已經得到業界的積極響應。據性能改進倡議的引導者Remko Popm透露，下一步將會增加log4j可以運行在免垃圾回收模式的場景數量。
2014年7月，log4j 2.0在日志框架領域革命性地引入了異步記錄器，相比於同步記錄器將吞吐率提升了6至68倍。這些結果可能令人影響深刻，但日志框架的性能損耗仍然占據了部分高吞吐率、低延時應用響應時間的很大一部分，這常常導致開發者在部署時排除日志框架。對於高性能應用程序進行微調以避免垃圾回收導致的暫停能夠達到非常好的效果，log4j團隊斷定這些性能提升能夠帶來更多的用戶。通過性能和Java專家Kirk Pepperdine的評論來判斷，該假設是成立的：
Java中的日志框架形勢不容樂觀。到今天為止，我很少碰到客戶反饋他們的系統沒有因為日志框架導致的負面影響。我與到的一個極端例子是，一個客戶面臨4.5秒的時限，但是日志記錄占用了其中的4.2秒（很大一部分壓力來自於異步追加器）。我將對次版本發布非常感興趣。
防止垃圾回收是通過避免創建臨時對象來實現的，這意味著需要盡可能的復用已經存在的對象。然而在最初發布的時候，整個庫沒有能夠做到免垃圾回收，因此開發者如果希望實現該功能，需要注意追加器（appenders）、日志記錄器（loggers）、格式化布局（formatting layouts）和API使用時的限制。
應用程序類型
部分被復用的對象保存在ThreadLocal區域中。這樣的設計對獨立的應用程序來說沒有問題，但是對於web應用可能會引起內存洩漏。應用服務器可能會將ThreadLocal保存在線程池中，這意味著即使應用被卸載，用於日志記錄的對象仍然會保持引用。因此，通過ThreadLOcal來復用對象的功能在web應用程序中默認是關閉的，既log4j無法完全運行在免垃圾回收模式。
日志記錄器
log4j防止觸發垃圾回收的另一個方式是在將文本轉換為字符數組的時候復用緩沖區。所有類型的應用程序都可因此受益，且該功能默認是開啟的。然而使用同步日志記錄器的多線程應用程序可能會有性能影響，因為不同的線程需要競爭共享的緩沖區。如果遇到這種情況，應該優先使用異步日志記錄器，或者禁用共享緩沖區。
追加器
只有部分追加器已經修改以避免創建臨時對象：Console（控制台）、File（文件）、RandomAccessFile（隨機訪問文件）、上述追加器的回卷追加器、MemoryMappedFile（內存映射文件）。任何其他追加器都會產生垃圾，並且需要被回收。然而需要注意的是，這些追加器本身可以免垃圾回收，仍然會有其他I/O相關的因素會影響它們的性能。
格式化布局
格式化布局可能是開發者在試圖配置達到免垃圾回收時最棘手的部分，因為他們不近需要關注所需使用的布局，還需要關注布局中的選項。GelfLayout（Graylog Extended Log Format）布局只有在壓縮選項禁用時才支持免垃圾回收，而PatternLayout只支持限定的轉換模式，任何其他轉換模式都會創建臨時對象。
API使用
API本身也已經為避免創建臨時對象而修改。除了之前支持簡單可變長度參數（這樣會創建一個臨時數據）的方法之外，log4j新增了所有方法的重載版本，最多支持10個參數。調用方法超過10個參數仍然會使用可變長度參數，這將會創建臨時數組。
這個限制對於通過SLF4J使用log4j的場景影響較大，因為這個門面庫只提供了最多兩個參數的非變長參數。用戶如果希望使用超過兩個參數，並運行在免垃圾回收模式，就需要拋棄SLF4J。
對代碼的影響
雖然已經做了向下兼容，以避免開發者更新代碼，有一類臨時對象的創建和log4j框架本身無關：對基本數據類型的自動裝箱。為了確保JVM不將基本數據類型裝換成對應的對象，開發者在給log4j傳遞基本數據類型時，可以使用靜態方法Unboxer.box()。該方法可以允許log4j直接處理基本數據類型而無需創建不必要的對象。
盡管有一系列的限制條件，這些改變已經有潛力在嚴格性能需求的場景下顯著提升日志記錄的體驗。那些因為當前限制無法使用免垃圾回收特性的開發者，可以繼續關注變更列表，在未來的發布版本中可能會提供進一步的改進。
查看英文原文：Log4j 2.6 Goes Garbage-Free