Dropwizard服务SLF4J MDC异常：service2上下文返回null原因咨询

碰到过类似的场景，给你梳理几个最可能导致这个问题的点，都是Dropwizard+MDC组合里常见的坑：

• 异步线程未传递MDC上下文
  MDC是完全绑定到当前线程的，如果service2采用了异步处理逻辑（比如用了JAX-RS的AsyncResponse，或者内部调用了CompletableFuture、线程池异步执行func()），默认情况下异步线程不会自动继承父线程的MDC数据。你在service2的请求线程里设置了MDC，但如果func()的执行或者日志缓冲的处理跑到了另一个线程，那个线程没有MDC上下文，自然返回null。而service1如果是同步处理，整个流程都在同一个请求线程内，MDC上下文全程有效。

• Dropwizard框架的隐式MDC清理
  Dropwizard自带的请求处理过滤器（比如LoggingFilter）会在请求结束后自动清理MDC——这是框架的默认行为，哪怕你没手动调用MDC.clear()。如果service2的日志缓冲追加器是异步工作的（比如日志先存到队列，后台线程再处理），等缓冲器去读取MDC的时候，请求线程已经结束，MDC已经被框架清掉了；而service1的日志是在请求处理过程中同步输出，这时候MDC还没被清理，所以能正常获取。

• MDC设置时机或范围错误
  检查下service2里设置MDC的代码是不是在调用func()之前就执行了？有没有可能这段代码被放在了某个条件分支里（比如只有特定请求参数才触发），导致实际没设置上MDC？另外，如果service2用了自定义线程池，线程复用的时候，之前的MDC残留或者新请求的MDC没在新线程里重新设置，也会出现null的情况。

• 线程池复用导致的上下文异常
  如果service2使用了自定义线程池处理请求，线程池里的线程被复用时，若上一个请求的MDC没被彻底清理（或者框架没正确覆盖），而当前请求的MDC又没在新线程中重新初始化，就会出现MDC为null的情况。而service1如果用的是Dropwizard默认的线程模型，每个请求对应独立的线程上下文，就不会有这个问题。

可以通过这几个步骤快速定位问题：

1. 在service2调用func()的前后，打印当前线程ID和MDC的具体值，确认在请求线程内部MDC是存在的；
2. 查看日志缓冲追加器的配置，确认是否为异步模式，如果是，检查是否配置了MDC上下文传递的逻辑；
3. 临时把service2改成同步处理，看看MDC能不能被缓冲追加器正常获取，排除异步的影响；
4. 检查Dropwizard的配置文件，有没有自定义的请求过滤器干扰了MDC的生命周期。

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