RequestObjectFactory
至于为何使用的是这个Factory来处理，请参考web容器初始化时的这块代码：
WebApplicationContextUtils： public static void registerWebApplicationScopes(ConfigurableListableBeanFactory beanFactory, @Nullable ServletContext sc) { // web容器下新增支持了三种scope // 非web容器（默认）只有单例和多例两种嘛 beanFactory.registerScope(WebApplicationContext.SCOPE_REQUEST, new RequestScope()); beanFactory.registerScope(WebApplicationContext.SCOPE_SESSION, new SessionScope()); if (sc != null) { ServletContextScope appScope = new ServletContextScope(sc); beanFactory.registerScope(WebApplicationContext.SCOPE_APPLICATION, appScope); sc.setAttribute(ServletContextScope.class.getName(), appScope); // ==================依赖注入================= // 这里决定了，若你依赖注入ServletRequest的话，就使用RequestObjectFactory来处理你 beanFactory.registerResolvableDependency(ServletRequest.class, new RequestObjectFactory()); beanFactory.registerResolvableDependency(ServletResponse.class, new ResponseObjectFactory()); beanFactory.registerResolvableDependency(HttpSession.class, new SessionObjectFactory()); beanFactory.registerResolvableDependency(WebRequest.class, new WebRequestObjectFactory()); } }
RequestObjectFactory自己的代码非常非常简单：
WebApplicationContextUtils： private static class RequestObjectFactory implements ObjectFactory<ServletRequest>, Serializable { // 从当前请求上下文里找到Request对象 @Override public ServletRequest getObject() { return currentRequestAttributes().getRequest(); } ... } // 从当前请求上下文：RequestContextHolder里找到请求属性，进而就可以拿到请求对象、响应对象等等了 private static ServletRequestAttributes currentRequestAttributes() { RequestAttributes requestAttr = RequestContextHolder.currentRequestAttributes(); if (!(requestAttr instanceof ServletRequestAttributes)) { throw new IllegalStateException("Current request is not a servlet request"); } return (ServletRequestAttributes) requestAttr; }
到这个节点可以知道，关键点就在于：RequestContextHolder.currentRequestAttributes()的值哪儿来的，或者说是什么时候放进去的，放了什么进去？
Spring何时把Request信息放进RequestContextHolder？
首先必须清楚：RequestContextHolder它代表着请求上下文，内部使用ThreadLocal来维护着，用于在线程间传递RequestAttributes数据。
// 它是个工具类：用抽象类表示而已 所有方法均静态 public abstract class RequestContextHolder { private static final ThreadLocal<RequestAttributes> requestAttributesHolder = new NamedThreadLocal<>("Request attributes"); private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder = new NamedInheritableThreadLocal<>("Request context"); ... // 省略set、get、reset等方法 }
说明：关于ThreadLocal的使用，以及误区什么的，请务必参阅此文：ThreadLocal能解决线程安全问题？胡扯！本文教你正确的使用姿势
需要说明的是：Spring此处使用了InheritableThreadLocal用于传递，所以即使你在子线程里也是可以通过上下文RequestContextHolder获取到RequestAttributes数据的。
要想找到何时向RequestContextHolder里放值的，仅需知道何时调用的set方法便可（它有两个set方法，其中一个set方法仅在RequestContextListener里被调用，可忽略）：
RequestContextFilter
该过滤器RequestContextFilter主要是用于第三方serlvet比如JSF FacesServlet。在Spring自己的Web应用中，如果一个请求最终被DispatcherServlet处理，它自己完成请求上下文的维护（比如对RequestContextHolder的维护）。
但是，并不是所有的请求都最终会被DispatcherServlet处理，比如匿名用户访问一个登录用户才能访问的资源，此时请求只会被安全过滤器（如TokenFilter）处理，而不会到达DispatcherServlet，在这种情况下，该过滤器RequestContextFilter就起了担当了相应的职责。
RequestContextFilter负责LocaleContextHolder和RequestContextHolder，而在过滤器内部很轻松的可以拿到HttpServletRequest，所以在不继承第三方Servlet技术的情况下，此Filter几乎用不着~
FrameworkServlet
“排除”上面一种设置的机会，只剩下FrameworkServlet了。它的initContextHolders()方法和resetContextHolders()方法均会维护请求上下文：
FrameworkServlet： // 处理请求的方法 protected final void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { ... ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes); ... initContextHolders(request, localeContext, requestAttributes); try { // 抽象方法：交给DispatcherServlet去实现 doService(request, response); } catch { ... } finally { resetContextHolders(request, previousLocaleContext, previousAttributes); ... } } private void initContextHolders(...) { ... RequestContextHolder.setRequestAttributes(requestAttributes, this.threadContextInheritable); }
说明：initContextHolders的另外一处调用处在RequestBindingInterceptor里，在Async异步支持时用于绑定的，略。
由此可见，只要请求交给了FrameworkServlet处理，那么请求上下文里就必然有Request/Response等实例，并且是和每个请求线程绑定的（独享）。而我们绝大多数情况下都是在Controller或者后续流程中希望得到HttpServletRequest，那时请求上下文就已经把其和当先线程绑定好啦~
依赖注入【确定安全】流程总结
经过这一波分析，通过@Autowired方式依赖注入得到HttpServletRequest是线程安全的结论是显而易见的了：通过JDK动态代理，每次方法调用实际调用的是实际请求对象HttpServletRequest。先对它的关键流程步骤总结如下：
- 在Spring解析HttpServletRequest类型的@Autowired依赖注入时，实际注入的是个JDK动态代理对象
- 该代理对象的处理器是：ObjectFactoryDelegatingInvocationHandler，内部实际实例由ObjectFactory动态提供，数据由RequestContextHolder请求上下文提供，请求上下文的数据在请求达到时被赋值，参照下面步骤
- 该ObjectFactory是一个RequestObjectFactory（这是由web上下文初始化时决定的）
- 请求进入时，单反只要经过了FrameworkServlet处理，便会在处理时（调用Controller目标方法前）把Request相关对象设置到RequestContextHolder的ThreadLocal中去
- 这样便完成了：调用Controller目标方法前完成了Request对象和线程的绑定，所以在目标方法里，自然就可以通过当前线程把它拿出来喽，这一切都拜托的是ThreadLocal去完成的~
值得注意的是：若有不经过FrameworkServlet的请求（比如被过滤器过滤了，Spring MVC拦截器不行的哦它还是会经过FrameworkServlet处理的），但却又想这么使用，那么请主动配置RequestContextFilter这个过滤器来达到目的吧。
谨防线程池里使用HttpServletRequest的坑
源码也已经分析了，Spring的RequestContextHolder使用的InheritableThreadLocal，所以最多支持到父线程向子线程的数据传递，因此若你这么使用：
@Autowired HttpServletRequest requestAuto; @GetMapping("/test/request") public Object testRequest() { new Thread(() -> { String name = requestAuto.getParameter("name"); System.out.println(name); }).start(); return "success"; }
是可以正常work的，但若你放在线程池里面执行，形如这样：
private static final ExecutorService THREAD_POOL = Executors.newFixedThreadPool(10); @Autowired HttpServletRequest requestAuto; @GetMapping("/test/request") public Object testRequest() { THREAD_POOL.execute(() -> { String name = requestAuto.getParameter("name"); System.out.println(name); }); return "success"; }
那是会出问题的，不能正常work。究其原因是@Autowire注入进来的实际使用的Request对象获取使用的是RequestContextHolder，而它最多只支持向子线程传递数据，不支持线程池。
说明：只有@Autowired进来的，或者自己在线程池内手动通过RequestContextHolder获取才有问题哦，HttpServletRequest通过请求参数进来的是木有问题哒~
至于底层原因，请参考文章：ThreadLocal垮线程池传递数据解决方案：TransmittableThreadLocal
总结
该文讲述的内容虽然并不难，但我认为还是比较“时髦”的，相信能给到很多人予以帮助，那就足够了。
最后提示一小点：有人留言我说可以使用RequestContextListener这个监听器，它也能给RequestContext赋值完成绑定。答案是可以的，因为它是一个源生的Servlet请求监听器：javax.servlet.ServletRequestListener可以监听到每个请求，RequestContextListener是Spring给出的监听器实现，因此只要你在xml里配置上它/or @Bean的方式也是可行的，只是上面已经说了，绝大部分情况下并不需自己麻烦自己的这么做
