Spring Boot中MDC上下文清理逻辑结合拦截器偶发失效后自动恢复的原因排查求助

问题背景梳理 #

我在Spring Boot应用里碰到了MDC上下文清理的偶发异常问题，先把整个过程和代码情况跟大家说清楚：

最初的代码实现问题

一开始我通过配置类注册了LogContextCleaner Bean：

@Configuration
public class LogContextCleanerConfig {
    @Bean
    public LogContextCleaner logContextCleaner() {
        return new LogContextCleaner();
    }
}

同时在WebConfig里手动封装了拦截器并注册：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Autowired
    private LogContextCleaner logContextCleaner;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loggingInterceptor(logContextCleaner));
    }

    private HandlerInterceptor loggingInterceptor(LogContextCleaner logContextCleaner) {
        return new HandlerInterceptor() {
            @Override
            public void afterCompletion(HttpServletRequest req, HttpServletResponse res, Object handler, Exception ex) throws Exception {
                logContextCleaner.afterCompletion(req, res, handler, ex);
            }
        };
    }
}

而LogContextCleaner是依赖中的组件：

@Component
public class LogContextCleaner implements HandlerInterceptor {
    @Override
    public void afterCompletion(HttpServletRequest req, HttpServletResponse res, Object handler, Exception ex) throws Exception {
        MDC.clear();
    }
}

但发现MDC.clear()完全没执行，找不到原因。

后续调整后的新状况

后来我意识到不该手动封装loggingInterceptor，已经把这部分代码移除了。另外发现之前清理的是错误的MDC实例，正确的应该是OrdersLogContext里的MDC，它的清理方法如下：

public void flush() {
    try {
        MDC.clear();
    } catch(Exception e) {
        LOGGER.error("Unable to clear context", ex);
    }
}

能看到这个方法在执行，但问题依然存在。于是我在MDC.clear()前加了日志打印：

LOGGER.info("clear(): {}", MDC.getCopyOfContextMap());
MDC.clear();

奇怪的是，现在我完全复现不了问题了，上下文能正常清理了。

核心求助问题 #

想请教各位，有没有可能的原因导致这种偶发失效，添加调试日志后又自动恢复正常的情况？

可能的排查方向分析 #

结合你的场景，我整理了几个大概率的原因，供你参考：

1. Bean实例冲突与竞态条件
   最初你手动封装拦截器的方式，可能导致Spring容器中存在多个LogContextCleaner实例（一个是你配置类注册的，一个是依赖中@Component自动扫描的），实际生效的不是你预期的那个实例，导致清理逻辑没触发。后续移除手动封装后，Bean注册逻辑统一了，但偶发的类加载顺序还是可能引发问题；而添加日志后，代码执行时序发生了微妙变化，暂时规避了竞态条件。

2. 线程池上下文复用问题
   如果你的应用使用了线程池（比如Tomcat工作线程池、异步任务线程池），线程会被复用。偶发情况下，前一个请求的MDC上下文还没来得及清理，线程就被分配给了下一个请求；添加日志打印后，相当于给线程执行增加了一点延迟，让清理逻辑有足够时间在线程复用前完成。

3. 异常吞吃的隐藏问题
   你flush()方法里的异常捕获存在变量拼写错误（catch(Exception e)但日志里用的是ex），这可能导致异常信息根本没被打印出来，你误以为清理逻辑执行了但没生效。偶发情况下MDC.clear()可能抛出了并发异常，但因为异常变量不匹配，日志没输出；添加日志后，可能改变了异常触发的条件，或者日志本身的MDC操作间接修复了上下文状态。

4. 日志框架MDC的实现细节
   比如SLF4J的MDC是基于ThreadLocal实现的，在线程池复用、异步线程切换的场景下，ThreadLocal的清理可能不及时。添加MDC.getCopyOfContextMap()日志时，相当于显式读取了一次上下文，可能触发了MDC内部的状态同步，间接帮助清理逻辑生效。

5. 调试代码的“观测者效应”
   这是开发中很常见的情况：添加调试日志时，代码的执行路径、时序甚至JIT编译的优化策略都会发生变化。比如日志打印操作强制刷新了ThreadLocal的状态，或者改变了代码的执行顺序，原本的偶发问题被暂时掩盖了。

后续排查建议 #

• 检查应用中所有线程池的配置，给线程池添加TaskDecorator，确保线程复用前能正确清理MDC上下文；
• 修正flush()方法里的异常捕获变量（把ex改成e），确保所有异常都能被正确记录；
• 开启日志框架的debug级别日志，观察MDC上下文的实时变化；
• 用压测工具模拟高并发场景，长时间运行应用，偶发问题往往在高负载下更容易复现。

内容来源于stack exchange