spring bean 中注入 HttpServletRequest 成员变量的思考

主题

在使用 spring 框架开发的时候，我们经常会碰到这种情况：

@Controller
public class SomeController {

    @RequestMapping("/test1")
    public String test1(HttpServletRequest request) {
        System.out.println(request.getQueryString());
        return "";
    }

    @RequestMapping("/test2")
    public String test2(HttpServletRequest request) {
        System.out.println(request.getQueryString());
        return "";
    }

    @RequestMapping("/test3")
    public String test3(HttpServletRequest request) {
        System.out.println(request.getQueryString());
        return "";
    }

}

         即，一个 @Controller 或 @Service 中的多个方法都使用到了 request 这个参数，那么为了简化代码，我们会将 request 作为成员变量注入，改写成如下形式：

@Controller
public class SomeController {

    @Resource
    private HttpServletRequest request;

    @RequestMapping("/test1")
    public String test1() {
        System.out.println(request.getQueryString());
        return "";
    }

    @RequestMapping("/test2")
    public String test2() {
        System.out.println(request.getQueryString());
        return "";
    }

    @RequestMapping("/test3")
    public String test3() {
        System.out.println(request.getQueryString());
        return "";
    }

}

        这样，我们就可以不必在每个用到 request 的方法的参数列表都写一遍HttpServletRequest request这个参数了。工作中也经常是这样做的。

思考

但是，仔细思考一下，我们会有这样的疑问：

• spring 中 @Controller 默认是单例的，其成员变量也是在 bean 初始化时注入好的，而 HttpServletRequest 这个变量对于每一次请求都是不同的，难道 @Controller 对每次请求都重新注入 request 这个成员变量？ 且不说这种做法不符合 spring 对 bean 管理的一般方式，即使这样做了，线程安全如何保证？

实现

先上结论，上面的写法，每次都可以取到正确的 request 对象，并且是线程安全的。

那么，spring 是如何做到的呢？

首先 debug 看下两种做法真实注入类的区别：

区别很明显——

• 作为成员变量注入的时候注入的是代理对象，是 AutowireUtils.ObjectFactoryDelegatingInvocationHandler 的实例。

• 作为方法参数注入的就是我们一般使用的 Request 对象。

看下 ObjectFactoryDelegatingInvocationHandler 这个 AutowireUtils 的内部类：

 /**
	 * Reflective InvocationHandler for lazy access to the current target object.
	 */
	@SuppressWarnings("serial")
	private static class ObjectFactoryDelegatingInvocationHandler implements InvocationHandler, Serializable {

		private final ObjectFactory<?> objectFactory;

		public ObjectFactoryDelegatingInvocationHandler(ObjectFactory<?> objectFactory) {
			this.objectFactory = objectFactory;
		}

		@Override
		public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
			String methodName = method.getName();
			if (methodName.equals("equals")) {
				// Only consider equal when proxies are identical.
				return (proxy == args[0]);
			}
			else if (methodName.equals("hashCode")) {
				// Use hashCode of proxy.
				return System.identityHashCode(proxy);
			}
			else if (methodName.equals("toString")) {
				return this.objectFactory.toString();
			}
			try {
				return method.invoke(this.objectFactory.getObject(), args);
			}
			catch (InvocationTargetException ex) {
				throw ex.getTargetException();
			}
		}
	}

可以看到，当代理对象的方法被调用时，除去少数几个方法，大部分的情况都是通过this.objectFactory.getObject() 获取被代理对象，再调用被代理对象的相应方法

通过一步步 debug，最终终于看到了熟悉的 Request 类，可以看到它是从requestAttributesHolder中取到的，那么 requestAttributesHolder 又是什么呢？

看到这里答案已经很明了了，这个 RequestContextHolder 的ThreadLocal 成员变量就是实现的关键所在，它存放了每个线程对应的 Request 对象，因此在 @Controller 中调用作为成员变量注入的代理类的方法时，最终可以取到当前线程相对应的 Request 对象，并调用Request 对应的方法，这样 @Controller 中的成员变量不需要重复注入（它一直都是最初 bean 初始化时注入的代理类），也避免了线程不安全的问题。

---

那么 spring 是何时将 Request 放入这个 ThreadLocal 之中的呢？

是在 Springmvc 的 dispatcherServlet 的父类 FrameworkServlet 里操作的：

可以看到对 Servlet 的 doGet、dePost 等各种调用，最终都通过processRequest(request, response) 处理

该方法调用了initContextHolders(request, localeContext, requestAttributes);

最终看到了将 Request 放入 ThreadLocal 的操作。

总结

1. 在 bean 中注入作为成员变量的 HttpServletRequest 时，实际注入的是 spring 框架生成的代理对象，是ObjectFactoryDelegatingInvocationHandler的实例。在我们调用这个成员变量的方法时，最终是调用了 objectFactory 的 getObject() 对象的对应方法，在这里 objectFactory 是RequestObjectFactory这个类的对象。
2. RequestObjectFactory 的 getObject 方法是从RequestContextHolder的threadlocal中去取值的。
3. 请求刚进入 springmvc 的dispatcherServlet的时候会把 request 相关对象设置到 RequestContextHolder 的 threadlocal 中去.

补充：

其实类似和 dubbo 的 RpcContext 一样的道理通过 ThreadLocal 这种临时状态变量记录