问题

当我们第一次接触到 Java Web 开发，从最原生的 Servlet 方法开始，我们就知道在 doGet() 或者 doPost() 方法有两个形参，分别是 HttpServletRequest 和 HttpServletResponse，这两个参数代表了 web 容器为我们封装的 HTTP 请求和 HTTP 响应。

当 Java Web 进化到 SpringMVC 中，一系列的杂活脏活都交给了 DispatcherServlet 前端控制器来处理。

回到正文，传统情况下，我们访问一个接口，想要从中取得 request 对象，或者是 response 对象，亦或者是 httpSession 对象，都是直接作为形参传进来。举个例子，前端传递 token，先经过 filter 得到用户ID，并将它存入 request 中，那么在每个接口中取得用户ID，都要这样：

@GetMapping(/"test")
public ResponseResult test(HttpServletRequest request, HttpServletResponse response) {
    Object userId = request.getAttribute("userId");
    ...
}

每个接口都要加 HttpServletRequest 或者 HttpServletResponse，第一写起来麻烦，第二看起来参数也很多。那么既然 Spring 可以依赖注入，我们可不可以这样做呢：

@RestController
public class DemoController {
    @Autowired
    private HttpServletRequest request;
    @Autowired
    private HttpServletResponse response;

    @GetMapping("/test")
    public ResponseResult test() {
        Object userId = request.getAttribute("userId");
        ...
    }
}

可以.

既然我可以将它 Autowired 出来，那么它是啥时候被注入的呢？
我们知道 Spring 容器中的 Bean 默认是单例的，那么这样得到的 request 会不会有问题？并发情况下，一个接口会不会取到另一个接口的 request？

结论

1. 啥时候注入的？

答：SpringMVC DispatcherServlet 每次处理 HTTP 请求时，会将 web 容器封装的 request 和 response 注入到 Spring 容器中。

2. 这样在并发情况下会不会有问题？

答：不会有问题。内部其实存在一个 ThreadLocal ，不同进程的 request 和 response 是隔离的。

3. 那我们以后是不是可以都这样写了？

答：理论上且实际上这样写都没有问题，但是一般认为接口形参上的 request 和 response 对应着一次 HTTP 请求，因此用注入的方式会让人感觉有点奇怪。

参考资料：

https://blog.csdn.net/yuanlaijike/article/details/89930553

---

Kotlin 开发者社区

国内第一Kotlin 开发者社区公众号，主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。

越是喧嚣的世界，越需要宁静的思考。