权衡

虽然异步日志记录可以带来显著的性能优势，但在某些情况下，您可能希望选择同步日志记录。本节介绍了异步日志记录的一些权衡。

优点

• 更高的峰值 吞吐量。使用异步日志记录器，您的应用程序可以以同步日志记录器的 6 到 68 倍的速度记录消息。

  这对偶尔需要记录大量消息的应用程序特别有用。异步日志记录可以通过缩短等待下一个消息可以记录的时间来帮助防止或抑制延迟峰值。如果队列大小配置得足够大以处理突发，异步日志记录将有助于防止您的应用程序在活动突然增加时落后（太多）。

• 更低的日志记录响应时间 延迟。响应时间延迟是指在给定工作负载下，对 Logger.log 的调用返回所需的时间。异步日志记录器始终比同步日志记录器甚至基于队列的异步追加器具有更低的延迟。

• 错误处理。如果在日志记录过程中出现问题并抛出异常，异步日志记录器或追加器很难向应用程序发出此问题的信号。这可以通过配置 ExceptionHandler 来部分缓解，但这可能仍然无法涵盖所有情况。因此，如果日志记录是您业务逻辑的一部分，例如，如果您使用 Log4j 作为审计日志记录框架，我们建议同步记录这些审计消息。（请注意，您仍然可以 组合它们，并使用异步日志记录进行调试/跟踪日志记录，以及使用同步日志记录进行审计跟踪。）
• 在某些罕见情况下，必须注意可变消息。大多数情况下，您无需担心这一点。Log4 将确保像 logger.debug("My object is {}", myObject) 这样的日志消息将在调用 logger.debug() 时使用 myObject 参数的状态。即使 myObject 稍后被修改，日志消息也不会改变。异步记录可变对象是安全的，因为 Log4j 中内置的大多数 Message 实现都会对参数进行快照。但是，有一些例外：MapMessage 和 StructuredDataMessage 都是可变的：在创建消息对象后，可以向这些消息添加字段。这些消息不应在使用异步日志记录器或异步追加器记录后进行修改；您可能在生成的日志输出中看到这些修改，也可能看不到。类似地，自定义 Message 实现应在设计时考虑异步使用，并在构造时对参数进行快照，或者记录其线程安全特性。
• 如果您的应用程序在 CPU 资源稀缺的环境中运行，例如一台只有一个 CPU 和一个内核的机器，启动另一个线程不太可能带来更好的性能。
• 如果您的应用程序记录消息的持续速率快于底层追加器的最大持续吞吐量，队列将填满，应用程序最终将以最慢的追加器的速度进行日志记录。如果发生这种情况，请考虑选择一个 更快的追加器，或者减少日志记录。如果这两个选项都不行，您可以通过同步日志记录获得更好的吞吐量和更少的延迟峰值。

使所有日志记录器异步

Log4j-2.9 及更高版本需要在类路径上使用 disruptor-3.3.4.jar 或更高版本。在 Log4j-2.9 之前，需要 disruptor-3.0.0.jar 或更高版本。

这是最简单的配置方法，并且可以提供最佳性能。要使所有日志记录器异步，请将 disruptor jar 添加到类路径，并将系统属性 log4j2.contextSelector 设置为 org.apache.logging.log4j.core.async.AsyncLoggerContextSelector 或 org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector。

默认情况下，异步日志记录器不会将 位置 传递给 I/O 线程。如果您的布局或自定义过滤器需要位置信息，您需要在所有相关日志记录器的配置中设置“includeLocation=true”，包括根日志记录器。

不需要位置的配置可能如下所示

<?xml version="1.0" encoding="UTF-8"?>

<!-- Don't forget to set system property
-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
or
-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector
     to make all loggers asynchronous. -->

<Configuration status="WARN">
  <Appenders>
    <!-- Async Loggers will auto-flush in batches, so switch off immediateFlush. -->
    <RandomAccessFile name="RandomAccessFile" fileName="async.log" immediateFlush="false" append="false">
      <PatternLayout>
        <Pattern>%d %p %c{1.} [%t] %m %ex%n</Pattern>
      </PatternLayout>
    </RandomAccessFile>
  </Appenders>
  <Loggers>
    <Root level="info" includeLocation="false">
      <AppenderRef ref="RandomAccessFile"/>
    </Root>
  </Loggers>
</Configuration>

当使用 AsyncLoggerContextSelector 或 BasicAsyncLoggerContextSelector 使所有日志记录器异步时，请确保在配置中使用正常的 <root> 和 <logger> 元素。上下文选择器将确保所有日志记录器都是异步的，使用与配置 <asyncRoot> 或 <asyncLogger> 时不同的机制。后者的元素旨在将异步与同步日志记录器混合使用。如果您将两种机制一起使用，您将最终获得两个后台线程，其中您的应用程序将日志消息传递给线程 A，线程 A 将消息传递给线程 B，然后线程 B 最终将消息记录到磁盘。这可以工作，但中间会有一步是不必要的。

您可以使用一些系统属性来控制异步日志子系统的各个方面。其中一些属性可用于调整日志性能。

还可以通过创建名为log4j2.component.properties的文件并将此文件包含在应用程序的类路径中来指定以下属性。

请注意，在 Log4j 2.10.0 中，系统属性已重命名为更一致的样式。所有旧的属性名称仍然受支持，这些名称在此处有记录。

还有一些系统属性可用于即使在底层追加器无法跟上日志记录速率并且队列正在填满的情况下也能保持应用程序吞吐量。有关系统属性log4j2.asyncQueueFullPolicy和log4j2.discardThreshold的详细信息，请参见。

混合同步和异步记录器

Log4j-2.9 及更高版本需要类路径中的 disruptor-3.3.4.jar 或更高版本。在 Log4j-2.9 之前，需要 disruptor-3.0.0.jar 或更高版本。无需将系统属性“Log4jContextSelector”设置为任何值。

可以在配置中组合同步和异步记录器。这为您提供了更大的灵活性，但会以略微降低性能为代价（与使所有记录器都异步相比）。使用<asyncRoot>或<asyncLogger>配置元素来指定需要异步的记录器。一个配置只能包含一个根记录器（<root>或<asyncRoot>元素），但除此之外，可以组合异步和非异步记录器。例如，包含<asyncLogger>元素的配置文件也可以包含用于同步记录器的<root>和<logger>元素。

默认情况下，异步日志记录器不会将 位置 传递给 I/O 线程。如果您的布局或自定义过滤器需要位置信息，您需要在所有相关日志记录器的配置中设置“includeLocation=true”，包括根日志记录器。

混合异步记录器的配置可能如下所示

<?xml version="1.0" encoding="UTF-8"?>

<!-- No need to set system property "log4j2.contextSelector" to any value
     when using <asyncLogger> or <asyncRoot>. -->

<Configuration status="WARN">
  <Appenders>
    <!-- Async Loggers will auto-flush in batches, so switch off immediateFlush. -->
    <RandomAccessFile name="RandomAccessFile" fileName="asyncWithLocation.log"
              immediateFlush="false" append="false">
      <PatternLayout>
        <Pattern>%d %p %class{1.} [%t] %location %m %ex%n</Pattern>
      </PatternLayout>
    </RandomAccessFile>
  </Appenders>
  <Loggers>
    <!-- pattern layout actually uses location, so we need to include it -->
    <AsyncLogger name="com.foo.Bar" level="trace" includeLocation="true">
      <AppenderRef ref="RandomAccessFile"/>
    </AsyncLogger>
    <Root level="info" includeLocation="true">
      <AppenderRef ref="RandomAccessFile"/>
    </Root>
  </Loggers>
</Configuration>

您可以使用一些系统属性来控制异步日志子系统的各个方面。其中一些属性可用于调整日志性能。

还可以通过创建名为log4j2.component.properties的文件并将此文件包含在应用程序的类路径中来指定以下属性。

请注意，在 Log4j 2.10 中，系统属性已重命名为更一致的样式。所有旧的属性名称仍然受支持，这些名称在此处有记录。

还有一些系统属性可用于即使在底层追加器无法跟上日志记录速率并且队列正在填满的情况下也能保持应用程序吞吐量。有关系统属性log4j2.asyncQueueFullPolicy和log4j2.discardThreshold的详细信息，请参见。

自定义 WaitStrategy

上面提到的系统属性只允许从一组预定义的 WaitStrategy 中进行选择。在某些情况下，您可能希望配置此列表中不存在的自定义 WaitStrategy。这可以通过在 Log4j 配置中使用AsyncWaitStrategyFactory元素来实现。

配置自定义 WaitStrategy 的配置可能如下所示

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">

  <AsyncWaitStrategyFactory
      class="my.custom.AsyncWaitStrategyFactory" />

  <Appenders>
    <File name="MyFile" fileName="logs/app.log">
      <PatternLayout pattern="%d %p %c{1.} [%t] %m%n" />
    </File>
  </Appenders>
  <Loggers>
    <AsyncRoot level="info">
      <AppenderRef ref="MyFile"/>
    </AsyncRoot>
  </Loggers>
</Configuration>

指定的类必须实现org.apache.logging.log4j.core.async.AsyncWaitStrategyFactory接口，该接口定义如下

public interface AsyncWaitStrategyFactory {
  /**
  * Returns a non-null implementation of the LMAX Disruptor's WaitStrategy interface.
  * This WaitStrategy will be used by Log4j Async Loggers and Async LoggerConfigs.
  *
  * @return the WaitStrategy instance to be used by Async Loggers and Async LoggerConfigs
  */
  WaitStrategy createWaitStrategy();
}
        

指定的类还必须具有一个公共的无参数构造函数；Log4j 将实例化指定工厂类的实例，并使用此工厂来创建所有异步记录器使用的 WaitStrategy。

如果配置了AsyncWaitStrategyFactory，则会忽略与 WaitStrategy 相关的系统属性。

位置、位置、位置...

如果其中一个布局配置了与位置相关的属性，例如 HTML locationInfo，或其中一个模式%C 或 $class、%F 或 %file、%l 或 %location、%L 或 %line、%M 或 %method，Log4j 将对堆栈进行快照，并遍历堆栈跟踪以查找位置信息。

这是一个昂贵的操作：对于同步记录器，速度慢 1.3-5 倍。同步记录器会在尽可能长时间地等待后才进行此堆栈快照。如果不需要位置，则永远不会进行快照。

但是，异步记录器需要在将日志消息传递给另一个线程之前做出此决定；位置信息将在该点之后丢失。对于异步记录器，进行堆栈跟踪快照的性能影响甚至更高：使用位置进行日志记录比不使用位置慢 30-100 倍。因此，异步记录器和异步追加器默认情况下不包含位置信息。

您可以在记录器或异步追加器配置中通过指定includeLocation="true"来覆盖默认行为。

异步日志记录性能

以下吞吐量性能结果来自运行 PerfTest、MTPerfTest 和 PerfTestDriver 类，这些类可以在 Log4j 2 单元测试源目录中找到。对于吞吐量测试，使用的方法是

• 首先，通过记录 200,000 条 500 个字符的日志消息来预热 JVM。
• 重复预热 10 次，然后等待 10 秒钟，让 I/O 线程赶上来并清空缓冲区。
• 测量执行 256 * 1024 / threadCount 次 Logger.log 调用需要多长时间，并将结果表示为每秒消息数。
• 重复测试 5 次，并对结果进行平均。

以下结果是在 log4j-2.0-beta5、disruptor-3.0.0.beta3、log4j-1.2.17 和 logback-1.0.10 上获得的。

幕后

异步日志记录器使用LMAX Disruptor 线程间消息传递库实现。来自 LMAX 网站

... 使用队列在系统各个阶段之间传递数据会导致延迟，因此我们专注于优化这一领域。Disruptor 是我们研究和测试的结果。我们发现，CPU 级别的缓存未命中以及需要内核仲裁的锁都非常昂贵，因此我们创建了一个框架，该框架对运行它的硬件具有“机械同情心”，并且是无锁的。

LMAX Disruptor 与java.util.concurrent.ArrayBlockingQueue 的内部性能比较可以在这里找到。