Spring Boot Webflux集成Log4j2内存飙升问题排查咨询

一、优先排查自定义LoggingFilter的MDC处理逻辑 #

Webflux是反应式非阻塞模型，MDC依赖的ThreadLocal使用逻辑和Servlet同步模型完全不同，这是此类问题的高发点：

• 检查LoggingFilter中复制MDC的代码：是否在请求处理完成（包括异常分支）后没有清理MDC？反应式流中请求会在多线程间切换，若MDC未及时移除，线程池中的线程会长期持有MDC映射，最终关联到Log4j2内部的Logger缓存。
• 确认是否错误绑定MDC到全局上下文：比如直接用MDC.put()而非通过SubscriberContext传递MDC值，导致MDC被线程池线程永久保留，进而阻止Logger对象被GC回收。
• 验证Filter的执行包裹逻辑：是否在filter()方法中正确用doFinally或类似机制包裹MDC清理逻辑，避免因异常跳过清理步骤。

二、分析Log4j2 Logger对象的缓存机制 #

Log4j2通过ConcurrentHashMap缓存Logger和LoggerContextFactory实例，若缓存实例无法被GC回收，会持续占用堆内存：

• 检查是否存在动态生成Logger名称的场景：比如用请求ID、UUID、接口参数作为Logger名称，每次请求创建新的Logger实例，这些实例会被Log4j2缓存永久持有（默认无自动清理逻辑），直接导致ConcurrentHashMap的Node数量持续增长。
• 查看Log4j2配置：是否开启Logger缓存自动过期？可添加log4j2.loggerContext.cache.ttl=3600参数（单位秒），让未使用的Logger实例自动从缓存中移除，压测验证是否能降低内存占用。
• 排查AsyncFile Appender的线程池：异步日志线程池若持有未清理的MDC，会导致ThreadLocal关联Logger对象，阻止GC。检查Appender的线程池配置，以及日志异步处理时的MDC传递逻辑。

三、排查WebClient的MDC传递问题 #

WebClient调用后端服务时，错误的MDC传递逻辑可能导致上下文被长期持有：

• 检查WebClient的ExchangeFilterFunction：若自定义了传递MDC的过滤器，是否正确使用SubscriberContext传递值，而非直接操作ThreadLocal？错误的传递方式会让MDC被线程池线程保留。
• 验证WebClient请求后的MDC清理：是否在请求完成后，从SubscriberContext中移除了MDC相关值，避免上下文被不必要的对象引用。

四、HeapDump的深度分析 #

基于已有的HeapDump进一步挖掘细节：

• 定位ConcurrentHashMap的Node对象：查看其key值，若为动态生成的Logger名称（含请求ID、随机字符串等），直接锁定动态Logger的问题。
• 追踪Logger对象的引用链：找到持有Logger实例的对象，比如线程池的ThreadLocal、反应式Context、自定义缓存等，明确内存泄漏的根路径。
• 关联监控时间点：结合应用监控数据（如Micrometer指标），看6小时的内存飙升是否与线程池扩容、定时任务执行、后端服务超时重试等事件重合，缩小排查范围。

五、代码验证与临时验证方案 #

• 临时关闭自定义LoggingFilter，重新压测：若内存不再飙升，直接定位到Filter的MDC处理逻辑问题。
• 临时禁用Log4j2的MDC功能：压测观察内存变化，验证是否为MDC导致Logger引用无法释放。
• 替换AsyncFile Appender为同步File Appender：排除异步线程池持有MDC的可能性。

内容的提问来源于stack exchange，提问作者springbootlearner