Spring Boot多线程任务中RequestContextHolder丢失问题解决 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Spring Boot 多线程任务中 RequestContextHolder 丢失问题解决

大家好，今天我们来聊聊Spring Boot多线程环境下一个常见但比较棘手的问题：RequestContextHolder丢失。很多开发者在使用异步任务或者线程池处理请求时，会发现原本在Controller层可用的RequestContextHolder，在子线程中却无法访问，导致获取不到诸如用户身份信息、请求头等数据，进而引发各种bug。

问题背景：RequestContextHolder的工作原理

首先，我们要理解RequestContextHolder的工作机制。它是Spring提供的一个用于存储请求上下文信息的类，主要通过ThreadLocal来实现线程隔离。

ThreadLocal: ThreadLocal为每个线程提供了一个独立的变量副本，线程之间互不干扰。这意味着，父线程设置的ThreadLocal变量，默认情况下子线程是无法访问的。
RequestContext: 在Web请求处理过程中，Spring的DispatcherServlet会在请求开始时将请求相关信息，如HttpServletRequest、HttpServletResponse等，封装到RequestContext对象中，并将其绑定到当前线程的RequestContextHolder。

因此，在单线程的Web请求处理过程中，我们可以通过RequestContextHolder.getRequestAttributes()来获取RequestContext，进而访问HttpServletRequest等对象。

问题重现：多线程环境下的RequestContextHolder失效

当我们使用@Async注解或者手动创建线程池来执行异步任务时，问题就出现了。因为子线程和父线程是不同的线程，它们拥有各自独立的ThreadLocal副本。因此，父线程中绑定的RequestContext在子线程中自然是不可见的。

以下面的代码为例：

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/async")
    public String asyncTask() {
        // 在Controller层获取用户信息
        String username = (String) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        System.out.println("Controller - Username: " + username);

        myService.asyncMethod();
        return "Async task started";
    }
}

@Service
public class MyService {

    @Async
    public void asyncMethod() {
        // 尝试在异步方法中获取用户信息
        try {
            String username = (String) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
            System.out.println("AsyncMethod - Username: " + username);
        } catch (Exception e) {
            System.out.println("AsyncMethod - Username: NullPointerException or similar");
            e.printStackTrace();
        }

        try {
            ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
            HttpServletRequest request = attributes.getRequest();
            String header = request.getHeader("X-Custom-Header");
            System.out.println("AsyncMethod - Header: " + header);
        } catch (Exception e) {
            System.out.println("AsyncMethod - Header: NullPointerException or similar");
            e.printStackTrace();
        }
    }
}

在这个例子中，MyController的asyncTask方法调用了MyService的asyncMethod方法，后者被@Async注解修饰，将在一个独立的线程中执行。如果在asyncMethod中尝试获取用户信息或者请求头，很可能会出现NullPointerException，因为RequestContextHolder为空。

解决方案：传递RequestContext

解决这个问题，核心思路是将父线程的RequestContext传递到子线程。有以下几种常用的解决方案：

手动传递RequestContext:

这是最直接的方式。在父线程中获取RequestContext，然后将其作为参数传递给子线程。

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/async")
    public String asyncTask() {
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
        String username = (String) SecurityContextHolder.getContext().getAuthentication().getPrincipal();

        myService.asyncMethod(attributes, username);
        return "Async task started";
    }
}

@Service
public class MyService {

    @Async
    public void asyncMethod(RequestAttributes attributes, String username) {
        RequestContextHolder.setRequestAttributes(attributes);
        SecurityContextHolder.getContext().setAuthentication(SecurityContextHolder.getContext().getAuthentication()); // 确保SecurityContext传递

        try {
            System.out.println("AsyncMethod - Username: " + username);
        } catch (Exception e) {
            System.out.println("AsyncMethod - Username: NullPointerException or similar");
            e.printStackTrace();
        }

        try {
            ServletRequestAttributes servletRequestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
            HttpServletRequest request = servletRequestAttributes.getRequest();
            String header = request.getHeader("X-Custom-Header");
            System.out.println("AsyncMethod - Header: " + header);
        } catch (Exception e) {
            System.out.println("AsyncMethod - Header: NullPointerException or similar");
            e.printStackTrace();
        } finally {
            RequestContextHolder.resetRequestAttributes(); // 清理，避免内存泄漏
        }
    }
}

这种方式的优点是简单明了，缺点是需要在每个需要访问RequestContext的异步方法中都进行参数传递和设置，代码冗余。同时需要手动清理RequestContextHolder，避免内存泄漏。

使用InheritableThreadLocal：

InheritableThreadLocal是ThreadLocal的一个子类，它允许子线程继承父线程的ThreadLocal变量。

修改RequestContextHolder的实现，使其使用InheritableThreadLocal：

public final class RequestContextHolder {

    private static final ThreadLocal<RequestAttributes> requestAttributesHolder =
            new InheritableThreadLocal<>();

    // ... 其他方法不变
}

这种方式的优点是方便，不需要手动传递RequestContext。缺点是全局性的，所有子线程都会继承父线程的RequestContext，可能导致数据污染。此外，使用InheritableThreadLocal会增加内存消耗，因为每个线程都会持有一份RequestContext的副本。

注意： 强烈不推荐直接修改 Spring 源码中的 RequestContextHolder 类。这种方式虽然简单，但会带来不可预测的风险，升级 Spring 版本时可能会遇到兼容性问题。更好的做法是自定义一个类似的 ContextHolder ，并使用 InheritableThreadLocal 。

public final class MyContextHolder {

    private static final ThreadLocal<MyContext> myContextHolder = new InheritableThreadLocal<>();

    public static void setContext(MyContext context) {
        myContextHolder.set(context);
    }

    public static MyContext getContext() {
        return myContextHolder.get();
    }

    public static void clearContext() {
        myContextHolder.remove();
    }
}

public class MyContext {
    private String username;
    private String requestId; // 从 HttpServletRequest 中获取

    // Getter and Setter
}

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/async")
    public String asyncTask(HttpServletRequest request) {
        String username = (String) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        String requestId = request.getHeader("X-Request-Id");

        MyContext context = new MyContext();
        context.setUsername(username);
        context.setRequestId(requestId);

        MyContextHolder.setContext(context);

        myService.asyncMethod();
        return "Async task started";
    }
}

 @Service
public class MyService {

    @Async
    public void asyncMethod() {
        try {
            MyContext context = MyContextHolder.getContext();
            String username = context.getUsername();
            String requestId = context.getRequestId();
            System.out.println("AsyncMethod - Username: " + username + ", RequestId: " + requestId);
        } catch (Exception e) {
            System.out.println("AsyncMethod - Error getting context");
            e.printStackTrace();
        } finally {
            MyContextHolder.clearContext(); // 清理
        }
    }
}

使用TaskDecorator：

TaskDecorator是Spring提供的用于装饰Runnable对象的接口，可以在Runnable执行前后进行一些操作。我们可以通过TaskDecorator来将父线程的RequestContext复制到子线程。

首先，创建一个TaskDecorator的实现类：

import org.springframework.core.task.TaskDecorator;
import org.springframework.web.context.request.RequestAttributes;
import org.springframework.web.context.request.RequestContextHolder;

public class ContextCopyingDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        RequestAttributes context = RequestContextHolder.getRequestAttributes();
        return () -> {
            try {
                RequestContextHolder.setRequestAttributes(context);
                runnable.run();
            } finally {
                RequestContextHolder.resetRequestAttributes(); //清理
            }
        };
    }
}

然后，在配置线程池时，将TaskDecorator设置到ThreadPoolTaskExecutor中：

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(25);
        executor.setThreadNamePrefix("MyAsync-");
        executor.setTaskDecorator(new ContextCopyingDecorator()); // 设置TaskDecorator
        executor.initialize();
        return executor;
    }

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return new SimpleAsyncUncaughtExceptionHandler();
    }
}

这种方式的优点是集中管理RequestContext的传递，不需要在每个异步方法中都进行处理。缺点是需要配置线程池，并且如果使用默认的线程池，则无法使用。

使用CompletableFuture配合ThreadContext (Log4j2):

如果你的应用使用了Log4j2，可以使用其提供的ThreadContext类来传递上下文信息。结合CompletableFuture，可以方便地在异步任务中访问这些信息。

首先，在父线程中将需要传递的信息放入ThreadContext：

import org.apache.logging.log4j.ThreadContext;

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/async")
    public String asyncTask() {
        String username = (String) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        ThreadContext.put("username", username); // 将用户信息放入ThreadContext

        myService.asyncMethod();
        return "Async task started";
    }
}

然后，在子线程中使用CompletableFuture获取并访问ThreadContext中的信息：

import org.apache.logging.log4j.ThreadContext;
import java.util.concurrent.CompletableFuture;

@Service
public class MyService {

    @Async
    public void asyncMethod() {
        CompletableFuture.supplyAsync(() -> ThreadContext.get("username"))
                .thenAccept(username -> {
                    System.out.println("AsyncMethod - Username: " + username);
                    ThreadContext.remove("username"); // 清理
                });
    }
}

这种方式的优点是可以传递任意类型的信息，并且不需要修改RequestContextHolder。缺点是依赖于Log4j2，并且需要使用CompletableFuture。

几种方案对比:

方案	优点	缺点	适用场景
手动传递RequestContext	简单明了，易于理解。	代码冗余，需要在每个异步方法中都进行处理。需要手动清理RequestContextHolder。	异步方法数量较少，对性能要求不高的场景。
使用InheritableThreadLocal	方便，不需要手动传递RequestContext。	全局性的，所有子线程都会继承父线程的RequestContext，可能导致数据污染。增加内存消耗。不推荐直接修改 Spring 源码。	不推荐使用，除非你能确保子线程不会修改RequestContext，并且内存消耗可以接受。
使用TaskDecorator	集中管理RequestContext的传递，不需要在每个异步方法中都进行处理。	需要配置线程池，并且如果使用默认的线程池，则无法使用。	异步任务较多，需要统一管理RequestContext传递的场景。
CompletableFuture+ThreadContext (Log4j2)	可以传递任意类型的信息，并且不需要修改RequestContextHolder。	依赖于Log4j2，并且需要使用CompletableFuture。	应用已经使用了Log4j2，并且需要传递任意类型的信息的场景。

最佳实践：

选择哪种方案取决于你的具体需求和项目架构。一般来说，推荐使用TaskDecorator或者CompletableFuture配合ThreadContext，因为它们可以更好地控制RequestContext的传递，并且避免了全局性的数据污染。

注意事项：

内存泄漏： 在使用完RequestContextHolder后，一定要及时清理，避免内存泄漏。可以使用RequestContextHolder.resetRequestAttributes()方法来清理。
数据污染： 在使用InheritableThreadLocal时，要特别注意数据污染的问题。如果子线程修改了RequestContext，可能会影响到其他线程。
SecurityContext: 如果你的应用使用了Spring Security，还需要确保SecurityContext也能够正确传递到子线程。可以使用SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)来设置SecurityContextHolder的策略，使其使用InheritableThreadLocal。但是同样需要注意数据污染的问题。更好的做法是手动传递 Authentication 对象或者使用 Spring Security 提供的 SecurityContextCallable 或 SecurityContextRunnable。

总结：确保请求上下文在多线程环境中的延续

Spring Boot多线程任务中RequestContextHolder丢失是一个常见的问题，但通过理解其工作原理，并选择合适的解决方案，可以有效地解决这个问题。记住，核心在于将父线程的RequestContext传递到子线程，并且在使用完后及时清理，避免内存泄漏。选择哪种方案取决于你的具体需求和项目架构，但TaskDecorator和CompletableFuture配合ThreadContext通常是更安全和灵活的选择。

确保SecurityContext的正确传递

在多线程环境中，不仅要关注RequestContextHolder的传递，也要确保SecurityContext能够正确地传递到子线程，避免用户身份验证信息的丢失。

内存管理是关键

无论是哪种解决方案，都必须注意内存管理，避免在多线程环境中出现内存泄漏问题，确保程序的稳定性和性能。

Spring Boot 多线程任务中 RequestContextHolder 丢失问题解决

发表回复 取消回复

发表回复取消回复