nacos-client从2.1.2升级到2.4.2之后，unload class持续增长

[willchaofeiyang]

Nacos Client 2.4.2 日志重载导致大量 ClassUnload 事件

环境信息

• Nacos Client 版本: 2.4.2
• 旧版本: 2.1.2（无此问题）
• JDK 版本: 21.0.6
• 日志框架: Log4j2
• 监控工具: Java Flight Recorder (JFR)

问题描述

将 Nacos Client 从 2.1.2 升级到 2.4.2 后，我们观察到 ClassUnload 事件数量显著增加。

观察到的现象

指标	2.1.2 版本	2.4.2 版本	影响
ClassUnload 事件	极少	每 2 小时左右 300-400 个	⬆️ 显著增加
来源线程	无	com.alibaba.nacos.client.logging.0	98.6% 的新加载

根因分析

通过详细的 JFR 数据分析，我们确定了 2.4.2 版本引入的 Nacos 日志重载机制 是导致此问题的根本原因：

1. 定期检查: 日志线程默认每 10 秒检查一次配置变化
2. 频繁重载: 不知为何，重载大约每 1-2 小时触发一次（即使日志配置文件从未被修改）
3. LambdaForm 生成: 每次重载都会触发 Log4j2 插件系统重新初始化，生成 150-200 个新的 java.lang.invoke.LambdaForm 类
4. Metaspace GC: 这些类不断累积，最终在每 2 小时左右的 Metaspace GC 时被批量卸载

源码引用

源码位置: com/alibaba/nacos/client/logging/NacosLogging.java

问题代码（v2.4.2）

// NacosLogging.java - 第 82-91 行
private void scheduleReloadTask() {
    ScheduledExecutorService reloadContextService = ExecutorFactory.Managed
            .newSingleScheduledExecutorService("Nacos-Client",
                    new NameThreadFactory("com.alibaba.nacos.client.logging"));
    reloadContextService.scheduleAtFixedRate(() -> {
        if (loggingAdapter.isNeedReloadConfiguration()) {
            loggingAdapter.loadConfiguration(loggingProperties);
        }
    }, 0, loggingProperties.getReloadInternal(), TimeUnit.SECONDS);
}

默认间隔: NacosLoggingProperties.DEFAULT_RELOAD_INTERNAL_SECONDS = 10（秒）

调用堆栈（来自 JFR）

线程: com.alibaba.nacos.client.logging.0

com.alibaba.nacos.client.logging.NacosLogging.lambda$scheduleReloadTask$0(NacosLogging.java:88)
  ↓
com.alibaba.nacos.logger.adapter.log4j2.Log4J2NacosLoggingAdapter.loadConfiguration
  ↓
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:319)
  ↓
org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:198)
  ↓
java.lang.reflect.Field.set(Field.java:836)
  ↓
java.lang.invoke.MethodHandle.asType(MethodHandle.java:870)
  ↓
java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:849)
  ↓
生成: java.lang.invoke.LambdaForm$MH+0x.../[identityHash]（每次重载 150-200 个类）

需要确认的问题

1. 根因确认

问: 能否确认 NacosLogging.scheduleReloadTask() 中的定期日志重载机制是导致频繁 ClassLoad/Unload 事件的根本原因？

我们的发现:

• 98.6% 的新 ClassUnload的类 是来自 com.alibaba.nacos.client.logging.0 线程创建的
• 重载大约每 1-2 小时触发一次，即使日志配置文件从未被修改
• 每次重载由于 Log4j2 插件重新初始化会生成 150-200 个新的 LambdaForm 类

2. 是否可以默认禁用此功能

问: 是否可以默认禁用此功能，或者额有什么配置关闭此功能（配置文件中的配置）？

当前问题:
设置 -Dnacos.logging.reload.interval.seconds=-1 会导致启动失败：

java.lang.IllegalArgumentException
  at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:623)
  at com.alibaba.nacos.client.logging.NacosLogging.scheduleReloadTask(NacosLogging.java:86)
  at com.alibaba.nacos.client.logging.NacosLogging.initLoggingAdapter(NacosLogging.java:66)
  at com.alibaba.nacos.client.logging.NacosLogging.<init>(NacosLogging.java:46)

我们的临时解决方案:

-Dnacos.logging.reload.interval.seconds=31536000  # 1 年（实际上相当于禁用）

此方案成功阻止了频繁的 ClassLoad/Unload， 是否可以默认关闭动态加载配置呢？

感谢您关注此问题。我们非常感谢 Nacos 项目，期待您的解决方案！ 🙏

[JGoP-L]

1.Log4j2 你使用的是nacos所提供的还是自己的？
我找到的原因：
问题出在 Log4J2NacosLoggingAdapter 类的 isNeedReloadConfiguration() 方法。
这个方法通过检查 Log4j2 配置中是否存在名为 ASYNC_NAMING 的 Appender 来判断是否需要重载配置：
如果找到这个 Appender，说明 Nacos 配置已加载，返回 false（不需要重载）
如果找不到，就认为需要加载，返回 true
修复方案：
基于配置文件内容哈希的智能重载
1.不依赖特定的 Appender 名称，而是通过配置文件内容的哈希值来判断是否需要重载。
2.不依赖特定的 Appender 标记，适用于任何自定义配置
3.只有配置文件实际发生变化时才重载
4.避免不必要的配置解析和重载
重载的本意就是响应配置文件的变化
实现要点：
在 Log4J2NacosLoggingAdapter 中维护配置文件的内容哈希值
每次检查时，计算当前配置文件的哈希值并与上次对比
只有哈希值变化时才返回 true 触发重载
如果配置文件不存在或读取失败，记录状态避免重复尝试 。
如果认同\或者有更好的方案，我可以提PR

[KomachiSion]

重载的本意就是响应配置文件的变化

这个观点是错误的。

Log4J2NacosLoggingAdapter （包括其他的adapter）出现的原因是部分框架比如spring cloud， 会在启动过程中多次重载log配置， 可能导致nacos-client的自身日志配置被移除（因为最初的版本只在启动时加载一次）。

这个issue之前提交给spring cloud alibaba社区， 但这样只能解决部分版本且只能解决这一个框架的问题。所以在nacos-client中添加了这个adapter机制，通过日志框架本身的机制（如有）或context中是否存在nacos的日志appender来判断是否需要将nacos的日志配置重载进入日志context中。

如果日志配置的md5没有任何变化， 如果只基于日志配置的md5在日志配置md5变化后重载， 会导致nacos-client的日志在日志配置变化前都会输出在业务日志中而不是nacos自身日志中。

影响排查不说，可能造成日志输出过多的问题。

因此我不认同现在的修复方案，核心点还是要排查出为何isNeedReloadConfiguration会返回true， 及ASYNC_NAMING的appender不在context中。

当然如果能提出其他支持方案，也是可以的。

[JGoP-L]

重载的本意就是响应配置文件的变化

这个观点是错误的。

Log4J2NacosLoggingAdapter （包括其他的adapter）出现的原因是部分框架比如spring cloud， 会在启动过程中多次重载log配置， 可能导致nacos-client的自身日志配置被移除（因为最初的版本只在启动时加载一次）。

这个issue之前提交给spring cloud alibaba社区， 但这样只能解决部分版本且只能解决这一个框架的问题。所以在nacos-client中添加了这个adapter机制，通过日志框架本身的机制（如有）或context中是否存在nacos的日志appender来判断是否需要将nacos的日志配置重载进入日志context中。

如果日志配置的md5没有任何变化， 如果只基于日志配置的md5在日志配置md5变化后重载， 会导致nacos-client的日志在日志配置变化前都会输出在业务日志中而不是nacos自身日志中。

影响排查不说，可能造成日志输出过多的问题。

因此我不认同现在的修复方案，核心点还是要排查出为何isNeedReloadConfiguration会返回true， 及ASYNC_NAMING的appender不在context中。

当然如果能提出其他支持方案，也是可以的。

我排查了一下，发现外部框架在重新加载 Log4j2 配置时，可能会通过多种方式修改配置，其中loggerContext.setConfiguration(newConfig) 是常见的方式之一（这是 Log4j2 的标准 API，用于替换日志配置）。该方法会替换整个 Configuration，而不是合并，导致 Nacos 之前添加的 ASYNC_NAMING appender 被移除。
实现：
如果直接检测 appender 是否存在，检查 context 中是否存在 ASYNC_NAMING appender，如果存在，不需要重载，如果不存在且已加载过，立即重载。当 appender 缺失且已加载过时，立即返回 true，不等待配置文件变化，目的是恢复 appender，而不是响应配置文件变化（不支持配置文件热更新）

[KomachiSion]

重载的本意就是响应配置文件的变化

这个观点是错误的。
Log4J2NacosLoggingAdapter （包括其他的adapter）出现的原因是部分框架比如spring cloud， 会在启动过程中多次重载log配置， 可能导致nacos-client的自身日志配置被移除（因为最初的版本只在启动时加载一次）。
这个issue之前提交给spring cloud alibaba社区， 但这样只能解决部分版本且只能解决这一个框架的问题。所以在nacos-client中添加了这个adapter机制，通过日志框架本身的机制（如有）或context中是否存在nacos的日志appender来判断是否需要将nacos的日志配置重载进入日志context中。
如果日志配置的md5没有任何变化， 如果只基于日志配置的md5在日志配置md5变化后重载， 会导致nacos-client的日志在日志配置变化前都会输出在业务日志中而不是nacos自身日志中。
影响排查不说，可能造成日志输出过多的问题。
因此我不认同现在的修复方案，核心点还是要排查出为何isNeedReloadConfiguration会返回true， 及ASYNC_NAMING的appender不在context中。
当然如果能提出其他支持方案，也是可以的。

我排查了一下，发现外部框架在重新加载 Log4j2 配置时，可能会通过多种方式修改配置，其中loggerContext.setConfiguration(newConfig) 是常见的方式之一（这是 Log4j2 的标准 API，用于替换日志配置）。该方法会替换整个 Configuration，而不是合并，导致 Nacos 之前添加的 ASYNC_NAMING appender 被移除。 实现： 如果直接检测 appender 是否存在，检查 context 中是否存在 ASYNC_NAMING appender，如果存在，不需要重载，如果不存在且已加载过，立即重载。当 appender 缺失且已加载过时，立即返回 true，不等待配置文件变化，目的是恢复 appender，而不是响应配置文件变化（不支持配置文件热更新）

我看现在就是这个逻辑啊， isNeedReloadConfiguration就是在判断ASYNC_NAMING appender是否存在， 存在就返回false， 不存在就返回true，然后执行重新添加appender

[JGoP-L]

重载的本意就是响应配置文件的变化

这个观点是错误的。
Log4J2NacosLoggingAdapter （包括其他的adapter）出现的原因是部分框架比如spring cloud， 会在启动过程中多次重载log配置， 可能导致nacos-client的自身日志配置被移除（因为最初的版本只在启动时加载一次）。
这个issue之前提交给spring cloud alibaba社区， 但这样只能解决部分版本且只能解决这一个框架的问题。所以在nacos-client中添加了这个adapter机制，通过日志框架本身的机制（如有）或context中是否存在nacos的日志appender来判断是否需要将nacos的日志配置重载进入日志context中。
如果日志配置的md5没有任何变化， 如果只基于日志配置的md5在日志配置md5变化后重载， 会导致nacos-client的日志在日志配置变化前都会输出在业务日志中而不是nacos自身日志中。
影响排查不说，可能造成日志输出过多的问题。
因此我不认同现在的修复方案，核心点还是要排查出为何isNeedReloadConfiguration会返回true， 及ASYNC_NAMING的appender不在context中。
当然如果能提出其他支持方案，也是可以的。

我排查了一下，发现外部框架在重新加载 Log4j2 配置时，可能会通过多种方式修改配置，其中loggerContext.setConfiguration(newConfig) 是常见的方式之一（这是 Log4j2 的标准 API，用于替换日志配置）。该方法会替换整个 Configuration，而不是合并，导致 Nacos 之前添加的 ASYNC_NAMING appender 被移除。 实现： 如果直接检测 appender 是否存在，检查 context 中是否存在 ASYNC_NAMING appender，如果存在，不需要重载，如果不存在且已加载过，立即重载。当 appender 缺失且已加载过时，立即返回 true，不等待配置文件变化，目的是恢复 appender，而不是响应配置文件变化（不支持配置文件热更新）

我看现在就是这个逻辑啊， isNeedReloadConfiguration就是在判断ASYNC_NAMING appender是否存在， 存在就返回false， 不存在就返回true，然后执行重新添加appender

不好意思，之前的逻辑确实是这么实现的。 我看代码里面每次重载都完整重新初始化 configuration.start() ，如果第一次加载：完整初始化（必需），后续重载：只恢复 appender，不重新初始化，配置变化：才完整重新初始化

[KomachiSion]

所以问题还是没找到， 或者是我没理解？

[JGoP-L]

所以问题还是没找到， 或者是我没理解？

我分析的过程：
1.模拟框架首次加载 原来的代码修改是没问题的
2. 模拟外部框架启动时替换 Log4j2 Configuration 对象，导致 Nacos 的 appender 丢失。热部署会加剧这个问题，外部框架替换 LoggerContext 的 Configuration 对象，每次检测都走configuration.start()
3.查看历史git 找到和当前相关的Issue #827 ， 用"创建临时 Configuration - 提取 - 追加"模式，引入了"临时对象浪费"的问题
4. Log4j2 API 限制：只能创建完整的 Configuration 对象，无法从 XML 直接创建单个 Appender，Appender 必须通过 configuration.start() 初始化
解决方案：缓存 + 增强检查
以上是我分析的过程。

[KomachiSion]

我看下来， 问题有两个：

1. 找到为何频繁的热加载Log4j2 的 LoggerContext - Configuration
2. 若频繁的热加载过成是合理的，缓存首次创建的appender并在之后进行重新注入是否会有问题（比如按照log4j2的生命周期管理，是否会在旧Configuration关闭时，把appender也关闭。如果会关闭的话，那么重新加载也是合理的， 这个场景下只能出现unload的增长。

如果问题2不存在， 那可以细化一下缓存 + 增强检查的逻辑， issue讨论一下如果问题不大，欢迎提交PR优化此问题

[JGoP-L]

我看下来， 问题有两个：

1. 找到为何频繁的热加载Log4j2 的 LoggerContext - Configuration
2. 若频繁的热加载过成是合理的，缓存首次创建的appender并在之后进行重新注入是否会有问题（比如按照log4j2的生命周期管理，是否会在旧Configuration关闭时，把appender也关闭。如果会关闭的话，那么重新加载也是合理的， 这个场景下只能出现unload的增长。

如果问题2不存在， 那可以细化一下缓存 + 增强检查的逻辑， issue讨论一下如果问题不大，欢迎提交PR优化此问题

缓存的方案我尝试了一下也是有问题，你看我最新的pr修改，看看这种方案会有问题吗？

[KomachiSion]

@JGoP-L 请帮忙帮v2.x-develop分支也提交一个修复