请求完成后请求作用域延续及异步线程注入请求域变量方案咨询

我之前在做高并发微服务的时候碰到过一模一样的问题——请求结束后异步任务要拿请求域的变量，简直头疼。核心思路其实很简单：在请求还活着的时候把需要的上下文抓出来，传给异步任务，而不是等请求死了再去“注入”。下面几个方案都是我实际用过的，按落地成本和适用场景给你列出来：

方案1：请求结束前主动捕获上下文并传递（最推荐） #

这是性能损耗最小、最直接的方案，完全符合你耗时<10ms的要求。在请求处理的收尾阶段（比如过滤器后置逻辑、业务方法的最后步骤），把需要的请求域变量（比如用户ID、追踪ID、租户信息这类轻量数据）提取出来，封装成普通POJO或者Map，直接作为参数传给异步任务。

示例伪代码：

// 请求处理流程中，准备提交异步任务时
RequestContext reqCtx = RequestContextHolder.getRequestAttributes();
// 只提取需要的变量，别传整个请求对象
String userId = reqCtx.getAttribute("userId", RequestAttributes.SCOPE_REQUEST);
String traceId = reqCtx.getAttribute("traceId", RequestAttributes.SCOPE_REQUEST);

AsyncTaskContext asyncCtx = new AsyncTaskContext(userId, traceId);

// 提交到线程池，直接传递上下文
executorService.submit(() -> {
    // 异步任务里直接用封装好的上下文
    executeHeavyTask(asyncCtx.getUserId(), asyncCtx.getTraceId());
});

• 优点：零额外框架依赖，性能开销可以忽略（就是几个变量的拷贝），彻底避开请求作用域生命周期问题。
• 注意：只捕获必要的变量，别传递大对象或整个请求实例，防止内存泄漏。

方案2：自定义线程本地变量桥接上下文 #

如果你的项目已经大量使用@Async这类注解式异步任务，不想逐个修改任务参数，可以在请求作用域内把上下文复制到自定义的ThreadLocal中，异步任务执行时读取，执行完必须清理。

示例代码：

// 自定义上下文持有者
public class AsyncContextHolder {
    private static final ThreadLocal<AsyncTaskContext> CONTEXT = new ThreadLocal<>();

    public static void setContext(AsyncTaskContext ctx) {
        CONTEXT.set(ctx);
    }

    public static AsyncTaskContext getContext() {
        return CONTEXT.get();
    }

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

// 请求处理时复制上下文
RequestContext reqCtx = RequestContextHolder.getRequestAttributes();
AsyncTaskContext asyncCtx = new AsyncTaskContext(
    reqCtx.getAttribute("userId", RequestAttributes.SCOPE_REQUEST),
    reqCtx.getAttribute("traceId", RequestAttributes.SCOPE_REQUEST)
);
AsyncContextHolder.setContext(asyncCtx);

// 提交@Async任务
asyncService.runHeavyTask();

// 异步任务方法
@Async
public void runHeavyTask() {
    try {
        AsyncTaskContext ctx = AsyncContextHolder.getContext();
        executeHeavyTask(ctx.getUserId(), ctx.getTraceId());
    } finally {
        // 必须清理！否则线程池复用会导致上下文污染
        AsyncContextHolder.clearContext();
    }
}

• 优点：对现有业务代码侵入极小，不用修改任务参数列表。
• 注意：一定要在finally块中清理ThreadLocal，不然线程池里的线程会带着旧上下文乱跑，导致数据错乱。

方案3：扩展线程池的任务包装器 #

如果用的是自定义线程池（比如Spring的ThreadPoolTaskExecutor），可以实现一个TaskDecorator，在提交任务时自动捕获当前请求上下文，包装到任务里，异步执行时再临时恢复上下文。

示例代码：

// 自定义请求上下文包装器
public class RequestContextDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        // 捕获当前请求上下文（此时请求还未结束）
        RequestAttributes attributes = RequestContextHolder.getRequestAttributes();
        return () -> {
            try {
                // 异步任务执行前恢复上下文
                RequestContextHolder.setRequestAttributes(attributes);
                runnable.run();
            } finally {
                // 执行完清理上下文
                RequestContextHolder.resetRequestAttributes();
            }
        };
    }
}

// 配置线程池时添加包装器
@Bean
public Executor asyncExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(10);
    executor.setMaxPoolSize(20);
    executor.setQueueCapacity(100);
    executor.setThreadNamePrefix("Async-Worker-");
    // 绑定自定义包装器
    executor.setTaskDecorator(new RequestContextDecorator());
    executor.initialize();
    return executor;
}

• 优点：对业务代码完全透明，不需要改任何任务逻辑，适合批量迁移现有异步任务的场景。
• 注意：依赖Spring的RequestContextHolder，如果是自定义请求作用域，需要适配对应的上下文持有类；另外别在上下文里放非线程安全的对象，否则异步线程里可能出问题。

最后再强调一遍核心原则：永远不要在请求作用域结束后试图访问它的变量，一定要在请求生命周期内把需要的上下文“快照”下来，传递给异步任务。上面三个方案的性能开销都远低于10ms，完全满足你的要求。

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