禁用无垃圾日志记录

有两个独立的系统属性用于手动控制 Log4j 用于避免创建临时对象的机制

• log4j2.enableThreadlocals - 如果为“true”（非 Web 应用程序的默认值），则对象将存储在 ThreadLocal 字段中并重复使用，否则将为每个日志事件创建新对象。
• log4j2.enableDirectEncoders - 如果为“true”（默认值），则日志事件将被转换为文本，并且此文本将被转换为字节，而无需创建临时对象。注意：同步日志记录性能在这种模式下对于多线程应用程序来说可能会更差，因为要对共享缓冲区进行同步。如果您的应用程序是多线程的并且日志记录性能很重要，请考虑使用异步记录器。
• ThreadContext 映射默认情况下不是无垃圾的，但从 Log4j 2.7 开始，可以通过将系统属性 log4j2.garbagefreeThreadContextMap 设置为“true”来配置为无垃圾的。

除了系统属性之外，还可以通过在名为 log4j2.component.properties 的文件中指定上述属性，方法是在应用程序的类路径中包含此文件。有关系统属性的更多信息，请参阅 有关系统属性的手册。

支持的附加器

以下 附加器 在稳态日志记录期间是无垃圾的

• 控制台
• 文件
• 滚动文件（在文件滚动期间会创建一些临时对象）
• RandomAccessFile
• 滚动 RandomAccessFile（在文件滚动期间会创建一些临时对象）
• 内存映射文件

上面列表中未列出的任何其他附加器（包括 AsyncAppender）在稳态日志记录期间都会创建临时对象。请使用 异步记录器 而不是 AsyncAppender 以无垃圾的方式异步记录日志。

支持的过滤器

以下 过滤器 在稳态日志记录期间是无垃圾的

• 复合过滤器（添加和删除元素过滤器会为线程安全创建临时对象）
• 动态阈值过滤器
• 级别范围过滤器（从 2.8 版本开始无垃圾）
• 映射过滤器（从 2.8 版本开始无垃圾）
• 标记过滤器（从 2.8 版本开始无垃圾）
• 结构化数据过滤器（从 2.8 版本开始无垃圾）
• ThreadContextMap 过滤器（从 2.8 版本开始无垃圾）
• 阈值过滤器（从 2.8 版本开始无垃圾）
• 时间过滤器（从 2.8 版本开始无垃圾，但当需要每天重新计算范围时除外）

其他过滤器，如 BurstFilter、RegexFilter 和 ScriptFilter，并非易于实现无垃圾，目前没有计划更改它们。

支持的布局

API 更改

已向 Logger 接口添加方法，以便在使用最多十个参数记录消息时不创建任何 vararg 数组对象。

此外，已向 Logger 接口添加方法以记录 java.lang.CharSequence 消息。实现 CharSequence 接口的用户定义对象可以在不创建临时对象的情况下进行记录：Log4j 将尝试通过将它们追加到 StringBuilder 作为 CharSequence 来将 CharSequence 消息、Object 消息和消息参数转换为文本。这避免了对这些对象调用 toString()。

另一种方法是实现 org.apache.logging.log4j.util.StringBuilderFormattable 接口。如果记录的对象实现了此接口，则会调用其 formatTo 方法而不是 toString()。

当无垃圾日志记录被禁用时（当系统属性 log4j2.enableThreadlocals 设置为“false”时），Log4j 可能会对消息和参数对象调用 toString()。

对应用程序代码的影响：自动装箱

我们努力使日志记录在不需修改现有应用程序中的代码的情况下实现无垃圾，但有一个方面无法做到。在记录原始值（即 int、double、boolean 等）时，JVM 会将这些原始值自动装箱到其 Object 包装器等效项，从而产生垃圾。

Log4j 提供了一个 Unbox 实用程序来防止对原始参数进行自动装箱。此实用程序包含一个线程局部池，其中包含可重复使用的 StringBuilder。Unbox.box(primitive) 方法直接写入 StringBuilder，生成的文本将被复制到最终的日志消息文本中，而不会创建临时对象。

import static org.apache.logging.log4j.util.Unbox.box;

...
public void garbageFree() {
    logger.debug("Prevent primitive autoboxing {} {}", box(10L), box(2.6d));
}

响应时间延迟

响应时间是在特定负载下记录消息所需的时间。通常报告为延迟的实际上是服务时间：执行操作所需的时间。这掩盖了这样一个事实，即服务时间的单次峰值会为许多后续操作增加排队延迟。服务时间很容易测量（并且在纸面上通常看起来很好），但对于用户来说无关紧要，因为它省略了等待服务的时间。出于这个原因，我们报告响应时间：服务时间加上等待时间。有关更多详细信息，请参阅性能页面的 响应时间部分。

以下响应时间测试结果均来自运行 ResponseTimeTest 类，该类可以在 Log4j 2 单元测试源目录中找到。如果你想自己运行这些测试，以下是我们使用的命令行选项

• -Xms1G -Xmx1G（防止在测试期间堆调整大小）
• -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -DAsyncLogger.WaitStrategy=busyspin（使用异步记录器。BusySpin 等待策略减少了一些抖动。）
• 经典模式： -Dlog4j2.enable.threadlocals=false -Dlog4j2.enable.direct.encoders=false
  无垃圾模式： -Dlog4j2.enable.threadlocals=true -Dlog4j2.enable.direct.encoders=true
• -XX:CompileCommand=dontinline,org.apache.logging.log4j.core.async.perftest.NoOpIdleStrategy::idle
• -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime（查看 GC 和安全点暂停）

异步记录器

下图比较了 Log4j 的异步记录器的“经典”日志记录和无垃圾日志记录响应时间行为。在图中，“100k”表示以每秒 100,000 条消息的持续负载进行日志记录，“800k”表示以每秒 800,000 条消息的持续负载进行日志记录。

在经典模式下，我们看到许多次小垃圾回收，这些回收会使应用程序线程暂停 3 毫秒或更长时间。这很快就会累积到近 10 毫秒的响应时间延迟。正如你在图中看到的，增加负载会将曲线向左移动（会有更多峰值）。这是有道理的：记录更多意味着对垃圾回收器的压力更大，从而导致更多的小 GC 暂停。我们尝试过将负载降低到 50,000 甚至 5000 条消息/秒，但这并没有消除 3 毫秒的暂停，只是使它们发生的频率降低了。请注意，此测试中的所有 GC 暂停都是小 GC 暂停。我们没有看到任何完整的垃圾回收。

在无垃圾模式下，最大响应时间在各种负载下都保持在 1 毫秒以下。（在每秒 800,000 条消息时最大值为 780 微秒，在每秒 600,000 条消息时最大值为 407 微秒，对于所有负载（高达每秒 800,000 条消息）的 99% 约为 5 微秒。）增加或减少负载不会改变响应时间行为。我们没有调查在此测试中看到的 200-300 微秒暂停的原因。

当我们进一步增加负载时，我们开始看到经典日志记录和无垃圾日志记录的响应时间暂停更大。在每秒 100 万条消息或更高的持续负载下，我们开始接近底层 RandomAccessFile 附加程序的最大吞吐量（请参阅下面的同步日志记录吞吐量图表）。在这些负载下，环形缓冲区开始填满，反压开始起作用：当环形缓冲区已满时尝试添加另一条消息将阻塞，直到有空闲插槽可用。我们开始看到响应时间为数十毫秒或更长时间；尝试进一步增加负载会导致响应时间峰值更大。

同步文件日志记录

使用同步文件日志记录，无垃圾日志记录的性能仍然优于经典日志记录，但差异不那么明显。

在每秒 100,000 条消息的工作负载下，经典日志记录的最大响应时间略高于 2 毫秒，而无垃圾日志记录略高于 1 毫秒。当工作负载增加到每秒 300,000 条消息时，经典日志记录显示响应时间暂停为 6 毫秒，而无垃圾响应时间小于 3 毫秒。这可能还有改进的空间，我们还没有进一步调查。

以上结果是在 RHEL 6.5（Linux 2.6.32-573.1.1.el6.x86_64）上运行 JDK 1.8.0_45，使用 10 核 Xeon CPU E5-2660 v3 @2.60GHz，超线程开启（20 个虚拟核心）的 ResponseTimeTest 类获得的，该类可以在 Log4j 2 单元测试源目录中找到。

经典日志记录的吞吐量略高

与经典日志记录相比，无垃圾日志记录的吞吐量略低。这对于同步和异步日志记录都是如此。下图比较了 Log4j 2.6 在无垃圾模式、经典模式和 Log4j 2.5 中将同步日志记录到文件的持续吞吐量。

以上结果使用 JMH Java 基准测试工具获得。请参阅 log4j-perf 模块中的 FileAppenderBenchmark 源代码。