SpringMVC 源码分析之 FrameworkServlet

onghaha

于 2024-04-11 13:29:39 发布

阅读量347

点赞数 5

分类专栏：程序员文章标签：前端 javascript 开发语言

本文链接：https://blog.csdn.net/onghaha/article/details/137635875

版权

程序员专栏收录该内容

185 篇文章 1 订阅

订阅专栏

@Override

protected void service(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());

if (httpMethod == HttpMethod.PATCH || httpMethod == null) {

processRequest(request, response);

}

else {

super.service(request, response);

}

可以看到，在该方法中，首先获取到当前请求方法，然后对 patch 请求额外关照了下，其他类型的请求统统都是 super.service 进行处理。

然而在 HttpServlet 中并未对 doGet、doPost 等请求进行实质性处理，所以 FrameworkServlet 中还重写了各种请求对应的方法，如 doDelete、doGet、doOptions、doPost、doPut、doTrace 等，其实就是除了 doHead 之外的其他方法都重写了。

我们先来看看 doDelete、doGet、doPost 以及 doPut 四个方法：

@Override

protected final void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);

}

@Override

protected final void doPost(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);

}

@Override

protected final void doPut(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);

}

@Override

protected final void doDelete(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);

}

可以看到，这里又把请求交给 processRequest 去处理了，在 processRequest 方法中则会进一步调用到 doService，对不同类型的请求分类处理。

doOptions 和 doTrace 则稍微有些差异，如下：

@Override

protected void doOptions(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

if (this.dispatchOptionsRequest || CorsUtils.isPreFlightRequest(request)) {

processRequest(request, response);

if (response.containsHeader(“Allow”)) {

return;

}

super.doOptions(request, new HttpServletResponseWrapper(response) {

@Override

public void setHeader(String name, String value) {

if (“Allow”.equals(name)) {

value = (StringUtils.hasLength(value) ? value + ", " : “”) + HttpMethod.PATCH.name();

}

super.setHeader(name, value);

}

});

}

@Override

protected void doTrace(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

if (this.dispatchTraceRequest) {

processRequest(request, response);

if (“message/http”.equals(response.getContentType())) {

return;

}

super.doTrace(request, response);

}

可以看到这两个方法的处理多了一层逻辑，就是去选择是在当前方法中处理对应的请求还是交给父类去处理，由于 dispatchOptionsRequest 和 dispatchTraceRequest 变量默认都是 false，因此默认情况下，这两种类型的请求都是交给了父类去处理。

2.processRequest

我们再来看 processRequest，这算是 FrameworkServlet 的核心方法了：

protected final void processRequest(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

long startTime = System.currentTimeMillis();

Throwable failureCause = null;

LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();

LocaleContext localeContext = buildLocaleContext(request);

RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();

ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes);

WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new RequestBindingInterceptor());

initContextHolders(request, localeContext, requestAttributes);

try {

doService(request, response);

}

catch (ServletException | IOException ex) {

failureCause = ex;

throw ex;

}

catch (Throwable ex) {

failureCause = ex;

throw new NestedServletException(“Request processing failed”, ex);

}

finally {

resetContextHolders(request, previousLocaleContext, previousAttributes);

if (requestAttributes != null) {

requestAttributes.requestCompleted();

}

logResult(request, response, failureCause, asyncManager);

publishRequestHandledEvent(request, response, startTime, failureCause);

}

这个方法虽然比较长，但是其实它的核心就是最中间的 doService 方法，以 doService 为界，我们可以将该方法的内容分为三部分：

doService 之前主要是一些准备工作，准备工作主要干了两件事，第一件事就是从 LocaleContextHolder 和 RequestContextHolder 中分别获取它们原来保存的 LocaleContext 和 RequestAttributes 对象存起来，然后分别调用 buildLocaleContext 和 buildRequestAttributes 方法获取到当前请求的 LocaleContext 和 RequestAttributes 对象，再通过 initContextHolders 方法将当前请求的 LocaleContext 和 RequestAttributes 对象分别设置到 LocaleContextHolder 和 RequestContextHolder 对象中；第二件事则是获取到异步管理器并设置拦截器。
接下来就是 doService 方法，这是一个抽象方法，具体的实现在 DispatcherServlet 中，这个松哥放到 DispatcherServlet 中再和大家分析。
第三部分就是 finally 中，这个里边干了两件事：第一件事就是将 LocaleContextHolder 和 RequestContextHolder 中对应的对象恢复成原来的样子（参考第一步）；第二件事就是通过 publishRequestHandledEvent 方法发布一个 ServletRequestHandledEvent 类型的消息。

经过上面的分析，大家发现，processRequest 其实主要做了两件事，第一件事就是对 LocaleContext 和 RequestAttributes 的处理，第二件事就是发布事件。我们对这两件事分别来研究。

2.1 LocaleContext 和 RequestAttributes

LocaleContext 和 RequestAttributes 都是接口，不同的是里边存放的对象不同。

2.1.1 LocaleContext

LocaleContext 里边存放着 Locale，也就是本地化信息，如果我们需要支持国际化，就会用到 Locale。

国际化的时候，如果我们需要用到 Locale 对象，第一反应就是从 HttpServletRequest 中获取，像下面这样：

Locale locale = req.getLocale();

但是大家知道，HttpServletRequest 只存在于 Controller 中，如果我们想要在 Service 层获取 HttpServletRequest，就得从 Controller 中传参数过来，这样就比较麻烦，特别是有的时候 Service 中相关方法都已经定义好了再去修改，就更头大了。

所以 SpringMVC 中还给我们提供了 LocaleContextHolder，这个工具就是用来保存当前请求的 LocaleContext 的。当大家看到 LocaleContextHolder 时不知道有没有觉得眼熟，松哥在之前的 Spring Security 系列教程中和大家聊过 SecurityContextHolder，这两个的原理基本一致，都是基于 ThreadLocal 来保存变量，进而确保不同线程之间互不干扰，对 ThreadLocal 不熟悉的小伙伴，可以看看松哥的 Spring Security 系列，之前有详细分析过（公号后台回复 ss）。

有了 LocaleContextHolder 之后，我们就可以在任何地方获取 Locale 了，例如在 Service 中我们可以通过如下方式获取 Locale：

Locale locale = LocaleContextHolder.getLocale();

上面这个 Locale 对象实际上就是从 LocaleContextHolder 中的 LocaleContext 里边取出来的。