SpringBoot源码解读与原理分析(三十七)SpringBoot整合WebMvc(二)DispatcherServlet的工作全流程

文章目录

- 前言
- 12.4 DispatcherServlet的工作全流程
- - 12.4.1 DispatcherServlet#service
  - 12.4.2 processRequest
  - 12.4.3 doService
  - - 12.4.3.1 isIncludeRequest的判断
    - 12.4.3.2 FlashMapManager的设计
  - 12.4.4 doDispatch
  - - 12.4.4.1 处理文件上传请求
    - 12.4.4.2 获取可用的Handler
    - - （1）HandlerMapping.getHandler
      - （2）getHandlerInternal
      - （3）getHandlerExecutionChain
    - 12.4.4.3 获取HandlerAdapter
    - 12.4.4.4 回调拦截器
    - 12.4.4.5 执行Handler
    - - （1）handleInternal
      - （2）invokeHandlerMethod
      - （a）初始化参数绑定器
        （b）参数预绑定
        （c）创建方法执行对象
        （d）执行Controller的方法```invokeAndHandle```
        （e）包装ModelAndView
    - 12.4.4.6 再次回调拦截器
    - 12.4.4.7 处理视图、解析异常
    - - （1）处理异常
      - （2）渲染视图
      - （3）第三次回调拦截器
  - 12.4.5 DispatcherServlet工作流程总结
- 12.5 小结

前言

WebMvc的核心组件装配完成之后，DispatcherServlet作为WebMvc的核心前端控制器正式投入工作，默认接收客户端的所有请求，并调度其它核心组件处理请求，最终响应结果给客户端。

本节内容研究WebMvc在实际运行期间DispatcherServlet对于请求处理和响应结果的全流程执行原理。本文内容由于不可割裂，因此具有超长预警。

本文沿用 SpringBoot源码解读与原理分析(三十六)SpringBoot整合WebMvc(一)@Controller控制器装配原理 12.1 SpringBoot整合WebMvc案例中编写好的示例项目，并进行一些小改动。

新增CustomAdvice类，标注@ControllerAdvice注解，并编写两个标注@InitBinder和@ExceptionHandler的方法

@ControllerAdvice
public class CustomAdvice {

    @InitBinder
    public void customDataBinder(WebDataBinder dataBinder) {
        // 请求URL中的时间格式为yyyy-MM-dd HH:mm:ss
        // 自动绑定到Date属性参数中
        dataBinder.addCustomFormatter(new DateFormatter("yyyy-MM-dd HH:mm:ss"));
    }

    @ExceptionHandler({Exception.class})
    public String customExceptionHandler(Exception ex) {
        System.out.println("自定义异常发生了，" + ex.getMessage());
        return "自定义异常返回";
    }

}

修改UserController类，新增标注@InitBinder注解的方法，test方法新增一个Date类型的参数

@Controller
@RequestMapping("/user")
public class UserController {

    @InitBinder
    public void myDataBinder(WebDataBinder dataBinder) {
        // 如果参数是字符串类型，则去除字符串的前后空格
        dataBinder.registerCustomEditor(String.class, new StringTrimmerEditor(true));
    }

    @RequestMapping(method = RequestMethod.GET, value = "/test")
    @ResponseBody
    public String test(String name, Date time) {
        System.out.println("请求参数 name=" + name);
        System.out.println("请求参数 time=" + time);
        return name;
    }
}

新增拦截器CustomInterceptor类

public class CustomInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("拦截器的preHandle方法执行了...");
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        System.out.println("拦截器的postHandle方法执行了...");
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        System.out.println("拦截器的afterCompletion方法执行了...");
    }
}

修改配置类，加载拦截器及配置其路径

@Configuration
public class PathConfig implements WebMvcConfigurer {

    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        configurer.addPathPrefix("/api", c -> c.isAnnotationPresent(Controller.class));
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new CustomInterceptor()).addPathPatterns("/api/user/test");
    }
}

至此，示例项目代码编写完成，执行主启动类的main方法启动项目。使用浏览器访问 http://127.0.0.1:8080/api/user/test?name=aaa&time=2024-02-29 12:12:12，控制台打印结果如下：

拦截器的preHandle方法执行了...
请求参数 name=aaa
请求参数 time=Thu Feb 29 12:12:12 CST 2024
拦截器的postHandle方法执行了...
拦截器的afterCompletion方法执行了...

12.4 DispatcherServlet的工作全流程

启动示例项目后，在DispatcherServlet的父类FrameworkServlet的service方法上打入断点，随后使用浏览器发起请求，待程序停在断点处，开始Debug调试。

12.4.1 DispatcherServlet#service

源码1：FrameworkServlet.java

protected void service(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
    if (httpMethod == HttpMethod.PATCH || httpMethod == null) {
        // 对PATCH类型的请求单独处理
        processRequest(request, response);
    } else {
        // 调用父类的HttpServlet的service方法
        super.service(request, response);
    }
}

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

由源码1 可知，service方法会对PATCH类型的请求单独处理，但通常在项目开发中不会使用PATCH类型。

继续向下执行else块的super.service方法，FrameworkServlet的父类HttpServlet会根据不同的请求类型将方法转发至doXxx方法中，所以最终执行的是FrameworkServlet中重写的doGet、doPost、doPut、doDelete等方法，而这些方法最终都会调用processRequest方法。

12.4.2 processRequest

源码2：FrameworkServlet.java

protected final void processRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // 记录接收请求的时间
    long startTime = System.currentTimeMillis();
    Throwable failureCause = null;
    // 获取当前线程的LocaleContext
    LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();
    // 创建当前线程的LocaleContext
    LocaleContext localeContext = buildLocaleContext(request);
    // 获取当前线程的RequestAttributes
    RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();
    // 创建当前线程的RequestAttributes
    ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes);

    WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
    asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new FrameworkServlet.RequestBindingInterceptor());

    // 初始化ContextHolder，传入新封装好LocaleContext和RequestAttributes
    initContextHolders(request, localeContext, requestAttributes);

    try {
        // 真正处理请求的方法，但这是子类的模板方法
        doService(request, response);
    } // catch ...
    finally {
        // 重新设置当前线程的LocaleContext和RequestAttributes
        resetContextHolders(request, previousLocaleContext, previousAttributes);
        if (requestAttributes != null) {
            requestAttributes.requestCompleted();
        }
        logResult(request, response, failureCause, asyncManager);
        // 发布ServletRequestHandledEvent事件
        publishRequestHandledEvent(request, response, startTime, failureCause);
    }
}

private void initContextHolders(HttpServletRequest request,
                                @Nullable LocaleContext localeContext, @Nullable RequestAttributes requestAttributes) {
    // 将全新的LocaleContext和RequestAttributes设置到当前线程中
    if (localeContext != null) {
        LocaleContextHolder.setLocaleContext(localeContext, this.threadContextInheritable);
    }
    if (requestAttributes != null) {
        RequestContextHolder.setRequestAttributes(requestAttributes, this.threadContextInheritable);
    }
}

private void resetContextHolders(HttpServletRequest request,
                                 @Nullable LocaleContext prevLocaleContext, @Nullable RequestAttributes previousAttributes) {
    // 将预先保存的LocaleContext和RequestAttributes设置回线程中
    LocaleContextHolder.setLocaleContext(prevLocaleContext, this.threadContextInheritable);
    RequestContextHolder.setRequestAttributes(previousAttributes, this.threadContextInheritable);
}

由源码2 可知，processRequest方法会对请求做一些前置处理，再转调doService方法真正处理请求。

在该方法的前置处理中，做了线程之间的隔离。首先获取当前线程的LocaleContext和RequestAttributes并暂存在方法中，随后创建全新的LocaleContext和RequestAttributes，调用initContextHolders方法设置到当前线程中，以此完成线程之间的隔离。

待请求完成处理后，在finally代码块中，调用resetContextHolders方法将预先保存好的LocaleContext和RequestAttributes设置回线程中，以恢复原来的线程。

12.4.3 doService

源码3：DispatcherServlet.java

protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
    logRequest(request);
    
    Map<String, Object> attributesSnapshot = null;
    // 判断请求是否由<jsp:include>标签而来
    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));
            }
        }
    }

    // ......

    if (this.flashMapManager != null) {
        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 ...
}

由源码3 可知，doService方法也是在进行一些前置处理之后，转调doDispatch方法真正处理请求。

12.4.3.1 isIncludeRequest的判断

源码4：WebUtils.java

public static final String INCLUDE_REQUEST_URI_ATTRIBUTE = "javax.servlet.include.request_uri";
public static boolean isIncludeRequest(ServletRequest request) {
    // 判断当前请求中是否包含名为“javax.servlet.include.request_uri”的属性
    return (request.getAttribute(INCLUDE_REQUEST_URI_ATTRIBUTE) != null);
}

由源码4 可知，doService方法的第一个if判断结构会调用WebUtils.isIncludeRequest(request)方法。该方法会判断当前请求中是否包含名为“javax.servlet.include.request_uri”的属性。

在JSP中，使用 <jsp:incluedepage=“xxx.jsp”> 标签可以组合其他JSP页面，那么这个被组合的JSP页面的加载请求就会带上“javax.servlet.include.request_uri”属性。因此，isIncludeRequest方法的作用是区别页面的加载是否由<jsp:include>标签而来。

12.4.3.2 FlashMapManager的设计

在用户登录的业务场景中，如果是前后端不分离的情况，通常是使用POST请求将用户名、密码等信息传入后端以供认证，认证成功后使用重定向将客户端引导至系统主页。

在这个前提下有一个特殊的场景：如果用于登录时提交的登录表单中，有一些需要在跳转至主页时渲染的数据，则仅放入request域中无法解决问题。

Spring引入FlashMapManager来解决这个问题，可以在页面重定向发生跳转时，将需要渲染的数据暂时放入session中，这样浏览器即便刷新也不会影响数据渲染。

12.4.4 doDispatch

该方法是处理请求和响应的核心方法，由于篇幅很长，下面拆解来看。

12.4.4.1 处理文件上传请求

源码5：DispatcherServlet.java

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

            // ......
}

protected HttpServletRequest checkMultipart(HttpServletRequest request) throws MultipartException {
    if (this.multipartResolver != null && this.multipartResolver.isMultipart(request)) {
        if (WebUtils.getNativeRequest(request, MultipartHttpServletRequest.class) != null) {
            if (request.getDispatcherType().equals(DispatcherType.REQUEST)) {
                // logger ...
            }
        } else if (hasMultipartException(request)) {
            // logger ...
        } else {
            try {
                return this.multipartResolver.resolveMultipart(request);
            } // catch ...
        }
    }
    return request;
}

源码6：StandardServletMultipartResolver.java

@Override
public boolean isMultipart(HttpServletRequest request) {
    return StringUtils.startsWithIgnoreCase(request.getContentType(), "multipart/");
}

由源码5 可知，doDispatch方法的第一部分逻辑是处理带有文件上传的请求，其核心组件是MultipartResolver。首先判断请求是否是multipart请求，如果是，则将本由Servlet容器处理的HttpServletRequest对象转换为可以访问请求中的文件对象的MultipartHttpServletRequest子接口对象。

由源码6 可知，判断请求是否是multipart请求的方法是判断请求头content-type是否以"multipart/"开头。

由于当前Debug的请求只是一个普通的GET请求，所以不会进入该部分代码。

12.4.4.2 获取可用的Handler

源码7：DispatcherServlet.java

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    // 处理文件上传的请求 ...
    
    // 获取可用的Handler
    mappedHandler = getHandler(processedRequest);
    if (mappedHandler == null) {
        noHandlerFound(processedRequest, response);
        return;
    }
    
    // ......
}

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    if (this.handlerMappings != null) {
        for (HandlerMapping mapping : this.handlerMappings) {
            HandlerExecutionChain handler = mapping.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
    }
    return null;
}

由源码7 可知，doDispatch方法的第二部分逻辑是获取可用的Handler。在getHandler方法中，遍历所有的HandlerMapping，从中找出可以返回非空HandlerExecutionChain对象的HandlerMapping。

HandlerMapping集合
Debug至getHandler方法的内部，可以发现有5个HandlerMapping可以选择。由于实例项目编写的Handler是以@Controller+@RequestMapping注解实现的，因此最终选择出来的HandlerMapping是与之相匹配的RequestMappingHandlerMapping。

（1）HandlerMapping.getHandler

源码8：AbstractHandlerMapping.java

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    // 留给子类实现的模板方法
    Object handler = getHandlerInternal(request);
    
    // ......
    
    // 构建HandlerExecutionChain对象
    HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
    
    // ......
    return executionChain;
}

由源码8 可知，HandlerMapping的getHandler的方法的核心逻辑有两步：由子类具体获取Handler的具体对象；根据Handler对象构建HandlerExecutionChain对象。

（2）getHandlerInternal

Debug进入getHandlerInternal方法，发现程序会进入RequestMappingHandlerMapping的直接父类RequestMappingInfoHandlerMapping中。

源码9：RequestMappingInfoHandlerMapping.java

@Override
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
    request.removeAttribute(PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
    try {
        return super.getHandlerInternal(request);
    } finally {
        ProducesRequestCondition.clearMediaTypesAttribute(request);
    }
}

由源码9 可知，RequestMappingInfoHandlerMapping中的getHandlerInternal也是直接使用super.getHandlerInternal方法调用父类AbstractHandlerMethodMapping中的getHandlerInternal方法。

源码10：AbstractHandlerMethodMapping.java

@Override
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
    // 获取本次请求的URI，并设置到request域中
    String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
    request.setAttribute(LOOKUP_PATH, lookupPath);
    this.mappingRegistry.acquireReadLock();
    try {
        // 获取可以处理当前URI请求的HandlerMethod对象
        HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
        // 创建全新的HandlerMethod对象
        return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
    } finally {
        this.mappingRegistry.releaseReadLock();
    }
}

由源码10 可知，getHandlerInternal方法首先会借助UrlPathHelper获取本次请求URI（示例项目是"/api/user/test"），并设置到request域中。随后调用lookupHandlerMethod方法，获取可以处理当前URI请求的HandlerMethod对象（实例项目是UserController的test方法）。

请求URI和HandlerMethod对象
注意，获取到HandlerMethod对象之后，还要调用createWithResolvedBean方法创建一个全新的HandlerMethod对象。为什么还要再次创建呢？

注意观察上图，发现HandlerMethod对象中的bean属性是一个字符串"userController"，而不是BeanFactory中真实存在的UserController对象，其他属性也没有UserController对象的持有。

源码11：HandlerMethod.java

public HandlerMethod createWithResolvedBean() {
    Object handler = this.bean;
    if (this.bean instanceof String) {
        Assert.state(this.beanFactory != null, "Cannot resolve bean name without BeanFactory");
        String beanName = (String) this.bean;
        // 从BeanFactory中取出bean对象
        handler = this.beanFactory.getBean(beanName);
    }
    // 重新封装HandlerMethod
    return new HandlerMethod(this, handler);
}

由源码11 可知，createWithResolvedBean方法的作用就是从BeanFactory中取出UserController对象并重新封装。

（3）getHandlerExecutionChain

回到源码8 ，getHandlerInternal执行完后获得HandlerMethod对象，然后将该HandlerMethod对象传入getHandlerExecutionChain方法，组合跟该Handler相关的拦截器，并封装为执行链HandlerExecutionChain对象。

源码12：AbstractHandlerMapping.java

protected HandlerExecutionChain getHandlerExecutionChain(Object handler, HttpServletRequest request) {
    // 构造HandlerExecutionChain对象
    HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ?
            (HandlerExecutionChain) handler : new HandlerExecutionChain(handler));
    // 获取请求路径
    String lookupPath = this.urlPathHelper.getLookupPathForRequest(request, LOOKUP_PATH);
    for (HandlerInterceptor interceptor : this.adaptedInterceptors) {
        if (interceptor instanceof MappedInterceptor) {
            // 匹配路径的拦截器处理
            MappedInterceptor mappedInterceptor = (MappedInterceptor) interceptor;
            if (mappedInterceptor.matches(lookupPath, this.pathMatcher)) {
                chain.addInterceptor(mappedInterceptor.getInterceptor());
            }
        } else {
            // 普通拦截器直接添加
            chain.addInterceptor(interceptor);
        }
    }
    return chain;
}

由源码12 可知，getHandlerExecutionChain会根据HandlerInterceptor的类型分别进行处理，最终构造一个HandlerExecutionChain对象。

getHandlerExecutionChain方法
由上图可知，对示例项目来说，构造的HandlerExecutionChain对象组合了三个拦截器，分别是ConversionServiceExposingInterceptor、ResourceUrlProviderExposingInterceptor，以及示例项目自定义的CustomInterceptor。

获得HandlerMethod对象并组合拦截器封装成HandlerExecutionChain对象之后，HandlerMapping的工作全部完成，接下来回到DispatcherServlet的doDispatch方法。

12.4.4.3 获取HandlerAdapter

源码13：DispatcherServlet.java

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 {
            // 处理文件上传请求
            // 获取可用的Handler
            
            // 获取HandlerAdapter
            HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

            // ......
}

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
    if (this.handlerAdapters != null) {
        for (HandlerAdapter adapter : this.handlerAdapters) {
            if (adapter.supports(handler)) {
                return adapter;
            }
        }
    }
    // throw ex ...
}

由源码13 可知，doDispatch方法的第三部分逻辑是获取可以处理当前请求的HandlerAdapter,匹配规则是通过HandlerAdapter的supports方法。

Debug至getHandlerAdapter方法，发现有4个可选的HandlerAdapter实现类对象：

getHandlerAdapter方法
由上图可知，示例项目选择的HandlerAdapter实现类对象是RequestMappingHandlerAdapter。

源码14：AbstractHandlerMethodAdapter.java

@Override
public final boolean supports(Object handler) {
    return (handler instanceof HandlerMethod && supportsInternal((HandlerMethod) handler));
}

源码15：RequestMappingHandlerAdapter.java

@Override
protected boolean supportsInternal(HandlerMethod handlerMethod) {
    return true;
}

由源码14-15 可知，supports方法仅是判断Handler类是否是HandlerMethod对象，supportsInternal方法默认返回true，此处supports方法一定返回true，因此最终会选择可选HandlerAdapter对象集合中下标为0的对象，即RequestMappingHandlerAdapter。

12.4.4.4 回调拦截器

源码16：DispatcherServlet.java

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 {
            // 处理文件上传请求
            // 获取可用的Handler
            // 获取HandlerAdapter
            
            // 回调拦截器
            if (!mappedHandler.applyPreHandle(processedRequest, response)) {
                return;
            }
            
            // ......
}

boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {
    // 获取HandlerExecutionChain对象中组合的拦截器
    HandlerInterceptor[] interceptors = getInterceptors();
    if (!ObjectUtils.isEmpty(interceptors)) {
        for (int i = 0; i < interceptors.length; i++) {
            HandlerInterceptor interceptor = interceptors[i];
            // 遍历拦截器，执行preHandle方法
            if (!interceptor.preHandle(request, response, this.handler)) {
                triggerAfterCompletion(request, response, null);
                return false;
            }
            this.interceptorIndex = i;
        }
    }
    return true;
}

由源码16 可知，doDispatch方法的第四部分逻辑是回调HandlerExecutionChain对象中组合的拦截器，首先会获取HandlerExecutionChain对象中组合的拦截器，然后遍历这些拦截器，执行其preHandle方法。

注意，每个拦截器preHandle方法如果有一个返回false，则applyPreHandle方法直接返回false，doDispatch方法直接结束不再执行下面的逻辑。

由 12.4.4.2 节的getHandlerExecutionChain方法分析可知，HandlerExecutionChain对象中组合的拦截器有3个，分别是ConversionServiceExposingInterceptor和ResourceUrlProviderExposingInterceptor，以及示例项目自定义的CustomInterceptor。

源码17：ResourceUrlProviderExposingInterceptor.java

@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
    try {
        request.setAttribute(RESOURCE_URL_PROVIDER_ATTR, this.resourceUrlProvider);
    } // catch ...
    return true;
}

源码18：ConversionServiceExposingInterceptor.java

@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws ServletException, IOException {
    request.setAttribute(ConversionService.class.getName(), this.conversionService);
    return true;
}

源码19：CustomInterceptor.java

public class CustomInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("拦截器的preHandle方法执行了...");
        return true;
    }
}

有源码17-19 以及CustomInterceptor类可知，四两个拦截器的preHandle方法一定会返回true，因此applyPreHandle方法返回true，doDispatch方法继续执行下面的逻辑。

12.4.4.5 执行Handler

源码20：DispatcherServlet.java

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 {
            // 处理文件上传请求
            // 获取可用的Handler
            // 获取HandlerAdapter
            // 回调拦截器
            
            // 实际执行Handler
            mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
            
            // ......
}

由源码20 可知，doDispatch方法的第五部分逻辑是调用HandlerAdapter的```handle``方法实际执行Handler，返回一个ModelAndView。

借助IDE，可以发现handle方法的实现在DispatcherServlet的父类AbstractHandlerMethodAdapter中，其handle方法又会转调子类RequestMappingHandlerAdapter的handleInternal方法。

（1）handleInternal

源码21：AbstractHandlerMethodAdapter.java

@Override
@Nullable
public final ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
    return handleInternal(request, response, (HandlerMethod) handler);
}

源码22：RequestMappingHandlerAdapter.java

private boolean synchronizeOnSession = false;
@Override
protected ModelAndView handleInternal(HttpServletRequest request,
                                      HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ModelAndView mav;
    checkRequest(request);

    // 同步session的配置，默认为fasle
    if (this.synchronizeOnSession) {
        // ......
    } else {
        // 执行Handler方法
        mav = invokeHandlerMethod(request, response, handlerMethod);
    }

    // ......

    return mav;
}

由源码21-22 可知，handleInternal方法最核心的逻辑是else代码块中的invokeHandlerMethod方法。

（2）invokeHandlerMethod

由于invokeHandlerMethod方法的篇幅很长，下面拆解来看。

（a）初始化参数绑定器

在WebMvc中，有两个和参数绑定相关的注解：@InitBinder和@ControllerAdvice。

@InitBinder注解可以单独声明在一个Controller类中，执行当前Controller类中的方法时，会先执行标注了@InitBinder注解的方法，初始化一些参数绑定器的逻辑。

@ControllerAdvice注解可以配合@InitBinder注解标注的方法，实现全局的参数绑定器预初始化。

源码23：RequestMappingHandlerAdapter.java

protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
                                           HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ServletWebRequest webRequest = new ServletWebRequest(request, response);
    try {
        // 初始化参数绑定器
        WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod);
        
        // ......
}

public static final MethodFilter INIT_BINDER_METHODS = method ->
            AnnotatedElementUtils.hasAnnotation(method, InitBinder.class);
private WebDataBinderFactory getDataBinderFactory(HandlerMethod handlerMethod) throws Exception {
    Class<?> handlerType = handlerMethod.getBeanType();
    Set<Method> methods = this.initBinderCache.get(handlerType);
    if (methods == null) {
        // 获取当前Controller中全部标注了@InitBinder注解的方法，并放到initBinderCache缓存中
        methods = MethodIntrospector.selectMethods(handlerType, INIT_BINDER_METHODS);
        this.initBinderCache.put(handlerType, methods);
    }
    List<InvocableHandlerMethod> initBinderMethods = new ArrayList<>();
    // 遍历标注了@ControllerAdvice注解的类
    this.initBinderAdviceCache.forEach((controllerAdviceBean, methodSet) -> {
        if (controllerAdviceBean.isApplicableToBeanType(handlerType)) {
            Object bean = controllerAdviceBean.resolveBean();
            // 遍历这些类中的全部标注了@InitBinder注解的方法，添加到initBinderMethods缓存中
            for (Method method : methodSet) {
                initBinderMethods.add(createInitBinderMethod(bean, method));
            }
        }
    });
    // 遍历当前Controller中全部标注了@InitBinder注解的方法
    // 将这些方法添加到initBinderMethods缓存中
    // 相当于合并了Controller类中和标注了@ControllerAdvice注解的类中的方法
    for (Method method : methods) {
        Object bean = handlerMethod.getBean();
        initBinderMethods.add(createInitBinderMethod(bean, method));
    }
    // 创建数据绑定工厂
    return createDataBinderFactory(initBinderMethods);
}

底层收集和执行@InitBinder注解的方法就是invokeHandlerMethod方法中的getDataBinderFactory方法。

由源码23 可知，getDataBinderFactory方法会分别收集Controller类中标注了@InitBinder注解的方法、标注了@ControllerAdvice注解的类中标注了@InitBinder注解的方法，并合并起来共同组成参数绑定器。

示例项目中编写的两类绑定器都被收集起来了，如图：

自定义的参数绑定器
在UserController中定义的参数绑定器是：

@InitBinder
public void myDataBinder(WebDataBinder dataBinder) {
    // 如果参数是字符串类型，则去除字符串的前后空格
    dataBinder.registerCustomEditor(String.class, new StringTrimmerEditor(true));
}

如果暂时把@InitBinder注解注释掉，该绑定器不再生效，执行结果如下：

没有@InitBinder时有空格
如果添加了把@InitBinder注解注解，该绑定器生效，执行结果如下：

有@InitBinder时无空格

CustomAdvice类中定义的参数绑定器是：

@ControllerAdvice
public class CustomAdvice {

    @InitBinder
    public void customDataBinder(WebDataBinder dataBinder) {
        // 请求URL中的时间格式为yyyy-MM-dd HH:mm:ss
        // 自动绑定到Date属性参数中
        dataBinder.addCustomFormatter(new DateFormatter("yyyy-MM-dd HH:mm:ss"));
    }
}

如果时间类型的参数不按照 yyyy-MM-dd HH:mm:ss 的格式传递，在浏览器访问：http://127.0.0.1:8080/api/user/test?name=aaa&time=2024年2月29日 12时12分12秒，结果如下:

IllegalArgumentException: Parse attempt failed for value [2024年2月29日 12时12分12秒]

如果时间类型的参数按照 yyyy-MM-dd HH:mm:ss 的格式传递，在浏览器访问：http://127.0.0.1:8080/api/user/test?name=aaa&time=2024-02-29 12-12-12，则正常访问。

通过以上测试，发现自定义的参数绑定器均生效了。

（b）参数预绑定

源码24：RequestMappingHandlerAdapter.java

protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
                                           HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ServletWebRequest webRequest = new ServletWebRequest(request, response);
    try {
        // 初始化参数绑定器 ...
        
        // 参数预绑定
        ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory);
        
        // ......
}

public static final MethodFilter MODEL_ATTRIBUTE_METHODS = method ->
			(!AnnotatedElementUtils.hasAnnotation(method, RequestMapping.class) &&
					AnnotatedElementUtils.hasAnnotation(method, ModelAttribute.class));
private ModelFactory getModelFactory(HandlerMethod handlerMethod, WebDataBinderFactory binderFactory) {
    SessionAttributesHandler sessionAttrHandler = getSessionAttributesHandler(handlerMethod);
    Class<?> handlerType = handlerMethod.getBeanType();
    Set<Method> methods = this.modelAttributeCache.get(handlerType);
    if (methods == null) {
        // 获取当前Controller中全部标注了@ModelAttribute注解且没有被@RequestMapping注解标注的方法
        // 并放到modelAttributeCache缓存中
        methods = MethodIntrospector.selectMethods(handlerType, MODEL_ATTRIBUTE_METHODS);
        this.modelAttributeCache.put(handlerType, methods);
    }
    List<InvocableHandlerMethod> attrMethods = new ArrayList<>();
    // 遍历标注了@ControllerAdvice注解的类
    this.modelAttributeAdviceCache.forEach((controllerAdviceBean, methodSet) -> {
        if (controllerAdviceBean.isApplicableToBeanType(handlerType)) {
            Object bean = controllerAdviceBean.resolveBean();
            // 遍历这些类中的全部标注了@ModelAttribute注解的方法，添加到attrMethods缓存中
            for (Method method : methodSet) {
                attrMethods.add(createModelAttributeMethod(binderFactory, bean, method));
            }
        }
    });
    // 遍历当前Controller中全部标注了@ModelAttribute注解的方法
    // 将这些方法添加到attrMethods缓存中
    // 相当于合并了Controller类中和标注了@ControllerAdvice注解的类中的方法
    for (Method method : methods) {
        Object bean = handlerMethod.getBean();
        attrMethods.add(createModelAttributeMethod(binderFactory, bean, method));
    }
    return new ModelFactory(attrMethods, binderFactory, sessionAttrHandler);
}

由源码24 可知，getModelFactory方法和上一步的getDataBinderFactory方法的逻辑结构几乎一样，都是将Controller类中的标注了某个注解的方法，与全局类中标注了某个注解的方法合并起来。

不同的是，getDataBinderFactory方法找的是@InitBinder注解，而getModelFactory方法找的是@ModelAttribute注解；相同的是，全局类都标注@ControllerAdvice注解。

（c）创建方法执行对象

源码25：RequestMappingHandlerAdapter.java

protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
                                           HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ServletWebRequest webRequest = new ServletWebRequest(request, response);
    try {
        // 初始化参数绑定器 ...
        // 参数预绑定 ...
        
        // 创建方法执行对象
        ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(handlerMethod);
        
        // ......
}

protected ServletInvocableHandlerMethod createInvocableHandlerMethod(HandlerMethod handlerMethod) {
    return new ServletInvocableHandlerMethod(handlerMethod);
}

由源码25 可知，createInvocableHandlerMethod方法只是将HandlerMethod对象二度封装为ServletInvocableHandlerMethod对象。

（d）执行Controller的方法`invokeAndHandle`

源码26：RequestMappingHandlerAdapter.java

protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
                                           HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ServletWebRequest webRequest = new ServletWebRequest(request, response);
    try {
        // 初始化参数绑定器 ...
        // 参数预绑定 ...
        // 创建方法执行对象 ...
        // 创建ModelAndView的容器ModelAndViewContainer ...（不重要）
        // 对异步请求的支持 ...（不重要）
        
        // 执行Controller的方法
        invocableMethod.invokeAndHandle(webRequest, mavContainer);
        if (asyncManager.isConcurrentHandlingStarted()) {
            return null;
        }
        // 包装ModelAndView
        return getModelAndView(mavContainer, modelFactory, webRequest);
    } // finally ...
}

由源码26 可知，创建方法执行对象ServletInvocableHandlerMethod后，又创建了ModelAndView的容器ModelAndViewContainer，以及处理了对异步请求的支持，最后调用方法执行对象ServletInvocableHandlerMethod的invokeAndHandle方法执行Handler方法。

由于invokeAndHandle方法的篇幅很长，下面拆解来看。

（i）反射执行Controller方法

源码27：ServletInvocableHandlerMethod.java

public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
            Object... providedArgs) throws Exception {
    // 反射执行Controller方法
    Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
    
    // ......
}

源码28：InvocableHandlerMethod.java

public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
                               Object... providedArgs) throws Exception {
    // 获取参数值列表
    Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
    // logger ...
    return doInvoke(args);
}

protected Object doInvoke(Object... args) throws Exception {
    ReflectionUtils.makeAccessible(getBridgedMethod());
    try {
        // 利用反射机制执行Handler
        return getBridgedMethod().invoke(getBean(), args);
    }
    // catch ...
}

由源码27-28 可知，invokeAndHandle方法调用invokeForRequest方法，会先收集好执行Handler方法所需的参数列表，然后利用反射机制执行目标Handler方法。doInvoke方法执行完毕后，意味着项目中编写的Controller类的方法已经执行完毕。

（ii）处理方法返回值

源码29：ServletInvocableHandlerMethod.java

public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
            Object... providedArgs) throws Exception {
    // 反射执行Controller方法
    Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
    
    // ......
    
    // 处理方法返回值
    try {
        this.returnValueHandlers.handleReturnValue(
                returnValue, getReturnValueType(returnValue), mavContainer, webRequest);
    } // catch ...
}

源码30：HandlerMethodReturnValueHandlerComposite.java

@Override
public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
                              ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
    // 筛选出可以处理当前Controller返回的HandlerMethodReturnValueHandler对象
    HandlerMethodReturnValueHandler handler = selectHandler(returnValue, returnType);
    if (handler == null) {
        // throw ......
    }
    handler.handleReturnValue(returnValue, returnType, mavContainer, webRequest);
}

private HandlerMethodReturnValueHandler selectHandler(@Nullable Object value, MethodParameter returnType) {
    boolean isAsyncValue = isAsyncReturnValue(value, returnType);
    // 遍历HandlerMethodReturnValueHandler集合
    for (HandlerMethodReturnValueHandler handler : this.returnValueHandlers) {
        if (isAsyncValue && !(handler instanceof AsyncHandlerMethodReturnValueHandler)) {
            continue;
        }
        // 找出支持当前返回值类型的
        if (handler.supportsReturnType(returnType)) {
            return handler;
        }
    }
    return null;
}

由源码29-30 可知，处理方法返回值的handleReturnValue方法会先筛选出可以处理当前Controller返回的HandlerMethodReturnValueHandler对象，再调用其handleReturnValue方法处理返回值。

筛选HandlerMethodReturnValueHandler对象的selectHandler方法，是利用for循环遍历HandlerMethodReturnValueHandler对象集合，找出其中支持当前返回值类型的HandlerMethodReturnValueHandler对象。

借助Debug工具，可以发现可选的HandlerMethodReturnValueHandler对象有15个，示例项目选择的是RequestResponseBodyMethodProcessor。

筛选HandlerMethodReturnValueHandler对象
在示例项目中，UserController的test方法上标注了@ResponseBody注解，因此响应的是JSON数据。处理JSON数据响应的底层实现就是RequestResponseBodyMethodProcessor。

源码31：RequestResponseBodyMethodProcessor.java

@Override
public boolean supportsReturnType(MethodParameter returnType) {
    return (AnnotatedElementUtils.hasAnnotation(returnType.getContainingClass(), ResponseBody.class) ||
            returnType.hasMethodAnnotation(ResponseBody.class));
}

由源码31 可知，RequestResponseBodyMethodProcessor中supportsReturnType方法就是判断方法所在类或者方法上是否标注@ResponseBody注解。再一次印证RequestResponseBodyMethodProcessor是处理JSON数据响应的底层实现。

（iii）处理JSON数据响应

获取RequestResponseBodyMethodProcessor对象后，调用其handleReturnValue方法正式处理返回值。

源码32：RequestResponseBodyMethodProcessor.java

@Override
public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
                              ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
        throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {

    mavContainer.setRequestHandled(true);
    ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
    ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);
    // 使用JSON序列化的方式将方法返回的数据转化为文本
    // 并写入HttpServletResponse的输出流中
    writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage);
}

由源码32 可知，handleReturnValue方法会执行writeWithMessageConverters方法，使用JSON序列化的方式将方法返回的数据转化为文本，并写入HttpServletResponse的输出流中。

（iiii）处理视图返回

示例项目中是响应JSON数据，但在实际开发中也有可能是响应视图。对于返回视图和返回JSON数据，底层使用的HandlerMethodReturnValueHandler并不相同。

如果一个Controller方法要跳转视图，则方法的返回值一定是一个字符串，并且方法和类上都没有标注@ResponseBody注解，这种情况下底层使用的HandlerMethodReturnValueHandler是ViewNameMethodReturnValueHandler。

源码33：ViewNameMethodReturnValueHandler.java

@Override
public boolean supportsReturnType(MethodParameter returnType) {
    Class<?> paramType = returnType.getParameterType();
    // 判断返回值类型是否是CharSequence
    return (void.class == paramType || CharSequence.class.isAssignableFrom(paramType));
}

@Override
public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
                              ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {

    if (returnValue instanceof CharSequence) {
        String viewName = returnValue.toString();
        // 将String类型的返回值作为逻辑视图名放入ModelAndView容器中
        mavContainer.setViewName(viewName);
        if (isRedirectViewName(viewName)) {
            mavContainer.setRedirectModelScenario(true);
        }
    } else if (returnValue != null) {
        // should not happen
        // throw ...
    }
}

由源码33 可知，处理视图响应的handleReturnValue方法会将String类型的返回值作为逻辑视图名称，并放入ModelAndView容器ModelAndViewContainer对象中。

至此，invokeAndHandle方法执行完毕，Controller类中的方法已执行，ModelAndViewContainer中已经封装了响应视图名称，或者将需要响应的数据写入了HttpServletResponse中。

（e）包装ModelAndView

源码34：RequestMappingHandlerAdapter.java

protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
                                           HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ServletWebRequest webRequest = new ServletWebRequest(request, response);
    try {
        // 初始化参数绑定器 ...
        // 参数预绑定 ...
        // 创建方法执行对象 ...
        // 创建ModelAndView的容器ModelAndViewContainer ...（不重要）
        // 对异步请求的支持 ...（不重要）
        // 执行Controller的方法 ...
        
        // 包装ModelAndView
        return getModelAndView(mavContainer, modelFactory, webRequest);
    } // finally ...
}

private ModelAndView getModelAndView(ModelAndViewContainer mavContainer,
                                     ModelFactory modelFactory, NativeWebRequest webRequest) throws Exception {
    // ......
    
    // 取出容器中的ModelMap
    ModelMap model = mavContainer.getModel();
    // 取出视图名称，构造ModelAndView
    ModelAndView mav = new ModelAndView(mavContainer.getViewName(), model, mavContainer.getStatus());
    // ......
    return mav;
}

由源码34 可知，invokeHandlerMethod方法的最后一步是调用getModelAndView方法包装ModelAndView对象。在该方法在中会从上一步封装的ModelAndViewContainer对象中取出ModelMap和视图名称，构造成ModelAndView对象并返回。

简言之，getModelAndView方法完成了ModelAndViewContainer对象到ModelAndView对象的转换。

至此，invokeHandlerMethod方法执行完毕，HandlerAdapter的工作全部完成，流程回到DispatcherServlet的doDispatch方法。

12.4.4.6 再次回调拦截器

源码35：DispatcherServlet.java

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 {
            // 处理文件上传请求 ...
            // 获取可用的Handler ...
            // 获取HandlerAdapter ...
            // 回调拦截器 ...
            // 执行Handler ...
            
            // 再次回调拦截器
            mappedHandler.applyPostHandle(processedRequest, response, mv);
            // ......
}

源码36：HandlerExecutionChain.java

void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv)
        throws Exception {
    HandlerInterceptor[] interceptors = getInterceptors();
    if (!ObjectUtils.isEmpty(interceptors)) {
        // 此处是倒序回调
        for (int i = interceptors.length - 1; i >= 0; i--) {
            HandlerInterceptor interceptor = interceptors[i];
            interceptor.postHandle(request, response, this.handler, mv);
        }
    }
}

由源码35-36 可知，再次回调拦截器的applyPostHandle方法和 12.4.4.4 节的applyPreHandle的逻辑是几乎一样，不一样的是，这次回调拦截器的顺序是反过来的，调用的是拦截器的postHandle方法。

12.4.4.7 处理视图、解析异常

源码37：DispatcherServlet.java

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 {
            // 处理文件上传请求 ...
            // 获取可用的Handler ...
            // 获取HandlerAdapter ...
            // 回调拦截器 ...
            // 执行Handler ...
            // 再次回调拦截器 ...
            mappedHandler.applyPostHandle(processedRequest, response, mv);
        } // catch ...
        // 处理视图、解析异常
        processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
        
        // ......
}

由源码37 可知，DispatcherServlet的doDispatch方法的最后一个关键步骤是processDispatchResult方法，该方法会进行视图处理，以及解析整个请求处理中抛出的异常。

该方法分为三个步骤，下面拆解来看。

（1）处理异常

源码38：DispatcherServlet.java

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
                                   @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
                                   @Nullable Exception exception) throws Exception {

    boolean errorView = false;
    // 处理异常
    if (exception != null) {
        if (exception instanceof ModelAndViewDefiningException) {
            // logger ...
            mv = ((ModelAndViewDefiningException) exception).getModelAndView();
        } else {
            Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
            mv = processHandlerException(request, response, handler, exception);
            errorView = (mv != null);
        }
    }

    // ......
}

由源码38 可知，processDispatchResult会根据异常的类型做不同的处理。

DispatcherServlet在处理客户端发起的请求时，中间调用Controller或者Service等组件时抛出的异常都几乎不可能是ModelAndViewDefiningException（前面的源码分析也没有见过这个异常），因此if代码块不重要。

在else代码块中，会调用processHandlerException方法，该方法才是处理异常的核心方法。

源码39：DispatcherServlet.java

protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response,
                                               @Nullable Object handler, Exception ex) throws Exception {

    // ......
    
    // 从HandlerExceptionResolver集合中找到可以处理当前异常的
    // 构造成ModelAndView对象并返回
    ModelAndView exMv = null;
    if (this.handlerExceptionResolvers != null) {
        for (HandlerExceptionResolver resolver : this.handlerExceptionResolvers) {
            exMv = resolver.resolveException(request, response, handler, ex);
            if (exMv != null) {
                break;
            }
        }
    }
    // ......

    throw ex;
}

由源码39 可知，processHandlerException方法会从HandlerExceptionResolver集合中找到可以处理当前异常的，构造成ModelAndView对象并返回。

在示例项目中，CustomAdvice类标注了@ControllerAdvice注解，并且声明了标注@ExceptionHandler注解的方法，可实现全局统一异常处理。

@ControllerAdvice
public class CustomAdvice {

    @ExceptionHandler({Exception.class})
    public String customExceptionHandler(Exception ex) {
        System.out.println("自定义异常发生了，" + ex.getMessage());
        return "自定义异常返回";
    }

}

在UserController的test方法加一行代码：int i = 1/0，发起请求时一定会抛出异常，控制台的结果如下：

自定义异常发生了，/ by zero

可见，全局统一异常处理生效了。

（2）渲染视图

源码40：DispatcherServlet.java

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
                                   @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
                                   @Nullable Exception exception) throws Exception {
    // 处理异常 ...
    
    // 渲染视图
    if (mv != null && !mv.wasCleared()) {
        render(mv, request, response);
        if (errorView) {
            WebUtils.clearErrorRequestAttributes(request);
        }
    }

    // ......
}

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
    // 国际化处理 ...

    View view;
    String viewName = mv.getViewName();
    if (viewName != null) {
        // 根据视图名解析出视图
        view = resolveViewName(viewName, mv.getModelInternal(), locale, request);
        if (view == null) {
            // throw ...
        }
    } else {
        // 否则，直接获取视图；如果还没有视图，则抛出异常
        view = mv.getView();
        if (view == null) {
            // throw ...
        }
    }

    // logger ...
    try {
        if (mv.getStatus() != null) {
            response.setStatus(mv.getStatus().value());
        }
        // 渲染视图
        view.render(mv.getModelInternal(), request, response);
    } // catch ...
}

由源码40 可知，无论是正常响应还是抛出异常，最终都会生成一个ModelAndView对象，紧接着就要进行视图的渲染，而渲染视图的核心方法是render方法。

渲染视图的render方法会从ModelAndView中获取逻辑视图的名称，如果有名称则借助ViewResolver去匹配视图，如果成功匹配到则返回，如果匹配不到则抛出异常。匹配生成视图View对象后，执行view.render方法实际渲染视图。

（3）第三次回调拦截器

源码41：DispatcherServlet.java

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
                                   @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
                                   @Nullable Exception exception) throws Exception {
    // 处理异常 ...
    // 渲染视图 ...
    
    // 第三次回调拦截器
    if (mappedHandler != null) {
        mappedHandler.triggerAfterCompletion(request, response, null);
    }
}

源码42：HandlerExecutionChain.java

void triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, @Nullable Exception ex)
        throws Exception {
    HandlerInterceptor[] interceptors = getInterceptors();
    if (!ObjectUtils.isEmpty(interceptors)) {
        // 遍历拦截器，执行其afterCompletion方法
        for (int i = this.interceptorIndex; i >= 0; i--) {
            HandlerInterceptor interceptor = interceptors[i];
            try {
                interceptor.afterCompletion(request, response, this.handler, ex);
            } // catch ...
        }
    }
}

由源码41-42 可知，视图渲染完成后，最后的收尾动作是回调所有拦截器的afterCompletion方法。

这已经是第三次回调拦截器了，第一次执行拦截器的preHandle方法，第二次倒序执行拦截器的postHandle方法，第三次执行拦截器的afterCompletion方法。其中，第一次是在Handler方法执行之前执行的，第二次和第三次是在之后执行的。

拦截器执行流程
因此，控制台的输出如下：

拦截器的preHandle方法执行了...
请求参数 name=aaa
请求参数 time=Thu Feb 29 12:12:12 CST 2024
拦截器的postHandle方法执行了...
拦截器的afterCompletion方法执行了...

至此，processDispatchResult方法执行完毕，DispatcherServlet的doDispatch方法也执行完毕，一次完整的DispatcherServlet请求处理和响应完成了。

12.4.5 DispatcherServlet工作流程总结

DispatcherServlet工作全流程示意图如下：

DispatcherServlet工作全流程

1. 客户端向服务端发起请求，由DispatcherServlet接收请求；
2. DispatcherServlet委托HandlerMapping，根据本次请求的URL匹配合适的Controller方法；
3. HandlerMapping找到合适的Controller方法后，组合可以应用于当前请求的拦截器，并封装为一个HandlerExecutionChain对象返回给DispatcherServlet；
4. DispatcherServlet接收到HandlerExecutionChain对象后，委托HandlerAdapter，将该请求转发给选定的Handler；
5. Handler接收到请求后，实际执行Controller方法；
6. Controller方法执行完毕后返回一个ModelAndView对象给HandlerAdapter；
7. HandlerAdapter接收到ModelAndView对象后返回给DispatcherServlet；
8. DispatcherServlet接收到ModelAndView对象后，委托ViewResolver进行视图渲染；
9. ViewResolver视图渲染完成后返回给DispatcherServlet，由DispatcherServlet负责响应视图。