异步日志：性能优化的金钥匙_AI阅读总结 — 包阅AI

• 支持条件日志记录（Conditionals），可以根据运行时条件决定是否记录日志。

• AwaitCompletionReliabilityStrategy: 等待日志接收完成策略。这种策略主要是在应用关闭时，尽可能要等应用日志接收完成后再结束Appender的生命周期（这种策略只是说尽可能所有日志等待调用Appender.append方法完成，但在异步日志场景下，Appender.append其实是落了ringbuffer或者其他队列里，实际上未持久化。因此该策略是尽可能保证接收完成而非处理完成）

• AwaitUnconditionallyReliabilityStrategy: 无条件等待策略。这种策略会在rootLogger关闭时无条件等待一段时间，具体等待时间可以配置log4j2.component.properties文件的log4j.waitMillisBeforeStopOldConfig属性。

• DefaultReliabilityStrategy: 默认策略。该策略不做任何等待。
• LockingReliabilityStrategy: 锁等待策略。该策略当正在写入日志时，则会等待；否则即会停止等待。

import java.util.Arrays;
import org.apache.logging.log4j.core.LogEvent;import org.apache.logging.log4j.core.config.plugins.Plugin;import org.apache.logging.log4j.core.pattern.ConverterKeys;import org.apache.logging.log4j.core.pattern.LogEventPatternConverter;import org.apache.logging.log4j.message.FormattedMessage;import org.apache.logging.log4j.message.Message;import org.apache.logging.log4j.message.MessageFormatMessage;import org.apache.logging.log4j.message.ParameterizedMessage;import org.apache.logging.log4j.message.StringFormattedMessage;import org.apache.logging.log4j.util.PerformanceSensitive;
@Plugin(        name = "ShieldPatternConverter",        category = "Converter")@ConverterKeys({"shield", "sd", "shieldMessage", "sm"})@PerformanceSensitive({"allocation"})public final class ShieldMessagePatternConverter extends LogEventPatternConverter {    private final String[] options;
    private ShieldMessagePatternConverter(String[] options) {        super("Shield", "shield");        this.options = options == null ? null : (String[])Arrays.copyOf(options, options.length);    }
        public static ShieldMessagePatternConverter newInstance(String[] options) {        return new ShieldMessagePatternConverter(options);    }

    @Override    public void format(LogEvent logEvent, StringBuilder output) {        Message message = logEvent.getMessage();        String format = message.getFormat();
        if (isFormatMessage(message)) {                        String msgInfo = ShieldUtils.format(format, message.getParameters());
            output.append(msgInfo);        } else {            output.append(message.getFormattedMessage());        }    }
    private boolean isFormatMessage(Message message) {        return message instanceof ParameterizedMessage || message instanceof StringFormattedMessage                || message instanceof FormattedMessage || message instanceof MessageFormatMessage;    }}

        <RollingFile name="TEST_APPENDER" fileName="test.log"                     filePattern="test.log.%d{yyyy-MM-dd}"                     append="true">                        <PatternLayout pattern="%d %sm%n" charset="UTF-8"/>            <TimeBasedTriggeringPolicy/>            <DefaultRolloverStrategy/>        </RollingFile>

异步日志原理概述

Disrupter组件构成：

如何使用异步日志

• 通过JVM启动参数来全局启用异步日志功能。在启动应用程序时，向JVM传递以下系统属性：

-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

• 在类路径（classpath）中添加一个名为log4j2.component.properties的文件，并包含以下内容（这个文件会在Log4j2初始化时被读取）：

Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

这两种方式下，所有Logger都会自动使用异步处理。

<Configuration status='WARN'><Appenders>        ... <!-- your appenders here --></Appenders><Loggers><AsyncRoot level='info' includeLocation='false'><AppenderRef ref='yourAppenderName'/></AsyncRoot><!-- 或者为特定logger配置 --><AsyncLogger name='com.example.MyClass' level='debug'><AppenderRef ref='yourAppenderName'/></AsyncLogger></Loggers></Configuration>


异步日志的潜在问题及解决方案


日志丢失问题：如果机器发生意外重启、发布、掉电导致的jvm进程停止，停留在队列的未来得及输出到目的地的LogEvent可能会丢失


日志顺序问题：由于日志事件是在不同的线程中异步处理的，因此日志条目可能不会严格按照它们产生的顺序出现在日志文件中，这对于需要严格按时间顺序追踪日志的应用可能是个问题。


其他问题：如增加资源损耗、配置复杂度和调试复杂度等问题








原生Log4j2有完整的生命周期管理，并监听了jvm关闭的事件。当jvm关闭时，Log4j2会监听Disrupter队列中的RingbufferLogEvent数量，直到日志打印完（或超时）才释放关闭Log4j2，jvm才得以正常关闭。但是自然灾害或者机房掉电等不可抗力因素，无法避免丢失问题。


我们基于Log4j2定制的AsyncAbleRollingFileAppender，其中有独立的Disrupter，且不在Log4j2生命周期管理当中，存在日志丢失风险。可以采用类似方案解决：


try {            LoggerContextFactory factory = LogManager.getFactory();            if (!(factory instanceof Log4jContextFactory)) {                return;            }            Log4jContextFactory log4jContextFactory = (Log4jContextFactory) factory;            ShutdownCallbackRegistry registry = log4jContextFactory.getShutdownCallbackRegistry();            if (!(registry instanceof DefaultShutdownCallbackRegistry)) {                return;            }            DefaultShutdownCallbackRegistry defaultShutdownCallbackRegistry = (DefaultShutdownCallbackRegistry) registry;            Field hooksField = DefaultShutdownCallbackRegistry.class.getDeclaredField("hooks");            hooksField.setAccessible(true);            Collection<Cancellable> hooks = (Collection<Cancellable>) hooksField.get(defaultShutdownCallbackRegistry);            Collection<Cancellable> newHooks = new CopyOnWriteArrayList<>();                        newHooks.add(new Log4j2Cancellable(() -> {                               new AppenderUnInstaller(register).run();            }));            newHooks.addAll(hooks);            hooksField.set(defaultShutdownCallbackRegistry, newHooks);        } catch (NoSuchFieldException e) {                    } catch (IllegalAccessException e) {                    }



AsyncAbleRollingFileAppender使用独立的disrupter，且RingBufferLogEvent未及时清理对象，容易导致内存泄漏，异步日志场景请慎用。







异步线程池大小设置为1，但是会影响日志打印的速度（现在的普遍做法）。






4月份的这一问题发生后，我们从原理出发，对理财的核心应用做了升级和优化，整体服务耗时上取得了不错的性能优化效果。





但与此同时，我们也发现升级后，应用的fgc次数更多了，经过heapdump分析后，发现AsyncAbleRollingFileAppender内部实现的RingBufferLogEvent执行后，不会释放引用的LogEvent，导致Disrupter一直持有已打印的LogEvent的引用关系，进而导致了内存泄漏。后来，我们采取主动释放对象引用（RingBufferLogEvent.setLogEvent(null)）优化的方案，发布以后前后fgc对比如下：
日志作为诊断问题、监控系统健康状况与优化服务效能不可或缺的一环，其重要性不言而喻。熟练掌握并有效利用如Log4j2这样的高性能日志框架以及注意一些打印日志的策略（如动静分离、合理分割、合理设置日志级别等），对于开发者而言至关重要：

1）动静分离 ：在一些大日志输出场景中，即使是异步日志也会给系统带来性能风险。因此建议合理识别大日志中的动态数据和静态数据。静态数据定时输出，动态数据关联唯一静态标识输出，在降低性能风险的同时又满足监控分析的需要；
2）合理分割 ：日志文件需要合理分割，并设置合理的保留策略，及时释放磁盘空间。
3）合理设置日志级别 ：避免日志滥用，尤其是debug日志，既有利于日志定位问题的速度，又能提高性能。