java 请求渲染,Spring MVC学习之DispatcherServlet请求处理详析

前言

要深入理解spring mvc的工作流程,就需要先了解spring mvc的架构:

374a8070c830eaffa6be2edd2520dff1.png

从上图可以看到 前端控制器DispatcherServlet在其中起着主导作用,理解了DispatcherServlet 就完全可以说弄清楚了spring mvc。

DispatcherServlet作为Spring用于处理web请求注册的唯一一个Servlet,所有的请求都是经由DispatcherServlet进行分发处理的。本文主要讲解DispatcherServlet是如何对请求进行分发,处理,并且生成相应的视图的。

1. 整体结构

在HttpServlet中,其对不同方式的请求进行了分发,比如对于GET请求,其提供了doGet()方法,对于POST请求,其提供了doPost()方法等等。通过这种方式,子类可以针对于当前请求的方式实现不同的方法即可。但是在DispatcherServlet中,由于需要使用同一的方式对不同的请求进行处理,因而其对各个请求方式进行了整合,如下就是DispatcherServlet针对GET和POST请求所编写的同一处理逻辑:

@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);

}

可以看到,无论是GET请求还是POST请求,DispatcherServlet都是委托给了processRequest()方法处理,对于其他的请求方式,其处理方式也是类似的。通过这种方式,DispatcherServlet将各个请求整合在了一起,虽然整合在了一起,但是request中也还是保存有当前请求的请求方式的,因而保存了后续对请求进行分发的能力。这里我们直接看processRequest()方法是如何处理各个请求的:

protected final void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

long startTime = System.currentTimeMillis();

Throwable failureCause = null;

// 获取先前请求的LocaleContext

LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();

// 获取当前请求的LocaleContext,其中保存了当前请求的Locale信息

LocaleContext localeContext = buildLocaleContext(request);

// 获取先前请求的Attributes信息

RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();

// 获取当前请求的Attributes信息,其中保存了当前请求的各个属性数据

ServletRequestAttributes requestAttributes =

buildRequestAttributes(request, response, previousAttributes);

// 获取当前请求的WebAsyncManager,这只有在当前请求是请求的异步任务时才会真正用到

WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

// 注册异步任务的拦截器,如果请求的是异步任务,这个拦截器可以拦截异步任务的前置,后置和异常等情况

asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(),

new RequestBindingInterceptor());

// 将当前请求的Locale,Attributes信息初始化到对应的ThreadLocal对象中,用于后续使用

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 {

// 在请求完成之后,判断当前请求的Locale和Attributes信息是否需要继承,如果需要继承,

// 则会将Locale信息设置到inheritableLocaleContextHolder中,而将Attributes

// 信息设置到inheritableRequestAttributesHolder中;否则就会移除对应的信息,

// 而只为当前请求的ContextHolder设置相应的属性

resetContextHolders(request, previousLocaleContext, previousAttributes);

if (requestAttributes != null) {

// 调用已注册的在当前请求被销毁时的回调函数,并且更新Session中当前请求所更新的属性

requestAttributes.requestCompleted();

}

if (logger.isDebugEnabled()) {

if (failureCause != null) {

this.logger.debug("Could not complete request", failureCause);

} else {

if (asyncManager.isConcurrentHandlingStarted()) {

logger.debug("Leaving response open for concurrent processing");

} else {

this.logger.debug("Successfully completed request");

}

}

}

// 发布请求已经完成的事件,以便对该事件进行监听的程序进行相应的处理

publishRequestHandledEvent(request, response, startTime, failureCause);

}

}

可以看到,processRequest()方法主要是对Locale和Attributes信息进行了处理,然后就通过doService()方法对请求再次进行了分发。我们这里继续阅读doService()方法的源码:

@Override

protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {

if (logger.isDebugEnabled()) {

String resumed = WebAsyncUtils.getAsyncManager(request).hasConcurrentResult()

? " resumed" : "";

logger.debug("DispatcherServlet with name '" + getServletName() + "'" + resumed

+ " processing " + request.getMethod() + " request for ["

+ getRequestUri(request) + "]");

}

// 这里主要是判断当前请求是否为include请求,如果是include请求,那么就会将当前请求中的

// 数据都放入一个快照中,在当前请求完成之后,会从该块中中取出数据,然后将其重新加载到

// 当前request中,以便request进行后续的处理。这里默认情况下是会对所有的属性进行处理的,

// 因为cleanupAfterInclude默认值为true,如果将其设置为false,那么就只会对Spring框架

// 相关的属性进行处理

Map attributesSnapshot = null;

if (WebUtils.isIncludeRequest(request)) {

attributesSnapshot = new HashMap<>();

Enumeration> attrNames = request.getAttributeNames();

while (attrNames.hasMoreElements()) {

String attrName = (String) attrNames.nextElement();

if (this.cleanupAfterInclude

|| attrName.startsWith(DEFAULT_STRATEGIES_PREFIX)) {

attributesSnapshot.put(attrName, request.getAttribute(attrName));

}

}

}

// 这里分别将ApplicationContext,LoacleResolver,ThemeResolver和ThemeSource等

// bean添加到当前request中

request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());

request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, this.localeResolver);

request.setAttribute(THEME_RESOLVER_ATTRIBUTE, this.themeResolver);

request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource());

// 这里FlashMapManager主要的作用在于当请求如果是重定向的请求,那么可以将一些属性保存在FlashMap

// 中,然后通过FlashMapManager进行管理,从而在重定向之后能够获取到重定向之前所保存的请求

if (this.flashMapManager != null) {

// 在当前请求中获取FlashMap数据,如果不是重定向之后的请求,那么这里获取到的就是空值

FlashMap inputFlashMap =

this.flashMapManager.retrieveAndUpdate(request, response);

if (inputFlashMap != null) {

// 将获取到的FlashMap数据保存在request中

request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE,

Collections.unmodifiableMap(inputFlashMap));

}

// 设置默认的FlashMap和FlashMapManager

request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap());

request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager);

}

try {

// 这里才是真正的对请求进行分发处理的位置

doDispatch(request, response);

} finally {

// 判断当前请求不是一个异步任务的请求,但是是一个include请求,那么就会重新加载

// 请求之前保存的快照数据

if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {

if (attributesSnapshot != null) {

restoreAttributesAfterInclude(request, attributesSnapshot);

}

}

}

}

这里的doService()方法也还没有对请求进行真正的处理,其首先判断了当前请求是不是一个include请求,如果是include请求,那么就将请求的属性都保存在一个快照中,以便请求完成之后能够重新进行加载;然后会判断当前是否是一个重定向之后的请求,如果是重定向之后的请求,那么其FlashMapManager就不是空的,此时会将重定向之前保存的属性重新加载到当前请求中;最后doService()方法才会调用doDispatch()方法进行请求的分发和处理。如下是doDispatch()方法的源码:

protected void doDispatch(HttpServletRequest request, HttpServletResponse response)

throws Exception {

HttpServletRequest processedRequest = request;

HandlerExecutionChain mappedHandler = null;

boolean multipartRequestParsed = false;

// 获取当前的异步任务管理器

WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

try {

ModelAndView mv = null;

Exception dispatchException = null;

try {

// 这里判断当前请求是否为一个文件请求,这里的判断方式就是要求当前请求满足两点:①请求

// 方式是POST;②判断contentType是否以multipart/开头。如果满足这两点,那么就认为当前

// 请求是一个文件请求,此时会将当前请求的request对象封装为一个

// MultipartHttpServletRequest对象,这也是我们在定义文件请求的Controller时

// 能够将request参数写为MultipartHttpServletRequest的原因。这里如果不是文件请求,

// 那么会将request直接返回。

processedRequest = checkMultipart(request);

// 这里判断原始request与转换后的request是否为同一个request,如果不是同一个,则说明

// 其是一个文件请求

multipartRequestParsed = (processedRequest != request);

// 这里getHandler()方法就是通过遍历当前Spring容器中所有定义的HandlerMapping对象,

// 通过调用它们的getHandler()方法,看当前的HandlerMapping能否将当前request映射

// 到某个handler,也就是某个Controller方法上,如果能够映射到,则说明该handler能够

// 处理当前请求

mappedHandler = getHandler(processedRequest);

if (mappedHandler == null) {

// 如果每个HandlerMapping都无法找到与当前request匹配的handler,那么就认为

// 无法处理当前请求,此时一般会返回给页面404状态码

noHandlerFound(processedRequest, response);

return;

}

// 通过找到的handler,然后在当前Spring容器中找到能够支持将当前request请求适配到

// 找到的handler上的HandlerAdapter。这里需要找到这样的适配器的原因是,我们的handler

// 一般都是Controller的某个方法,其是一个Java方法,而当前request则是一种符合http

// 协议的请求,这里是无法直接将request直接应用到handler上的,因而需要使用一个适配器,

// 也就是这里的HandlerAdapter。由于前面获取handler的时候,不同的HandlerMapping

// 所产生的handler是不一样的,比如ReqeustMappingHandlerMapping产生的handler是一个

// HandlerMethod对象,因而这里在判断某个HandlerAdapter是否能够用于适配当前handler的

// 时候是通过其supports()方法进行的,比如RequestMappingHandlerAdapter就是判断

// 当前的handler是否为HandlerMethod类型,从而判断其是否能够用于适配当前handler。

HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

String method = request.getMethod();

boolean isGet = "GET".equals(method);

// 这里判断请求方式是否为GET或HEAD请求,如果是这两种请求的一种,那么就会判断

// 当前请求的资源是否超过了其lastModified时间,如果没超过,则直接返回,

// 并且告知浏览器可以直接使用缓存来处理当前请求

if (isGet || "HEAD".equals(method)) {

long lastModified = ha.getLastModified(request,

mappedHandler.getHandler());

if (logger.isDebugEnabled()) {

logger.debug("Last-Modified value for [" + getRequestUri(request)

+ "] is: " + lastModified);

}

if (new ServletWebRequest(request, response)

.checkNotModified(lastModified) && isGet) {

return;

}

}

// 这里在真正处理请求之前会获取容器中所有的拦截器,也就是HandlerInterceptor对象,

// 然后依次调用其preHandle()方法,如果某个preHandle()方法返回了false,那么就说明

// 当前请求无法通过拦截器的过滤,因而就会直接出发其afterCompletion()方法,只有在

// 所有的preHandle()方法都返回true时才会认为当前请求是能够使用目标handler进行处理的

if (!mappedHandler.applyPreHandle(processedRequest, response)) {

return;

}

// 在当前请求通过了所有拦截器的预处理之后,这里就直接调用HandlerAdapter.handle()

// 方法来处理当前请求,并且将处理结果封装为一个ModelAndView对象。该对象中主要有两个

// 属性:view和model,这里的view存储了后续需要展示的逻辑视图名或视图对象,而model

// 中则保存了用于渲染视图所需要的属性

mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

// 如果当前是一个异步任务,那么就会释放当前线程,等待异步任务处理完成之后才将

// 任务的处理结果返回到页面

if (asyncManager.isConcurrentHandlingStarted()) {

return;

}

// 如果返回的ModelAndView对象中没有指定视图名或视图对象,那么就会根据当前请求的url

// 来生成一个视图名

applyDefaultViewName(processedRequest, mv);

// 在请求处理完成之后,依次调用拦截器的postHandle()方法,对请求进行后置处理

mappedHandler.applyPostHandle(processedRequest, response, mv);

} catch (Exception ex) {

dispatchException = ex;

} catch (Throwable err) {

// 将处理请求过程中产生的异常封装到dispatchException中

dispatchException = new NestedServletException("Handler dispatch failed",

err);

}

// 这里主要是请求处理之后生成的视图进行渲染,也包括出现异常之后对异常的处理。

// 渲染完之后会依次调用拦截器的afterCompletion()方法来对请求进行最终处理

processDispatchResult(processedRequest, response, mappedHandler, mv,

dispatchException);

} catch (Exception ex) {

// 如果在上述过程中任意位置抛出异常,包括渲染视图时抛出异常,那么都会触发拦截器的

// afterCompletion()方法的调用

triggerAfterCompletion(processedRequest, response, mappedHandler, ex);

} catch (Throwable err) {

triggerAfterCompletion(processedRequest, response, mappedHandler,

new NestedServletException("Handler processing failed", err));

} finally {

// 如果当前异步任务已经开始,则触发异步任务拦截器的afterConcurrentHandlingStarted()方法

if (asyncManager.isConcurrentHandlingStarted()) {

if (mappedHandler != null) {

mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest,

response);

}

} else {

// 如果当前是一个文件请求,则清理当前request中的文件数据

if (multipartRequestParsed) {

cleanupMultipart(processedRequest);

}

}

}

}

这里doDispatch()方法是进行请求分发和处理的主干部分,其主要分为如下几个步骤:

判断当前是否为文件请求,如果是,则将request对象类型转换为MultipartHttpServletRequest;

在HandlerMapping中查找能够处理当前request的HandlerMapping,并且获取能够处理当前请求的handler;

根据获取到的handler,查找当前容器中支持将当前request适配到该handler的HandlerAdapter;

应用容器中所有拦截器的preHandle()方法,只有在所有的preHandle()方法都通过之后才会将当前请求交由具体的handler进行处理;

调用HandlerAdapter.handle()方法将request适配给获取到的handler进行处理;

应用容器中所有拦截器的postHandle()方法,以对当前请求进行后置处理;

根据处理后得到的ModelAndView对象对视图进行渲染;

应用容器中所有拦截器的afterCompletion()方法,以对当前请求进行完成处理。

2. handler获取

从前面的步骤可以看出,请求的具体处理过程主要是通过HandlerMapping根据当前request获取到对应的handler,然后交由HandlerAdapter将request适配给该handler进行处理,并将处理结果封装为一个ModelAndView对象,最后将该ModelAndView对象渲染出来。这里我们首先看HandlerMapping根据request查找具体的handler的过程:

@Nullable

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {

if (this.handlerMappings != null) {

// 遍历当前容器中所有的HandlerMapping对象,调用其getHandler()方法,如果其能够根据

// 当前request获取一个handler,那么就直接返回。

for (HandlerMapping hm : this.handlerMappings) {

if (logger.isTraceEnabled()) {

logger.trace(

"Testing handler map [" + hm + "] in DispatcherServlet with name '"

+ getServletName() + "'");

}

HandlerExecutionChain handler = hm.getHandler(request);

if (handler != null) {

return handler;

}

}

}

return null;

}

这里的逻辑比较简单,就是遍历当前容器中所有的HandlerMapping对象,然后依次判断其是否能够根据当前request获取一个handler,如果能够获取就直接使用该handler。这里关于HandlerMapping将request映射为handler的过程可以阅读本人之前的文章:Spring MVC之RequestMappingHandlerMapping匹配。

3. HandlerAdapter获取与请求处理

在获取到具体的handler之后,Dispatcher就会根据获取到的handler查找能够将当前request适配到该handler的Adapter,这里获取HandlerAdapter的代码如下:

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {

if (this.handlerAdapters != null) {

// 遍历当前容器中所有的HandlerAdapter,通过调用其supports()方法,判断当前HandlerAdapter

// 能否用于适配当前的handler,如果可以,则直接使用该HandlerAdapter

for (HandlerAdapter ha : this.handlerAdapters) {

if (logger.isTraceEnabled()) {

logger.trace("Testing handler adapter [" + ha + "]");

}

if (ha.supports(handler)) {

return ha;

}

}

}

// 如果找不到任何一个HandlerAdapter用于适配当前请求,则抛出异常

throw new ServletException("No adapter for handler [" + handler

+ "]: The DispatcherServlet configuration needs to include a HandlerAdapter"

+ " that supports this handler");

}

这里获取HandlerAdapter的过程与HandlerMapping非常的相似,也是遍历当前容器中所有的HandlerAdapter对象,然后调用其supports()方法,判断该适配器能否应用于当前handler的适配,如果可以则直接使用该HandlerAdapter。关于HandlerAdapter进行request与handler适配的过程,读者可阅读本人之前的文章:Spring MVC之RequestMappingHandlerAdapter详解。

4. 视图渲染

在HandlerAdapter进行了请求的适配,并且调用了目标handler之后,其会返回一个ModelAndView对象,该对象中保存有用于渲染视图的模型数据和需要渲染的视图名。具体的视图渲染工作是在processDispatchResult()方法中进行的,这里我们直接阅读器源码:

private void processDispatchResult(HttpServletRequest request,

HttpServletResponse response, @Nullable HandlerExecutionChain mappedHandler,

@Nullable ModelAndView mv, @Nullable Exception exception) throws Exception {

// 用于标记当前生成view是否是异常处理之后生成的view

boolean errorView = false;

if (exception != null) {

// 如果当前的异常是ModelAndViewDefiningException类型,则说明是ModelAndView的定义

// 异常,那么就会调用其getModelAndView()方法生成一个新的view

if (exception instanceof ModelAndViewDefiningException) {

logger.debug("ModelAndViewDefiningException encountered", exception);

mv = ((ModelAndViewDefiningException) exception).getModelAndView();

} else {

// 如果生成的异常是其他类型的异常,就会在当前容器中查找能够处理当前异常的“拦截器”,

// 找到之后调用这些拦截器,然后生成一个新的ModelAndView

Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);

mv = processHandlerException(request, response, handler, exception);

errorView = (mv != null);

}

}

// 如果得到的ModelAndView对象(无论是否为异常处理之后生成的ModelAndView)不为空,并且没有被清理,

// 那么就会对其进行渲染,渲染的主要逻辑在render()方法中

if (mv != null && !mv.wasCleared()) {

render(mv, request, response);

if (errorView) {

// 如果当前是异常处理之后生成的视图,那么就请求当前request中与异常相关的属性

WebUtils.clearErrorRequestAttributes(request);

}

} else {

if (logger.isDebugEnabled()) {

logger.debug("Null ModelAndView returned to DispatcherServlet with name '"

+ getServletName() + "': assuming HandlerAdapter completed request "

+ "handling");

}

}

// 如果当前正在进行异步请求任务的调用,则直接释放当前线程,等异步任务处理完之后再进行处理

if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {

return;

}

// 在视图渲染完成之后,依次调用当前容器中所有拦截器的afterCompletion()方法

if (mappedHandler != null) {

mappedHandler.triggerAfterCompletion(request, response, null);

}

}

从上面的逻辑可以看出,在进行视图渲染时,首先会判断请求处理过程中是否抛出了异常,如果抛出了异常,则会调用相应的异常处理器,获取异常处理之后的ModelAndView对象,然后通过ModelAndView对象渲染具体的视图,最后会依次触发当前容器中所有拦截器的afterCompletion()方法。这里对视图的具体渲染工作在render()方法中,我们继续阅读其源码:

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {

// 获取当前请求的Locale信息,该信息在进行视图的国际化展示时将会非常有用

Locale locale = (this.localeResolver != null

? this.localeResolver.resolveLocale(request) : request.getLocale());

response.setLocale(locale);

View view;

String viewName = mv.getViewName();

if (viewName != null) {

// 如果视图名不为空,那么就会使用当前容器中配置的ViewResolver根据视图名获取一个View对象

view = resolveViewName(viewName, mv.getModelInternal(), locale, request);

if (view == null) {

throw new ServletException("Could not resolve view with name '"

+ mv.getViewName() + "' in servlet with name '" + getServletName() + "'");

}

} else {

// 如果ModelAndView中没有视图名,而提供的View对象,则直接使用该View对象

view = mv.getView();

if (view == null) {

throw new ServletException("ModelAndView [" + mv + "] neither contains a "

+ "view name nor a View object in servlet with name '"

+ getServletName() + "'");

}

}

if (logger.isDebugEnabled()) {

logger.debug("Rendering view [" + view + "] in DispatcherServlet with name '"

+ getServletName() + "'");

}

try {

// 设置响应的status属性

if (mv.getStatus() != null) {

response.setStatus(mv.getStatus().value());

}

// 调用View对象的render()方法来渲染具体的视图

view.render(mv.getModelInternal(), request, response);

} catch (Exception ex) {

if (logger.isDebugEnabled()) {

logger.debug("Error rendering view [" + view + "] in DispatcherServlet"

+ " with name '" + getServletName() + "'", ex);

}

throw ex;

}

}

这里的render()方法才是进行视图渲染的真正方法,首先该方法首先通过ModelAndView对象获取所要渲染的视图名,通过ViewResolver生成一个用于视图渲染的View对象;如果ModelAndView中不是保存的视图名,而是保存的View对象,则直接使用该对象。在生成View对象之后,通过调用该对象的render()方法渲染得到具体的视图。这里关于ViewResolver如何获取到View对象,并且如何进行视图渲染的过程,读者可以阅读本人的文章:Spring MVC之视图解析。

5. 小结

本文首先从整体上讲解了DispatcherServlet是如何对请求进行聚合并且处理的,然后分别从handler获取,HandlerAdapter进行请求适配,以及视图的渲染三个方面对请求处理的整体流程进行了讲解。这里主要是对DispatcherServlet处理请求的整体流程进行讲解,其各个部分的细节读者可以阅读本人前面的文章以进行详细的了解。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对脚本之家的支持。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值