本文将分析Spring MVC是如何处理请求的；
首先，分析HttpServletBean，FrameworkServlet和DispatcherServlet这三个Servlet的处理过程；这样大家就可以明白从Servlet容器将请求交给Spring MVC一直到DispatcherServlet具体处理请求之前都做了什么；
最后再重点分析Spring MVC中最核心的处理方法doDispatch的处理流程；
HttpServletBean
它主要参与了创建工作，并没有涉及到请求的处理；
FrameworkServlet
Servlet的处理过程：首先从Servlet接口的service方法开始，然后在HttpServlet的service方法中根据请求的类型不同将请求路由到了doGet，doHead，doPost，doPut，doDelete，doOptions和doTrace这7个方法；
HttpServlet默认实现了doHead，doOptions和doDelete；
FrameworkServlet重写了service以及除了doHead的所有其他6个方法；
在service方法中增加了对PATCH类型请求的处理，其他类型的请求直接交给父类进行处理；doOptions和doTrace方法可以通过设置dispatchOptionsRequest和dispatchTraceRequest参数决定是自己处理还是交给父类处理(默认是交给父类，doOptions会在父类的处理结果中增加PATCH类型)；所有需要自己处理的请求都交给processRequest方法统一处理；
protected void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String method = request.getMethod();
//对PATCH类型请求的处理
if (method.equalsIgnoreCase(RequestMethod.PATCH.name())) {
processRequest(request, response);
}
else {
super.service(request, response);
}
}
protected final void doGet(HttpServletRequest request,HttpServletResponse response)
throws ServletException,IOException {
processRequest(request,response); //别的需要自己处理的方法都与doGet类似
}这里的处理思路和HttpServlet的相反，它是将所有的请求都合并到了processRequest方法，不同类型的请求用不同的Handler进行处理；
为什么要这样做呢，不再调用super.service(),而是直接将请求交给processRequest处理不是更简单吗？从结构上来看确实如此，但是如果这样做的话会存在一些问题；
例如：我们为了某种特殊需求需要在Post请求处理前对request进行一些处理，这时可能会新建一个继承自DispatcherServlet的类，然后覆盖doPost方法，在里面对request进行处理，然后再调用super.doPost方法，但是父类根本没有调用doPost，这时就会出现问题，虽然有其他方法来解决这个问题，但按正常的逻辑，调用doPost应该可以完成才合理，而且一般情况下开发者并不需要对Spring MVC 的内部结构非常了解。所以Spring MVC的这种做法是有必要的；
protected final void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
long startTime = System.currentTimeMillis();
Throwable failureCause = null;
//获取LocaleContextHolder中原来保存的LocaleContext
LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();
//获取当前请求的LocaleContext
LocaleContext localeContext = buildLocaleContext(request);
//获取RequestContextHolder中原来保存的RequestAttributes
RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();
//获取当前请求的ServletRequestAttributes
ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes);
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new RequestBindingInterceptor());
//将当前请求的LocaleContext和ServletRequestAttributes设置到LocaleContextHolder和RequestContextHolder中
initContextHolders(request, localeContext, requestAttributes);
try {
//核心语句，这是一个模板方法，在DispatcherServlet中具体实现
//在这之前和之后都做了一些事情，processRequest整个方法就是我们熟知的装饰模式
doService(request, response); /////////////////////////////////////////////////////
}
catch (ServletException ex) {
failureCause = ex;
throw ex;
}
catch (IOException ex) {
failureCause = ex;
throw ex;
}
catch (Throwable ex) {
failureCause = ex;
throw new NestedServletException("Request processing failed", ex);
}
finally {
//恢复原来的LocaleContext和ServiceRequestAttributes到LocaleContextHolder和RequestContextHolder，
//避免影响Servlet以外的处理，如Filter
resetContextHolders(request, previousLocaleContext, previousAttributes);
if (requestAttributes != null) {
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");
}
}
}
//发布ServletRequestHandlerEvent消息
publishRequestHandledEvent(request, response, startTime, failureCause);
}
}或许大家对于设置LocaleContext和RequestAttributes不是很理解，在这我们再深入探索一番，帮助大家更好地理解其目的。首先我们要知道LocaleContext里存放的是Locale(本地化信息),因而是用于获取Locale，而RequestAttributes是spring的一个接口，用于管理request和session的属性，通过它可以get/set/removeAttribute，根据scope参数判断是操作request还是session，使用的具体实现类是ServletRequestAttributes类，它还封装了request、response和session，而且提供了get方法，可以直接获取。到这里或许大家对于LocaleContext和RequestAttributes的作用有了大概的了解，可是它们又是如何使用的呢。通过debug进initContextHolders方法，我们可以发现LocalContext和RequestAttributes是保存在LocalContextHolders和RequestAttributesHolders中的。接下来我们来看看LocalContextHolders和RequestAttributesHolders；
首先我们先来看看LocalContextHolders，这是一个abstract类，但里面的方法都是static的，可以直接调用，而且没有父类也没子类，因而我们不能对其进行实例化，只能调用其static方法。这种abstract的使用方式值得我们学习。在LocaleContextHolder中定义了两个属性：
private static final ThreadLocal<LocaleContext> localeContextHolder =
new NamedThreadLocal<LocaleContext>("Locale context");
private static final ThreadLocal<LocaleContext> inheritableLocaleContextHolder =
new NamedInheritableThreadLocal<LocaleContext>("Locale context");LocaleContextHolder还提供了get/set方法，可以获取和设置LocaleContext，另外还提供了get/setLocale方法，可以直接操作Locale，保存在ThreadLocal中能够保证多个请求之间相互独立，互不影响，对于ThreadLocal的作用及其实现原理，我们将在后面的文章中进行说明。相信到此，大家已经初步理解这样做的目的：为了方便在项目的任何地方使用Locale，而不需要将其作为参数进行传递到对应的地方，只需要调用一下LocaleContextHolder的getLocale()方法即可；
RequestAttributesHolder也是一样的道理，里面封装了RequestAttributes，可以get/set/removeAttribute，而且因为实际封装的是ServletRequestAttributes，因此还可以通过get/set方法获取或修改request、response、session对象；
概括总结一下FrameworkServlet处理请求的过程：
FrameworkServlet重写除doHead的所有处理请求的方法，并在service方法中增加了对PATCH类型请求的处理，其他类型的请求直接交给了父类进行处理；与HttpServlet里将不同类型的请求路径路由到不同方法进行处理的思路相反，doXXX类型方法又将所有请求合并到了processRequest方法中；在processRequet方法中，除了异步请求和调用doService方法具体处理请求，主要做了两件事：
1. 对LocaleContext和RequestAttributes的设置，为了便于在其他层次调用locale信息和request信息；而对它们的恢复是为了不影响Servlet以外的处理，如Filter ；
2. 处理完成后发布了ServletRequestHandledEvent消息；
DispatcherServlet
接下来我们将来弄明白Spring MVC最核心的类——DispatcherServlet，整个处理过程的顶层设计都在这里。从上面FrameworkServlet的分析中，我们知道DispatcherServlet里面执行处理的入口方法是doService，其代码如下：
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请求时对request的Attribute做快照备份
Map<String, Object> attributesSnapshot = null;
if (WebUtils.isIncludeRequest(request)) {
attributesSnapshot = new HashMap<String, Object>();
Enumeration<?> attrNames = request.getAttributeNames();
while (attrNames.hasMoreElements()) {
String attrName = (String) attrNames.nextElement();
if (this.cleanupAfterInclude || attrName.startsWith("org.springframework.web.servlet")) {
attributesSnapshot.put(attrName, request.getAttribute(attrName));
}
}
}
//对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());
//flashMap主要用于Redirect转发时参数的传递
FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate(request, response);
if (inputFlashMap != null) {
request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, Collections.unmodifiableMap(inputFlashMap));
}
request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap());
request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager);
try {
doDispatch(request, response);
}
finally {
if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
//还原request快照的备份
if (attributesSnapshot != null) {
restoreAttributesAfterInclude(request, attributesSnapshot);
}
}
}
}由上面的代码我们可以看出doService并没有直接进行处理，而是交给了doDispatcher进行具体的处理，在交给doDispatcher处理前，doService还做了以下的事：
1. 判断是不是include请求，如果是则对request的Attribute做个快照备份，等doDispatcher处理完成后进行还原；
2. 对request设置了一些属性，至于FlashMap则是主要用于Redirect转发时参数的传递；
分析完doService，接下来我们将对doDispatcher进行分析，其代码如下：
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 {
//检查是不是上传请求
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
//根据request找到Handler
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null || mappedHandler.getHandler() == null) {
noHandlerFound(processedRequest, response);
return;
}
//根据Handler找到HandlerAdapter
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// 处理GET、HEAD请求的Last-Modified
String method = request.getMethod();
boolean isGet = "GET".equals(method);
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;
}
}
//执行相应的Interceptor的preHandle
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// HandlerAdapter使用Handler处理请求
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
//如果需要异步处理，直接返回
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
//当view为空时，根据request设置默认view，如Handler返回值为void
applyDefaultViewName(request, mv);
//执行相应Interceptor的postHandle
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
//处理返回结果，包括处理异常、渲染页面，发出完成通知触发Interceptor的afterCompletion
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Error err) {
triggerAfterCompletionWithError(processedRequest, response, mappedHandler, err);
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// 删除上传资源
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}上述的代码中最核心的代码只有4句，它们的任务分别是：
1. 根据request找到Handler
2. 根据Handler找到对应的HandlerAdapter
3. 用HandlerAdapter处理Handler
4. 调用processRequest方法处理上面处理之后的结果（包含找到View并渲染输出给用户）
对应的代码如下：
mappedHandler = getHandler(processedRequset)
HandlerAdaptor ha = getHandlerAdapter(mappedHandler.getHandler());
mv = ha.handle(processedRequest,response,mappedHandler.getHandler());
processDispatchResult(processRequest,response,mappedHandler,mv,dispatcherException);doDispatcher首先检查是不是上传请求，如果是则将request转换为MultipartHttpServletRequest，并将multipartRequestParsed标志设置为true。
然后通过getHandler获取Handler处理器链，具体的获取过程，后面分析HandlerMapping时再进行详细分析。
接下来处理GET、HEAD请求的Last-Modified，当浏览器第一次跟服务器请求资源时，服务器在返回的请求头里会包含一个last-Modified的属性，代表本资源最后是什么时候修改的。在浏览器以后发送请求时会同时发送之前接收到的last-modified，服务器接收到带Last-modified的请求后会用其值和自己实际资源的最后修改时间作对比，如果资源过期了则返回新的资源（同时返回新的last-modified），否则直接返回304状态吗表示资源未过期，浏览器直接使用之前缓存的结果。
接下来依次调用相应的Interceptor的preHandle。处理完preHandle后就到了此方法最关键的地方——让HandlerAdapter使用Handler处理请求，Controller就是在这执行的，具体内容在分析HandlerAdapter时在详细解释。
Handler处理完请求后，如果需要异步处理则直接返回，如果不需要异步处理，当view为空时，设置默认view，然后执行相应的Interceptor的postHandle。
至此，请求处理的内容就完成了，接下来使用processDispatchResult方法处理前面返回的结果，其中包括处理异常、渲染页面、触发Interceptor的afterCompletion方法三部分内容。
最后是doDispatcher的异常处理，doDispatcher有两层异常处理，内层是捕获在对请求进行处理过程中抛出的异常，外层主要是在处理渲染页面时抛出的。
processDispatchResult代码如下：
private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception) throws Exception {
boolean errorView = false;
//如果请求处理的过程中有异常抛出则处理异常
if (exception != null) {
if (exception instanceof ModelAndViewDefiningException) {
logger.debug("ModelAndViewDefiningException encountered", exception);
mv = ((ModelAndViewDefiningException) exception).getModelAndView();
}
else {
Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
mv = processHandlerException(request, response, handler, exception);
errorView = (mv != null);
}
}
//渲染页面
if (mv != null && !mv.wasCleared()) {
render(mv, request, response);
if (errorView) {
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;
}
//发出请求处理完成的通知，触发Interceptor的afterCompletion
if (mappedHandler != null) {
mappedHandler.triggerAfterCompletion(request, response, null);
}
}
protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
// Determine locale for request and apply it to the response.
Locale locale = this.localeResolver.resolveLocale(request);
response.setLocale(locale);
View view;
if (mv.isReference()) {
//View如果是引用类型，则需要调用resolveViewName使用ViewResolver得到实际的View
view = resolveViewName(mv.getViewName(), mv.getModelInternal(), locale, request);
if (view == null) {
throw new ServletException("Could not resolve view with name '" + mv.getViewName() +
"' in servlet with name '" + getServletName() + "'");
}
}
else {
// No need to lookup: the ModelAndView object contains the actual View object.
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 {
//对页面进行具体渲染
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;
}
}从上面代码我们可以看出，processDispatchResult处理异常的方式是将相应的错误页面设置到View，并在其中的processHandlerException方法中用到了HandlerExceptionResolver。
渲染页面具体在render方法中执行，render中首先对response设置了Local，过程中使用到了LocalResolver，然后判断View如果是String类型则调用resolveViewName方法使用ViewResolver得到实际的View，最后调用view的render方法对页面进行具体的渲染，该过程使用到了ThemeResolver。
最后通过mappedHandler的triggerAfterCompletion方法触发Interceptor的afterCompletion方法。
至此doDispatcher的结构已经分析完毕，在上面我们还留下一个问题没有解决，那就是为什么Spring MVC对处理请求的思路与HttpServlet的将不同类型的请求路由到不同的方法进行处理的思路相反，将所有的请求合并到了processRequest方法中，这是因为Spring MVC将不同类型的请求用不同的Handler进行处理，但通过HandlerAdapter对Handler进行封装，以统一的适配器接口调用Handler，因而将所有的请求合并到了processRequest方法中。
概括总结一下DispatcherServlet的处理过程：
DispatcherServlet的处理请求入口方法是doService，但它没有直接进行具体处理，而是将具体处理交给了doDispatcher，而doDispatcher方法从顶层设计了整个请求处理的过程：
1. 根据request找到Handler
2. 根据Handler找到对应的HandlerAdapter
3. 用HandlerAdapter处理Handler
4. 调用processRequestResult方法处理上面处理之后的结果（包括异常处理、渲染页面、触发Interceptor的afterCompletion方法）
HandlerMapping，是用来查找Handler的，在Spring MVC中会处理很多请求，每个请求都需要一个Handler来处理，具体接收到一个请求后由HandlerMapping决定使用哪个Handler来处理。
Handler，也就是处理器，直接对应MVC中的C也就是Controller层，标注了@RequestMapping的所有方法都可以看成一个Handler
HandlerAdapter，因为Spring MVC中的Handler可以是任意的形式，但Servlet需要处理的方法的结构确实固定的，都是以request和response为参数，因而需要HandlerAdapter来让固定的Servlet处理方法调用灵活的Handler来进行具体处理。
doDispatcher流程
上图是doDispatcher的流程图，中间是doDispatcher的处理流程图，左边是Interceptor相关处理方法的调用位置，右边是doDispatcher方法处理过程中所涉及的组件。图中上半部分的处理请求对应着MVC的Controller即C层，下半部分的processRequestResult主要对应MVC中的View即V层，M层也就是Model贯穿于与整个过程中。