Spring Batch报No thread-bound request found异常如何解决

异常根因 #

这个异常的触发逻辑非常明确：

• Spring 会把真实Web请求的上下文对象存在当前处理线程的ThreadLocal中，由DispatcherServlet在请求进入时绑定、请求返回时清理，所有request/session作用域的Bean、依赖请求属性（比如请求头、Cookie、登录态）的组件，都会从这个线程上下文里取数据。
• Spring Batch的定时任务、批处理组件（Reader/Processor/Writer）默认运行在独立的任务线程池中，这些线程从来没有经过DispatcherServlet处理HTTP请求，线程内根本没有绑定请求上下文，一旦调用需要读取请求上下文的组件，就会抛出你看到的异常。

你遇到的第一个接口调用能正常执行，是因为你注入的MyController是单例Bean，被调用的method方法内部没有依赖任何请求上下文内容，本质就是普通的Spring Bean方法调用——和注入Service调用没有区别，根本没走HTTP请求流程，自然不会触发上下文校验。而你在ObjectFactoryImpl里通过ObjectProvider获取的AnotherApi实例是request作用域的代理对象，实例化和方法执行时会主动检查当前线程的请求上下文，所以直接报错。

这里要提一个常见误区：直接注入Controller实例调用方法不属于“调用本项目API”，只是普通的内部方法调用，分层规范上不推荐这么做。

可行解决方案 #

按照生产环境推荐优先级排序：

方案1：分层逻辑重构（首选，无副作用） #

从架构层面彻底规避Web上下文依赖：

• 把Controller中承载的核心业务逻辑全部抽离到独立的单例Service层Bean中，Controller只保留HTTP参数解析、格式校验、调用Service、封装HTTP响应的薄逻辑
• 批处理的Processor、Factory组件直接注入对应的Service单例Bean完成调用，完全不触碰Web层组件、不依赖任何请求上下文
  这个方案是生产环境的标准实践，没有线程安全风险，也不需要额外维护上下文绑定逻辑，性能和稳定性都是最优的。

方案2：手动绑定空请求上下文（适合老代码临时兼容） #

如果短期内无法完成重构，且确认被调用的组件不会实际读取请求里的业务属性（比如不会取请求头的token、不会拿request里存的用户信息），可以在批处理执行逻辑的入口手动给当前线程绑定一个空的请求上下文，执行完成后必须手动清理，避免线程池复用时的上下文污染：

@Override
public List<String> process(@NonNull List<String> objects) throws Exception {
    try {
        // 给当前批处理线程绑定空请求上下文
        RequestContextHolder.setRequestAttributes(new ServletRequestAttributes(new MockHttpServletRequest()));
        // 原有业务逻辑
        objects.forEach(object -> exampleApi.method(object));
        return objects;
    } finally {
        // 必须在finally块中重置上下文，防止内存泄漏和上下文串扰
        RequestContextHolder.resetRequestAttributes();
    }
}

注意：如果被调用的方法实际需要读取请求中的业务数据，这个方案会导致业务逻辑错误，禁止在这类场景使用。

方案3：调整Bean作用域配置 #

如果anotherService本身不需要依赖请求上下文，只是错误配置成了request作用域，直接将其作用域修改为默认的singleton单例模式，就不会再触发请求上下文检查。

额外提醒：不要在批处理任务中通过HTTP客户端调用本项目的Controller接口，这种方式会额外经过网络IO、序列化、过滤器链、权限校验等流程，性能差还容易出现超时、事务不一致的问题，内部逻辑直接调用本地Bean是最优选择。

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