Java语言中流行的日志库Log4j的最新版本Log4j 2.6，将引入一系列选项以运行在免垃圾回收模式。该发布继续跟随前几个发布版，尝试提升日志库的性能，并且已经得到业界的积极响应。据性能改进倡议的引导者Remko Popm透露，下一步将会增加log4j可以运行在免垃圾回收模式的场景数量。
2014年7月，log4j 2.0在日志框架领域革命性地引入了异步记录器，相比于同步记录器将吞吐率提升了6至68倍。这些结果可能令人影响深刻，但日志框架的性能损耗仍然占据了部分高吞吐率、低延时应用响应时间的很大一部分，这常常导致开发者在部署时排除日志框架。对于高性能应用程序进行微调以避免垃圾回收导致的暂停能够达到非常好的效果，log4j团队断定这些性能提升能够带来更多的用户。通过来判断，该假设是成立的：
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