多并发请求下log4j ThreadContext存储值是否会相互覆盖？

正常情况下不会出现跨请求的correlationId覆盖问题，但现有实现存在上下文残留、异步场景丢值/串值的隐患，极端情况会导致日志打印错误的链路ID。
原理说明：Log4j2的ThreadContext（对应SLF4J规范中的MDC）默认基于ThreadLocal实现，每个线程持有独立的上下文副本，不同线程的上下文值天然隔离。Spring MVC场景下，Servlet容器（如Tomcat）会从工作线程池分配独立线程处理每个并发请求，只要请求全程在同一个线程内执行，不同请求写入的correlationId不会互相覆盖。

• 空值风险：如果请求头未携带correlationId，直接将null写入ThreadContext，部分Log4j2版本会触发空指针异常，且无correlationId的请求无法关联链路。
• 上下文残留风险：Tomcat等容器是复用工作线程的，如果请求被拦截器链提前中断（比如前置拦截器返回false未走到当前拦截器的afterCompletion）、或者请求处理中抛出未捕获的极端错误导致清理逻辑未执行，ThreadLocal中残留的correlationId会随着线程归还给池，下一个复用该线程的请求如果未成功写入新的correlationId，就会打印旧的链路ID。
• 误删上下文风险：直接调用ThreadContext.clearMap()会清空当前线程所有的ThreadContext键值对，包括其他框架、业务层提前写入的公共上下文参数，造成非预期的上下文丢失。
• 异步场景串值/丢值：如果请求处理过程中使用了@Async、手动提交线程池任务、CompletableFuture等异步逻辑，子线程默认无法获取父线程的ThreadContext值，会出现异步日志无correlationId的问题；如果线程池配置了可继承的ThreadLocal，又会因为线程复用出现子线程拿到旧correlationId的串值问题。

1. 修正拦截器逻辑 #

public class RequestHandlerInterceptor implements HandlerInterceptor {
    private static final String CORRELATION_ID = "correlationId";
    private static final String CORRELATION_ID_HEADER = "X-Correlation-Id";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 优先从请求头获取链路ID，不存在则自动生成全局唯一ID
        String correlationId = request.getHeader(CORRELATION_ID_HEADER);
        if (correlationId == null || correlationId.isBlank()) {
            correlationId = UUID.randomUUID().toString().replace("-", "");
        }
        ThreadContext.put(CORRELATION_ID, correlationId);
        // 将链路ID写入响应头，方便调用方对齐链路
        response.setHeader(CORRELATION_ID_HEADER, correlationId);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 仅清理当前拦截器写入的键值，避免误删其他上下文
        ThreadContext.remove(CORRELATION_ID);
    }
}

2. 异步场景适配 #

• 针对@Async场景，自定义任务装饰器，在任务提交时取出当前线程的correlationId，任务执行前写入子线程的ThreadContext，任务执行完成后在finally块中调用ThreadContext.remove()清理，避免线程池复用导致串值。
• 针对手动提交线程池、CompletableFuture的场景，提交任务前先获取当前线程的correlationId，在任务的执行逻辑开头写入ThreadContext，finally块中做清理。
• 如果使用Log4j2，可开启isThreadContextMapInheritable=true配置支持父子线程上下文传递，但必须搭配任务执行后的清理逻辑，禁止仅依赖可继承ThreadLocal传递上下文，否则池化线程复用时必然出现旧值残留问题。

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