SpringMVC框架是Spring框架中web模块，时下常用来构建web应用。在应用之余，也一直想要搞明白SpringMVC中是如何接受处理请求的？
SpingMVC 初始化
Spring框架和其他框架类似，都是配置元素集中于xml配置文件中，在框架初始化的时候，加载配置文件，解析文件，生成对应的配置。SpringMVC框架是依托于Spring容器。Spring初始化的过程其实就是IoC容器启动的过程，也就是上下文建立的过程。
ServletContext
每一个web应用中都有一个Servlet上下文。servlet容器提供一个全局上下文的环境，这个上下文环境将成为其他IoC容器的宿主环境，例如：WebApplicationContext就是作为ServletContext的一个属性存在。
WebApplicationContext
在使用SpringMVC的时候，通常需要在web.xml文件中配置：
org.springframework.web.context.ContextLoaderListener
ContextLoaderListener 实现了ServletContextListener接口，在SpringMVC中作为监听器的存在，当servlet容器启动时候，会调用contextInitialized进行一些初始化的工作。而ContextLoaderListener中contextInitialized的具体实现在ContextLoader类中。
try {
// Store context in local instance variable, to guarantee that
// it is available on ServletContext shutdown.
if (this.context == null) {
this.context = createWebApplicationContext(servletContext);
}
if (this.context instanceof ConfigurableWebApplicationContext) {
ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context;
if (!cwac.isActive()) {
// The context has not yet been refreshed -> provide services such as
// setting the parent context, setting the application context id, etc
if (cwac.getParent() == null) {
// The context instance was injected without an explicit parent ->
// determine parent for root web application context, if any.
ApplicationContext parent = loadParentContext(servletContext);
cwac.setParent(parent);
}
configureAndRefreshWebApplicationContext(cwac, servletContext);
}
}
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);
上面的部分代码可以看出，初始化时候通过createWebApplicationContext(servletContext);声明一个WebApplicationContext并赋值给ServletContext的org.springframework.web.context.WebApplicationContext.ROOT属性，作为WebApplicationContext的根上下文（root context）。
DispatcherServlet
在加载完load-on-startup的servlet。
example
org.springframework.web.servlet.DispatcherServlet
1
example
/example/*
DispatcherServlet在初始化的过程中，会建立一个自己的IoC容器上下文Servlet WebApplicationContext，会以ContextLoaderListener建立的根上下文作为自己的父级上下文。DispatcherServlet持有的上下文默认的实现类是XmlWebApplicationContext。Servlet有自己独有的Bean空间，也可以共享父级上下文的共享Bean，当然也存在配置有含有一个root WebApplicationContext配置。其关系如下图所示，后面也还会详细介绍DispatcherServlet这个类。
DispatcherServlet类
DispatcherServlet最为SpringMVC核心类，起到了前端控制器（Front controller）的作用，负责请求分发等工作。
从类图中可以看出，DispatcherServlet的继承关系大致如此：
DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet -> GenericServlet
从继承关系上可以得出结论，DispatcherServlet本质上还是一个Servlet。Servlet的生命周期大致分为三个阶段：
- 初始化阶段 init方法
- 处理请求阶段 service方法
- 结束阶段 destroy方法
这里就重点关注DispatcherServlet在这三个阶段具体做了那些工作。
DispatcherServlet初始化
DispatcherServlet的init()的实现在其父类HttpServletBean中。
public final void init() throws ServletException {
...
// Set bean properties from init parameters.
try {
PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);
BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);
ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());
bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment()));
initBeanWrapper(bw);
bw.setPropertyValues(pvs, true);
}
catch (BeansException ex) {
logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);
throw ex;
}
// Let subclasses do whatever initialization they like.
initServletBean();
...
}
以上部分源码描述的过程是通过读取DispatcherServlet中，配置相关bean的配置。完成配置后调用initServletBean方法来创建Servlet WebApplicationContext。
initServletBean方法在FrameworkServlet类中重写了：
protected final void initServletBean() throws ServletException {
...
try {
this.webApplicationContext = initWebApplicationContext();
initFrameworkServlet();
}
...
}
protected WebApplicationContext initWebApplicationContext() {
WebApplicationContext rootContext =
WebApplicationContextUtils.getWebApplicationContext(getServletContext());
WebApplicationContext wac = null;
if (this.webApplicationContext != null) {
wac = this.webApplicationContext;
if (wac instanceof ConfigurableWebApplicationContext) {
ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac;
if (!cwac.isActive()) {
if (cwac.getParent() == null) {
cwac.setParent(rootContext);
}
configureAndRefreshWebApplicationContext(cwac);
}
}
}
if (wac == null) {
wac = findWebApplicationContext();
}
if (wac == null) {
wac = createWebApplicationContext(rootContext);
}
if (!this.refreshEventReceived) {
onRefresh(wac);
}
if (this.publishContext) {
String attrName = getServletContextAttributeName();
getServletContext().setAttribute(attrName, wac);
if (this.logger.isDebugEnabled()) {
this.logger.debug("Published WebApplicationContext of servlet '" + getServletName() +
"' as ServletContext attribute with name [" + attrName + "]");
}
}
return wac;
}
上文提到Servlet容器在启动的时候，通过ContextLoaderListener创建一个根上下文，并配置到ServletContext中。可以看出FrameworkServlet这个类做的作用是用来创建WebApplicationContext上下文的。大致过程如下：
- 首先检查
webApplicationContext是否通过构造函数注入，如果有的话，直接使用，并将根上下文设置为父上下文。 - 如果
webApplicationContext没有注入，则检查是否在ServletContext已经注册过，如果已经注册过，直接返回使用。 - 如果没有注册过，将重新新建一个
webApplicationContext。将根上下文设置为父级上下文。 - 不管是何种策略获取的
webApplicationContext，都将会调用onRefresh方法，onRefresh方法会调用initStrategies方法，通过上下文初始化HandlerMappings、HandlerAdapters、ViewResolvers等等。 - 最后，同样会将所得
webApplicationContext注册到ServletContext中。
而initFrameworkServlet()默认的实现是空的。这也可算是SpingMVC留的一个扩展点。
DispatcherServlet处理请求
纵观SpringMVC的源码，大量运用模板方法的设计模式。Servlet的service方法也不例外。FrameworkServlet类重写service方法：
@Override
protected void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
if (HttpMethod.PATCH == httpMethod || httpMethod == null) {
processRequest(request, response);
}
else {
super.service(request, response);
}
}
如果请求的方法是PATCH或者空，直接调用processRequest方法（后面会详细解释）；否则，将调用父类的service的方法，即HttpServlet的service方法, 而这里会根据请求方法，去调用相应的doGet、doPost、doPut......
而doXXX系列方法的实现并不是HttpServlet类中，而是在FrameworkServlet类中。在FrameworkServlet中doXXX系列实现中，都调用了上面提到的processRequest方法：
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 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 {
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");
}
}
}
publishRequestHandledEvent(request, response, startTime, failureCause);
}
}
为了避免子类重写它，该方法用final修饰。
- 首先调用
initContextHolders方法,将获取到的localeContext、requestAttributes、request绑定到线程上。 - 然后调用
doService方法，doService具体是由DispatcherServlet类实现的。 -
doService执行完成后，调用resetContextHolders，解除localeContext等信息与线程的绑定。 - 最终调用
publishRequestHandledEvent发布一个处理完成的事件。
DispatcherServlet类中的doService方法实现会调用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 {
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null || mappedHandler.getHandler() == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
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;
}
}
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}
doDispatch主要流程是：
- 先判断是否
Multipart类型的请求。如果是则通过multipartResolver解析request - 通过
getHandler方法找到从HandlerMapping找到该请求对应的handler,如果没有找到对应的handler则抛出异常。 - 通过
getHandlerAdapter方法找到handler对应的HandlerAdapter - 如果有拦截器，执行拦截器
preHandler方法 -
HandlerAdapter执行handle方法处理请求，返回ModelAndView。 - 如果有拦截器，执行拦截器
postHandle方法 - 然后调用
processDispatchResult方法处理请求结果，封装到response中。
SpingMVC 请求处理流程
SpringMVC框架是围绕DispatcherServlet设计的。DispatcherServlet负责将请求分发给对应的处理程序。从网上找了两个图，可以大致了解SpringMVC的框架对请求的处理流程。
- 用户发送请求，
Front Controller（DispatcherServlet）根据请求信息将请求委托给对应的Controller进行处理。 -
DispatcherServlet接收到请求后，HandlerMapping将会把请求封装为HandlerExecutionChain，而HandlerExecutionChain包含请求的所有信息，包括拦截器、Handler处理器等。 -
DispatcherServlet会找到对应的HandlerAdapter，并调用对应的处理方法，并返回一个ModelAndView对象。 -
DispatcherServlet会将ModelAndView对象传入View层进行渲染。 - 最终
DispatcherServlet将渲染好的response返回给用户。
总结
本文主要分析SpringMVC中DispatcherServlet的初始化、请求流传过程等。
发现了SpringMVC中在DispatcherServlet的实现过程中运用了模板方法设计模式，看到SpringMVC中留给用户可扩展的点也有很多，体会到Open for extension, closed for modification的设计原则。
本文只关注了DispatcherServlet主流程，忽略了很多宝贵的细枝末节，如：HandlerMapping、HandlerExecutionChain、HandlerAdapter等。后面有机会定会追本溯源。