當前位置：首頁 >

springboot MVC视图解析流程源码分析

發布時間：2025/3/15 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 springboot MVC视图解析流程源码分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Servlet的基礎知識

為什么要先了解Servlet的知識呢，因為后面你會看到我們所熟悉的SpringMVC其實也是一個Servlet，只是它封裝了很多的東西并和Spring進行了整合，后面我們進行的源碼分析就是圍繞著Servlet的生命周期進行的，所以有必要了解一下Servlet相關的知識。
Servlet概念
全稱Java Servlet，是用Java編寫的服務器端程序。其主要功能在于交互式地瀏覽和修改數據，生成動態Web內容。Servlet運行于支持 Java應用的服務器中。從原理上講，Servlet可以響應任何類型的請求，但絕大多數情況下Servlet只用來擴展基于HTTP協議的Web服務器。
Servlet的工作原理
下面通過一張時序圖來理解Servlet的工作流程

從上面的時序圖總結如下：

首先客戶端請求接入
Servlet容器，比如Tomcat處理請求
Tomcat 創建HttpServletRequest對象，將請求的信息封裝到這個對象中。
Tomcat 創建HttpServletResponse對象, 此時是一個空的對象等待請求返回并填充
Tomcat調用service方法，最終傳遞到子類HttpServlet中
HttpServlet從request中獲取請求信息，處理完畢后將返回值信息封裝到HttpServletResponse對象
Tomcat容器返回處理后的信息

Servlet生命周期
打開Servlet源碼發現Servlet接口有幾個方法：

init()方法Tomcat創建Servlet時會調用
每次有請求來時Tomcat都會調用service()方法
請求結束時Tomcat會調用destroy()方法

public interface Servlet {//Servlet創建時會調用init方法進行初始化void init(ServletConfig var1) throws ServletException;ServletConfig getServletConfig();// 每次有新的請求來時都會調用void service(ServletRequest var1, ServletResponse var2) throws ServletException, IOException;String getServletInfo();// 請求結束時調用void destroy(); }

一個Servlet例子
寫一個AddUserServlet類繼承自HttpServlet（為什么要繼承這個類后面有說明）

public class AddUserServlet extends HttpServlet {private static final long serialVersionUID = 1L;protected void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {response.setContentType("text/plain;charset=utf8");response.getWriter().write("添加成功");}protected void doPost(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {doGet(request, response);}}

總結：

Servlet實際上是tomcat容器生成的，調用init方法可以初始化。他有別于普通java的執行過程，普通java需要main方法;但是web項目由于是服務器控制的創建和銷毀，所以servlet的訪問也需要tomcat來控制。通過tomcat訪問 servlet的機制是通過使用http協議的URL來訪問，所以servlet的配置完想要訪問，必須通過URL來訪問，所以沒有main方法。

下面正式開始mvc過程的源碼分析，先看一張完整的DispatcherServlet的流程圖

一、方法到達service

當Spring MVC啟動完畢，就可以開始準備接受來自客戶端的請求了。根據Servlet規范，請求必須先發送到service()方法。在Spring MVC中，該方法實現在DispatcherServlet的父類FrameworkServlet：

protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());if (HttpMethod.PATCH != httpMethod && httpMethod != null) {super.service(request, response);} else {this.processRequest(request, response);} }

根據HttpMethod，即GET、POST、PUT、DELETE等請求類型來分派請求。這里將請求分為兩類：PATCH&空，以及其他請求,對于前者，調用processRequest處理，否則調用父類的service方法處理。

processRequest方法
它首先備份了請求的LocaleContext和RequestAttributes，然后copy了一份新的，并綁定到當前線程：

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

initContextHolders就是將localeContext和requestAttributes兩個對象存入Holder。并且在方法最后，將備份的數據恢復過來，并觸發請求處理完畢事件：

finally {resetContextHolders(request, previousLocaleContext, previousAttributes);if (requestAttributes != null) {requestAttributes.requestCompleted();}logResult(request, response, failureCause, asyncManager);publishRequestHandledEvent(request, response, startTime, failureCause); }

備份和綁定操作完成后，調用它的核心方法doService，這是一個抽象方法，在DispatcherServlet實現，首先也是備份屬性，并且最后也進行了恢復：

Map<String, Object> 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));}} } ... finally {if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {if (attributesSnapshot != null) {restoreAttributesAfterInclude(request, attributesSnapshot);}} }

然后為request綁定Web容器、本地化解析器、主題解析器、主題、FlashMap管理器、inputFlashMap/outputFlashMap等屬性，并調用doDispatch方法。

父類service方法
在父類的方法中，根據HttpMethod類型，分別調用了doXXX方法：

protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {String method = req.getMethod();if (method.equals(METHOD_GET)) {...doGet(req, resp);...} else if (method.equals(METHOD_HEAD)) {...doHead(req, resp);} else if (method.equals(METHOD_POST)) {doPost(req, resp); } else if (method.equals(METHOD_PUT)) {doPut(req, resp);} else if (method.equals(METHOD_DELETE)) {doDelete(req, resp);} else if (method.equals(METHOD_OPTIONS)) {doOptions(req,resp);} else if (method.equals(METHOD_TRACE)) {doTrace(req,resp);} else {String errMsg = lStrings.getString("http.method_not_implemented");Object[] errArgs = new Object[1];errArgs[0] = method;errMsg = MessageFormat.format(errMsg, errArgs);resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED, errMsg);} }

對于未知類型的Http請求，則不進行分派，直接返回錯誤。這些do方法都實現在FrameworkServlet中，實際上都最終調用了processRequest，體現了集中入口、分協議轉發、統一處理的特點。

二、doDispatch方法

先上一張流程圖（來源于網絡）：

很清晰地描述了doDispatch方法的流程。

檢查上傳請求 —— checkMultipart方法
由于Spring MVC默認不支持文件上傳，所以必須在請求處理的最開始就進行檢查，以免在處理過程中才發現沒有配置文件上傳解析器，導致處理失敗。checkMultipart方法源碼如下：

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.trace("Request already resolved to MultipartHttpServletRequest, e.g. by MultipartFilter");}}else if (hasMultipartException(request)) {logger.debug("Multipart resolution previously failed for current request - " + "skipping re-resolution for undisturbed error rendering");}else {try {return this.multipartResolver.resolveMultipart(request);}catch (MultipartException ex) {if (request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE) != null) {logger.debug("Multipart resolution failed for error dispatch", ex);}else {throw ex;}}}}return request; }

首先檢查是否配置了文件上傳解析器，以及請求中是否包含multipart部分，沒有的話就可以不必繼續了。

然后檢查請求是否已經被處理過，或者曾經處理過但是有未解決的異常，這兩種情況也不需要繼續處理。如果請求還沒處理過，則用文件上傳解析器進行解析，成功解析后，將生成一個MultipartHttpServletRequest對象。這里以CommonsMultpartResolver為例說明，其resolveMultipart方法源碼如下：

public MultipartHttpServletRequest resolveMultipart(final HttpServletRequest request) throws MultipartException {if (this.resolveLazily) {return new DefaultMultipartHttpServletRequest(request) {@Overrideprotected void initializeMultipart() {MultipartParsingResult parsingResult = parseRequest(request);setMultipartFiles(parsingResult.getMultipartFiles());setMultipartParameters(parsingResult.getMultipartParameters());setMultipartParameterContentTypes(parsingResult.getMultipartParameterContentTypes());}};}else {MultipartParsingResult parsingResult = parseRequest(request);return new DefaultMultipartHttpServletRequest(request, parsingResult.getMultipartFiles(),parsingResult.getMultipartParameters(), parsingResult.getMultipartParameterContentTypes());} }

不難看出，懶加載方式下，只是重寫了initializeMultipart方法，真正的解析還要等后面，非懶加載模式下，直接就進行解析了：

protected MultipartParsingResult parseRequest(HttpServletRequest request) throws MultipartException {String encoding = determineEncoding(request);FileUpload fileUpload = prepareFileUpload(encoding);try {List<FileItem> fileItems = ((ServletFileUpload) fileUpload).parseRequest(request);return parseFileItems(fileItems, encoding);}catch (FileUploadBase.SizeLimitExceededException ex) {throw new MaxUploadSizeExceededException(fileUpload.getSizeMax(), ex);}catch (FileUploadBase.FileSizeLimitExceededException ex) {throw new MaxUploadSizeExceededException(fileUpload.getFileSizeMax(), ex);}catch (FileUploadException ex) {throw new MultipartException("Failed to parse multipart servlet request", ex);} }

這里有三種異常情況：請求本身太大、上傳的文件太大、Request無法解析。

determineEncoding很簡單，就是讀取請求中character-encoding屬性，沒有就使用默認編碼ISO-8859-1。
prepareFileUpload也很簡單，就是創建一個FileUpload實例，賦一些屬性：

protected FileUpload prepareFileUpload(@Nullable String encoding) {FileUpload fileUpload = getFileUpload();FileUpload actualFileUpload = fileUpload;if (encoding != null && !encoding.equals(fileUpload.getHeaderEncoding())) {actualFileUpload = newFileUpload(getFileItemFactory());actualFileUpload.setSizeMax(fileUpload.getSizeMax());actualFileUpload.setFileSizeMax(fileUpload.getFileSizeMax());actualFileUpload.setHeaderEncoding(encoding);}return actualFileUpload; }

FileUpload類的parseRequest方法可以用于解析MultipartServletRequest，生成文件對象列表，它的原理就是讀取請求中的數據，構造FileItem對象，然后存入列表中，去除了catch塊之后的代碼如下：：

public List<FileItem> parseRequest(RequestContext ctx) throws FileUploadException {List<FileItem> items = new ArrayList<FileItem>();boolean successful = false;FileItemIterator iter = getItemIterator(ctx);FileItemFactory fac = getFileItemFactory();if (fac == null) {throw new NullPointerException("No FileItemFactory has been set.");}while (iter.hasNext()) {final FileItemStream item = iter.next();final String fileName = ((FileItemIteratorImpl.FileItemStreamImpl) item).name;FileItem fileItem = fac.createItem(item.getFieldName(), item.getContentType(),item.isFormField(), fileName);items.add(fileItem);Streams.copy(item.openStream(), fileItem.getOutputStream(), true);final FileItemHeaders fih = item.getHeaders();fileItem.setHeaders(fih);}successful = true;if (!successful) {for (FileItem fileItem : items) {try {fileItem.delete();} catch (Exception ignored) {}}} }

getItemIterator方法從請求中讀取了Content-Type、Content-Length、Character-Encoding等屬性，構造了MultipartStream流，并返回了一個迭代器實例。每當調用hasNext時，就會調用findNextItem方法，解析MultipartStream并生成FileItemStream對象。

假如在生成FileItem的過程中拋出異常，則會執行fileItem.delete()方法顯式清除臨時文件。
FileItem是apache commons包的類，還需要進一步解析為Spring的MultipartParsingResult對象。此處根據FileItem對象里面封裝的數據是一個普通文本表單字段，還是一個文件表單字段采用不同的處理方式。

對于文本表單字段，調用getString方法讀取文件內容，然后存入multipartParameters中，讀取Content-Type屬性，存入multipartParameterContentTypes中

String value; String partEncoding = determineEncoding(fileItem.getContentType(), encoding); try {value = fileItem.getString(partEncoding); } catch (UnsupportedEncodingException ex) {value = fileItem.getString(); } String[] curParam = multipartParameters.get(fileItem.getFieldName()); if (curParam == null) {multipartParameters.put(fileItem.getFieldName(), new String[] {value}); } else {String[] newParam = StringUtils.addStringToArray(curParam, value);multipartParameters.put(fileItem.getFieldName(), newParam); } multipartParameterContentTypes.put(fileItem.getFieldName(), fileItem.getContentType());

對于文件表單字段，則直接創建CommonsMultipartFile對象，并添加到multipartFiles：

CommonsMultipartFile file = createMultipartFile(fileItem); multipartFiles.add(file.getName(), file);protected CommonsMultipartFile createMultipartFile(FileItem fileItem) {CommonsMultipartFile multipartFile = new CommonsMultipartFile(fileItem);multipartFile.setPreserveFilename(this.preserveFilename);return multipartFile; }

無論如何，都將上述三個加了粗的Map對象傳入MultipartParsingResult的構造函數，返回一個新實例。

查找處理器 —— getHandler方法

該方法實際就是遍歷所有HandlerMapping，逐個調用其getHandler方法，看它對應的Handler能否處理該請求，假如某個HandlerMapping滿足條件，則直接返回(也就是執行鏈)，否則繼續循環。假如直到遍歷完畢還沒有結果，則返回null。

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

getHandler方法實現在AbstractHandlerMapping類中，關鍵源碼如下：

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {Object handler = getHandlerInternal(request);if (handler == null) {handler = getDefaultHandler();}if (handler == null) {return null;}if (handler instanceof String) {String handlerName = (String) handler;handler = obtainApplicationContext().getBean(handlerName);}HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);if (CorsUtils.isCorsRequest(request)) {CorsConfiguration globalConfig = this.corsConfigurationSource.getCorsConfiguration(request);CorsConfiguration handlerConfig = getCorsConfiguration(handler, request);CorsConfiguration config = (globalConfig != null ? globalConfig.combine(handlerConfig) : handlerConfig);executionChain = getCorsHandlerExecutionChain(request, executionChain, config);}return executionChain; }

defaultHandler如果沒有顯式注入的話一般都是null，所以不用考慮。顯然核心方法就是getHandlerInternal和getHandlerExecutionChain，以及下面的CORS處理邏輯。

RequestMappingHandlerMapping 的 getHandlerInternal 方法實現

這里仍以RequestMappingHandlerMapping為例說明。其getHandlerInternal方法實際上位于父類AbstractHandlerMethodMapping：

protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);this.mappingRegistry.acquireReadLock();try {HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);}finally {this.mappingRegistry.releaseReadLock();} }

首先是對URL進行截取：

public String getLookupPathForRequest(HttpServletRequest request) {if (this.alwaysUseFullPath) {return getPathWithinApplication(request);}String rest = getPathWithinServletMapping(request);if (!"".equals(rest)) {return rest;}else {return getPathWithinApplication(request);} }

先來看getPathWithinApplication方法，它獲取了request的contextPath屬性和URI，然后把URI中和contextPath相同的部分切除，返回剩余的部分：

public String getPathWithinApplication(HttpServletRequest request) {String contextPath = getContextPath(request);String requestUri = getRequestUri(request);String path = getRemainingPath(requestUri, contextPath, true);if (path != null) {return (StringUtils.hasText(path) ? path : "/");}else {return requestUri;} }

舉個例子，假如contextPath為"/hello"，URI為"/hello/index.html"，則返回"/index.html"。

再來看getPathWithinServletMapping方法，首先也是調用了getPathWithinApplication，然后獲取了request中的servletPath屬性，然后將pathWithinApp中的"//“替換為”/"。servletPath就是URI中分號之前的部分，例如：URI為"/hello/index.html;a=1;b=2"，則其servletPath就是"/hello/index.html"。然后把URI中和servletPath相同的部分切除，保留剩余的部分：

public String getPathWithinServletMapping(HttpServletRequest request) {String pathWithinApp = getPathWithinApplication(request);String servletPath = getServletPath(request);String sanitizedPathWithinApp = getSanitizedPath(pathWithinApp);String path;if (servletPath.contains(sanitizedPathWithinApp)) {path = getRemainingPath(sanitizedPathWithinApp, servletPath, false);}else {path = getRemainingPath(pathWithinApp, servletPath, false);}if (path != null) {return path;}else {String pathInfo = request.getPathInfo();if (pathInfo != null) {return pathInfo;}if (!this.urlDecode) {path = getRemainingPath(decodeInternal(request, pathWithinApp), servletPath, false);if (path != null) {return pathWithinApp;}}return servletPath;} }

截取URL之后，就可以進行HandlerMethod的匹配了，首先要看下有沒有能完全匹配上的：

List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath); if (directPathMatches != null) {addMatchingMappings(directPathMatches, matches, request); }

假如沒有，則對所有HandlerMethods進行查找，找出其中最好的一個繼續處理。Comparator按照請求類型、patternsCondition、paramsCondition、headersCondition、consumesCondition、producesCondition、methodsCondition、customConditionHolder的順序比較各屬性：

Comparator<Match> comparator = new MatchComparator(getMappingComparator(request)); matches.sort(comparator); Match bestMatch = matches.get(0); if (matches.size() > 1) {if (CorsUtils.isPreFlightRequest(request)) {return new HandlerMethod(new EmptyHandler(), ClassUtils.getMethod(EmptyHandler.class, "handle"));}Match secondBestMatch = matches.get(1);if (comparator.compare(bestMatch, secondBestMatch) == 0) {Method m1 = bestMatch.handlerMethod.getMethod();Method m2 = secondBestMatch.handlerMethod.getMethod();String uri = request.getRequestURI();throw new IllegalStateException("Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}");} } request.setAttribute(HandlerMapping.class.getName() + ".bestMatchingHandler", bestMatch.handlerMethod); handleMatch(bestMatch.mapping, lookupPath, request); return bestMatch.handlerMethod;

handleMatch方法在子類RequestMappingInfoHandlerMapping進行了重寫，除了將匹配/比較結果存放到request中，還從request里解析了@MatrixVariable和@PathVariable注解的參數的值，也一并存入request。

假如沒有匹配到HandlerMethod（比如根本就沒有注冊任何HandlerMethod），就會執行handleNoMatch方法，該方法也被重寫，實際邏輯就是再遍歷一次RequestMappingInfo列表，看看是不是有漏網之魚，如果還是沒有，則拋出異常。

然后需要對HandlerMethod進行實例化。HandlerMethod在創建時（createHandlerMethod方法），傳入的handler參數實際是BeanName，顯然不包含實例，也就不可能進行方法調用，所以還需要進行實例化：

public HandlerMethod createWithResolvedBean() {Object handler = this.bean;if (this.bean instanceof String) {String beanName = (String) this.bean;handler = this.beanFactory.getBean(beanName);}return new HandlerMethod(this, handler); }

getHandlerExecutionChain方法
該方法實質就是將Handler攔截器加入到處理鏈中，以便攔截器生效：

protected HandlerExecutionChain getHandlerExecutionChain(Object handler, HttpServletRequest request) {HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ?(HandlerExecutionChain) handler : new HandlerExecutionChain(handler));String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);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; }

CORS配置

首先獲取全局CORS配置，實際就是從Map中獲取值：

public CorsConfiguration getCorsConfiguration(HttpServletRequest request) {String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);for (Map.Entry<String, CorsConfiguration> entry : this.corsConfigurations.entrySet()) {if (this.pathMatcher.match(entry.getKey(), lookupPath)) {return entry.getValue();}}return null; }

然后是獲取處理器的CORS配置，本質上和上面的一樣：

// in AbstractHandlerMethodMapping.java protected CorsConfiguration getCorsConfiguration(Object handler, HttpServletRequest request) {CorsConfiguration corsConfig = super.getCorsConfiguration(handler, request);if (handler instanceof HandlerMethod) {HandlerMethod handlerMethod = (HandlerMethod) handler;if (handlerMethod.equals(PREFLIGHT_AMBIGUOUS_MATCH)) {return AbstractHandlerMethodMapping.ALLOW_CORS_CONFIG;}else {CorsConfiguration corsConfigFromMethod = this.mappingRegistry.getCorsConfiguration(handlerMethod);corsConfig = (corsConfig != null ? corsConfig.combine(corsConfigFromMethod) : corsConfigFromMethod);}}return corsConfig; }// in AbstractHandlerMapping.java protected CorsConfiguration getCorsConfiguration(Object handler, HttpServletRequest request) {Object resolvedHandler = handler;if (handler instanceof HandlerExecutionChain) {resolvedHandler = ((HandlerExecutionChain) handler).getHandler();}if (resolvedHandler instanceof CorsConfigurationSource) {return ((CorsConfigurationSource) resolvedHandler).getCorsConfiguration(request);}return null; }

然后將本地配置和全局配置融合，用于創建CORS攔截器，添加到處理器執行鏈上：

protected HandlerExecutionChain getCorsHandlerExecutionChain(HttpServletRequest request,HandlerExecutionChain chain, @Nullable CorsConfiguration config) {if (CorsUtils.isPreFlightRequest(request)) {HandlerInterceptor[] interceptors = chain.getInterceptors();chain = new HandlerExecutionChain(new PreFlightHandler(config), interceptors);}else {chain.addInterceptor(new CorsInterceptor(config));}return chain; }

和上面的getHandlerExecutionChain原理一致，不再贅述。

DispatcherServlet對沒有找到Handler的處理

盡管在查找HandlerMethod的過程中，如果出現noMatch會拋出異常，但是Spring還是在DispatcherServlet進行了處理，原因很簡單：服務器拋出異常，僅有自己可以感知到，還必須通過Response返回錯誤，才能讓客戶端也感知到：

protected void noHandlerFound(HttpServletRequest request, HttpServletResponse response) throws Exception {if (pageNotFoundLogger.isWarnEnabled()) {pageNotFoundLogger.warn("No mapping for " + request.getMethod() + " " + getRequestUri(request));}if (this.throwExceptionIfNoHandlerFound) {throw new NoHandlerFoundException(request.getMethod(), getRequestUri(request),new ServletServerHttpRequest(request).getHeaders());}else {response.sendError(HttpServletResponse.SC_NOT_FOUND);} }

尋找HandlerAdapter —— getHandlerAdapter方法(用于解析參數)

這里實現很簡單：遍歷適配器列表，看哪個可以支持找到的Handler，就返回哪個。

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {if (this.handlerAdapters != null) {for (HandlerAdapter adapter : this.handlerAdapters) {if (adapter.supports(handler)) {return adapter;}}}throw new ServletException("No adapter for handler [" + handler + "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler"); }

對于RequestMappingHandlerAdapter來說，僅僅檢查了handler是否是HandlerMethod類型，是則返回true。

緩存（LastModified屬性）的處理

服務器具有緩存機制，在用戶第一次請求某資源時，如果請求成功，服務器會返回HTTP 200，并在響應頭中添加一個LastModified字段，記錄此資源在服務器上的最后更新時間；當再次請求該資源時，瀏覽器會在請求頭中加上If-Modified-Since字段，詢問服務器該資源自此時間起是否更新過，如果沒有更新，則直接返回HTTP 304，而不返回資源，這樣就節省了帶寬。

Spring在獲取了HandlerAdapter后，就會檢查Handler是否支持緩存機制，如果支持，且資源未過期，則直接返回：

String method = request.getMethod(); boolean isGet = "GET".equals(method); if (isGet || "HEAD".equals(method)) {long lastModified = ha.getLastModified(request, mappedHandler.getHandler());if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {return;} }

可見資源更新時間是由HandlerAdapter決定的，這里以SimpleControllerHandlerAdapter的實現為例：

public long getLastModified(HttpServletRequest request, Object handler) {if (handler instanceof LastModified) {return ((LastModified) handler).getLastModified(request);}return -1L; }

意思很簡單：如果Handler（即Controller類）實現了LastModified接口，則調用其getLastModified方法獲取，否則返回-1。

checkNotModified就是驗證獲取到的時間是否過期，并更新Response：

if (validateIfUnmodifiedSince(lastModifiedTimestamp)) {if (this.notModified && response != null) {response.setStatus(HttpStatus.PRECONDITION_FAILED.value());}return this.notModified; } boolean validated = validateIfNoneMatch(etag); if (!validated) {validateIfModifiedSince(lastModifiedTimestamp); } if (response != null) {boolean isHttpGetOrHead = SAFE_METHODS.contains(getRequest().getMethod());if (this.notModified) {response.setStatus(isHttpGetOrHead ?HttpStatus.NOT_MODIFIED.value() : HttpStatus.PRECONDITION_FAILED.value());}if (isHttpGetOrHead) {if (lastModifiedTimestamp > 0 && parseDateValue(response.getHeader(LAST_MODIFIED)) == -1) {response.setDateHeader(LAST_MODIFIED, lastModifiedTimestamp);}if (StringUtils.hasLength(etag) && response.getHeader(ETAG) == null) {response.setHeader(ETAG, padEtagIfNecessary(etag));}} } return this.notModified;

validateIfUnmodifiedSince首先對剛剛獲取到的資源更新時間進行判斷，如果小于0直接返回false，否則解析If-Modified-Since屬性并進行比較：

private boolean validateIfUnmodifiedSince(long lastModifiedTimestamp) {if (lastModifiedTimestamp < 0) {return false;}long ifUnmodifiedSince = parseDateHeader(IF_UNMODIFIED_SINCE);if (ifUnmodifiedSince == -1) {return false;}this.notModified = (ifUnmodifiedSince < (lastModifiedTimestamp / 1000 * 1000));return true; }

如果validateIfUnmodifiedSince返回了false，則需要進一步判斷，由于調用checkNotModified方法時沒有傳入etag，所以validateIfNoneMatch必定返回false，因此會調用validateIfModifiedSince再次判斷，內容和validateIfUnmodifiedSince類似，只是最后面的小于號換成了大于等于號。

如果經過兩次判斷，確認了資源未修改，則可以對repsonse進行更新。

攔截器發揮作用 —— preHandler、postHandler和afterCompletion

在進行了上面一系列預處理后，就可以正式開始使用Handler處理請求了。在Servlet規范中，設計了filter組件，可以在每個Web請求前后對它做處理，顯然這種處理粒度太粗。Spring MVC增加了攔截器的概念，從HandlerMapping初始化和Handler查找的過程中，我們可以看到它的身影。

攔截器接口HandlerInterceptor定義了三個方法：preHandle、postHandle、afterCompletion，分別作用于處理器方法調用前后、處理器執行鏈全部執行后。在doDispatch方法中，通過applyPreHandle、applyPostHandle和triggerAfterCompletion來調用處理器執行鏈上所有攔截器的對應方法。

applyPreHandle/applyPostHandle就是遍歷所有攔截器，觸發其preHandle/postHandle方法，比較有意思的是applyPreHandle，當preHandle返回false時，它會嘗試調用afterCompletion方法。閱讀HandlerInterceptor接口注釋后發現，preHandle方法如果返回true，表示應當由下一個攔截器或者處理器繼續處理，否則可以認為response對象已經被該處理鏈處理過了，不需要重復處理，應當中斷：

boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {HandlerInterceptor[] interceptors = getInterceptors();if (!ObjectUtils.isEmpty(interceptors)) {for (int i = 0; i < interceptors.length; i++) {HandlerInterceptor interceptor = interceptors[i];if (!interceptor.preHandle(request, response, this.handler)) {triggerAfterCompletion(request, response, null);return false;}this.interceptorIndex = i;}}return true; }

處理請求 —— handle方法、applyDefaultViewName方法

當執行鏈中所有的preHandle方法都觸發之后，就可以調用處理器來真正處理請求了。這里調用了HandlerAdapter的handle方法處理，以RequestMappingHandlerAdapter為例，它的handle方法又調用了handleInternal方法：

protected ModelAndView handleInternal(HttpServletRequest request,HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {ModelAndView mav;checkRequest(request);if (this.synchronizeOnSession) {HttpSession session = request.getSession(false);if (session != null) {Object mutex = WebUtils.getSessionMutex(session);synchronized (mutex) {mav = invokeHandlerMethod(request, response, handlerMethod);}}else {mav = invokeHandlerMethod(request, response, handlerMethod);}}else {mav = invokeHandlerMethod(request, response, handlerMethod);}... }

synchronizedOnSession的作用是，讓同一個Session的請求串行執行，默認false。

6.1 請求檢查 checkRequest

首先進行正式處理前的最后一次檢查，這里檢查了請求類型是否被支持，以及是否包含必需的Session對象：

protected final void checkRequest(HttpServletRequest request) throws ServletException {String method = request.getMethod();if (this.supportedMethods != null && !this.supportedMethods.contains(method)) {throw new HttpRequestMethodNotSupportedException(method, this.supportedMethods);}if (this.requireSession && request.getSession(false) == null) {throw new HttpSessionRequiredException("Pre-existing session required but none found");} }

6.2 觸發處理器方法 invokeHandlerMethod

在該方法的第一段，對傳入的三個參數：request、response、handlerMethod進行了包裝和解析，創建了接下來觸發方法需要的組件：

ServletWebRequest webRequest = new ServletWebRequest(request, response); WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod); ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory); ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(handlerMethod); if (this.argumentResolvers != null) {invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers); } if (this.returnValueHandlers != null) {invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers); } invocableMethod.setDataBinderFactory(binderFactory); invocableMethod.setParameterNameDiscoverer(this.parameterNameDiscoverer);

getDataBinderFactory主要做了三件事：

取出handlerMethod所在類下被注解了@InitBinder的方法，以及@ControllerAdvice類下被注解了@InitBinder的方法
將這些方法封裝為InvocableHandlerMethod，設置參數綁定解析器和參數綁定工廠，并添加到列表中
使用上一步得到的列表創建一個ServletRequestDataBinderFactory并返回

getModelFactory方法的主要流程和getDataBidnerFactory差不多，只不過第一步搜索的是@ModelAttribute注解的方法，第三步創建的是ModelFactory而已。

createInvocableHandlerMethod則是將傳入的HandlerMethod對象直接封裝為ServletInvocableHandlerMethod。

接下來，將初始化HandlerAdapter時配置的各種解析器，以及剛剛創建的binderFactory對象綁定到處理器方法上。

方法的第二段主要創建和配置了邏輯視圖容器及異步管理器對象：

ModelAndViewContainer mavContainer = new ModelAndViewContainer(); mavContainer.addAllAttributes(RequestContextUtils.getInputFlashMap(request)); modelFactory.initModel(webRequest, mavContainer, invocableMethod); mavContainer.setIgnoreDefaultModelOnRedirect(this.ignoreDefaultModelOnRedirect);AsyncWebRequest asyncWebRequest = WebAsyncUtils.createAsyncWebRequest(request, response); asyncWebRequest.setTimeout(this.asyncRequestTimeout);WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); asyncManager.setTaskExecutor(this.taskExecutor); asyncManager.setAsyncWebRequest(asyncWebRequest); asyncManager.registerCallableInterceptors(this.callableInterceptors); asyncManager.registerDeferredResultInterceptors(this.deferredResultInterceptors);

中間還處理器方法的ModelMap進行了處理，實際就是觸發剛剛找到的所有@ModelAttribute方法，將可以觸發的都觸發，把該添加到ModelMap的屬性都添加進來。

假如需要異步處理，則將ServletInvocableHandlerMethod對象進一步封裝為ConcurrentResultHandlerMethod：

if (asyncManager.hasConcurrentResult()) {Object result = asyncManager.getConcurrentResult();mavContainer = (ModelAndViewContainer) asyncManager.getConcurrentResultContext()[0];asyncManager.clearConcurrentResult();invocableMethod = invocableMethod.wrapConcurrentResult(result); }

第三段就是調用處理器方法，并取出處理結果（邏輯視圖），如果是異步處理，則先返回null，等異步處理完了再獲取：

invocableMethod.invokeAndHandle(webRequest, mavContainer); if (asyncManager.isConcurrentHandlingStarted()) {return null; } return getModelAndView(mavContainer, modelFactory, webRequest);

invokeAndHandle邏輯很簡單：使用Method.invoke方法反射調用，然后調用初始化HandlerAdapter時配置的返回值處理器進行處理，中間還處理了一下無返回值或出現響應錯誤的情況：

public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,Object... providedArgs) throws Exception {Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);setResponseStatus(webRequest);if (returnValue == null) {if (isRequestNotModified(webRequest) || getResponseStatus() != null || mavContainer.isRequestHandled()) {mavContainer.setRequestHandled(true);return;}}else if (StringUtils.hasText(getResponseStatusReason())) {mavContainer.setRequestHandled(true);return;}mavContainer.setRequestHandled(false);try {this.returnValueHandlers.handleReturnValue(returnValue, getReturnValueType(returnValue), mavContainer, webRequest);}catch (Exception ex) {throw ex;} }

可以看出，如果出現無返回值或者響應錯誤，則對邏輯視圖容器標記處理完成，而順利執行反而不做標記，這么做的原因在getModelAndView方法里：

private ModelAndView getModelAndView(ModelAndViewContainer mavContainer,ModelFactory modelFactory, NativeWebRequest webRequest) throws Exception {modelFactory.updateModel(webRequest, mavContainer);if (mavContainer.isRequestHandled()) {return null;}ModelMap model = mavContainer.getModel();ModelAndView mav = new ModelAndView(mavContainer.getViewName(), model, mavContainer.getStatus());if (!mavContainer.isViewReference()) {mav.setView((View) mavContainer.getView());}if (model instanceof RedirectAttributes) {Map<String, ?> flashAttributes = ((RedirectAttributes) model).getFlashAttributes();HttpServletRequest request = webRequest.getNativeRequest(HttpServletRequest.class);if (request != null) {RequestContextUtils.getOutputFlashMap(request).putAll(flashAttributes);}}return mav; }

如果標記了請求已處理，則不會獲取處理結果。這里將ModelMap和ViewName、Status等屬性封裝為ModelAndView邏輯視圖對象，進行返回。對于視圖引用和重定向請求，還進行了特殊處理。值得一提的是重定向的處理，這里獲取到了在本篇1.1節配置的outputFlashMap對象。

在整個方法調用完后，通過finally塊執行了ServletWebRequest的requestCompleted方法，該方法源碼如下：

public void requestCompleted() {executeRequestDestructionCallbacks();updateAccessedSessionAttributes();this.requestActive = false; }

這里執行了request中設置的析構回調，并更新了會話中的屬性。

6.3 響應頭處理

在handle方法處理完畢后，handleInternal方法還對響應頭進行了處理：

if (!response.containsHeader("Cache-Control")) {if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) {applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers);}else {prepareResponse(response);} } return mav;

getSessionAttributesHandler返回了當前處理器類型對應的SessionAttributesHandler，如果沒有就新建一個，不過實際上在創建ModelFactory的時候就已經調用過這個方法了，也就是說，進行到響應頭處理這一步時，是肯定存在SessionAttributesHandler的，而且在上一步最后獲取處理結果時，調用的updateModel已經將會話屬性sessionAttributes保存進去了。也就是說，除非會話中不包含任何屬性，否則是肯定會進入applyCacheSeconds分支的。

applyCacheSeconds方法中，最外層的if語句判斷的兩個條件，默認情況下都不成立，即會進入else分支。cacheSeconds參數（即 RequestMappingHandlerAdapter 的 cacheSecondsForSessionAttributeHandlers 屬性）默認為0，useCacheControlNoStore默認為true，所以cControl在默認情況下是通過noStore方法創建的一個noStore屬性為true的實例：

protected final void applyCacheSeconds(HttpServletResponse response, int cacheSeconds) {if (this.useExpiresHeader || !this.useCacheControlHeader) {if (cacheSeconds > 0) {cacheForSeconds(response, cacheSeconds);}else if (cacheSeconds == 0) {preventCaching(response);}}else {CacheControl cControl;if (cacheSeconds > 0) {cControl = CacheControl.maxAge(cacheSeconds, TimeUnit.SECONDS);if (this.alwaysMustRevalidate) {cControl = cControl.mustRevalidate();}}else if (cacheSeconds == 0) {cControl = (this.useCacheControlNoStore ? CacheControl.noStore() : CacheControl.noCache());}else {cControl = CacheControl.empty();}applyCacheControl(response, cControl);} }

applyCacheControl就是根據傳入的CacheControl對象，對response進行修改：

protected final void applyCacheControl(HttpServletResponse response, CacheControl cacheControl) {String ccValue = cacheControl.getHeaderValue();if (ccValue != null) {response.setHeader("Cache-Control", ccValue);if (response.containsHeader("Pragma")) {response.setHeader("Pragma", "");}if (response.containsHeader("Expires")) {response.setHeader("Expires", "");}} }

至于prepareResponse分支，實際也調用了applyCacheControl和applyCacheSeconds兩個方法：

protected final void prepareResponse(HttpServletResponse response) {if (this.cacheControl != null) {applyCacheControl(response, this.cacheControl);}else {applyCacheSeconds(response, this.cacheSeconds);}if (this.varyByRequestHeaders != null) {for (String value : getVaryRequestHeadersToAdd(response, this.varyByRequestHeaders)) {response.addHeader("Vary", value);}} }

6.4 doDispatch的異步處理

在6.2中，如果請求需要異步處理，則不會獲取處理結果，而是直接返回，在doDispatch中也是這樣處理的：

if (asyncManager.isConcurrentHandlingStarted()) {return; }

不過doDispatch在finally塊中又進行了一次處理：

finally {if (asyncManager.isConcurrentHandlingStarted()) {if (mappedHandler != null) {mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);}}else {if (multipartRequestParsed) {cleanupMultipart(processedRequest);}} }

mappedHandler在applyAfterConcurrentHandlingStarted方法中，調用了AsyncHandlerInterceptor實例對請求和響應進行處理。

6.5 設置默認視圖名 —— applyDefaultViewName

這里的邏輯很簡單，假如邏輯視圖不是視圖引用（即其view屬性是個String對象），則用RequestToViewNameTranslator生成一個默認名稱：

private void applyDefaultViewName(HttpServletRequest request, @Nullable ModelAndView mv) throws Exception {if (mv != null && !mv.hasView()) {String defaultViewName = getDefaultViewName(request);if (defaultViewName != null) {mv.setViewName(defaultViewName);}} }

處理分派結果 —— processDispatchResult
處理器執行鏈對請求處理完成后，產生了ModelAndView邏輯視圖對象，但是：

邏輯視圖還不是我們看到的網頁或數據，還需要進一步渲染；
如果處理過程中出現了異常，也需要進行集中處理；
afterCompletion方法還沒有觸發

因此Spring MVC提供了processDispatchResult對上述三個問題進行處理。

7.1 異常處理

在doDispatch方法中，如果捕獲了異常，就把異常賦給dispatchException對象，通過方法調用傳遞過來：

catch (Exception ex) {dispatchException = ex; } catch (Throwable err) {dispatchException = new NestedServletException("Handler dispatch failed", err); }

在processDispatchResult方法最開始，就對異常進行了處理：

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

這一過程是用異常視圖替換原始視圖的過程，核心邏輯在processHandlerException方法，實際就是調用所有注冊了的處理器異常解析器的resolveException方法產生異常視圖，并對請求屬性進行配置：

protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response,@Nullable Object handler, Exception ex) throws Exception {ModelAndView exMv = null;if (this.handlerExceptionResolvers != null) {for (HandlerExceptionResolver resolver : this.handlerExceptionResolvers) {exMv = resolver.resolveException(request, response, handler, ex);if (exMv != null) {break;}}}if (exMv != null) {if (exMv.isEmpty()) {request.setAttribute(EXCEPTION_ATTRIBUTE, ex);return null;}if (!exMv.hasView()) {String defaultViewName = getDefaultViewName(request);if (defaultViewName != null) {exMv.setViewName(defaultViewName);}}WebUtils.exposeErrorRequestAttributes(request, ex, getServletName());return exMv;}throw ex; }

7.2 頁面渲染 —— render方法

在方法的開頭，先使用本地化解析器決定了本地化屬性：

Locale locale = (this.localeResolver != null ? this.localeResolver.resolveLocale(request) : request.getLocale()); response.setLocale(locale);

然后根據邏輯視圖中，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() + "'"); }

需要靠名稱解析出實際的視圖對象，實質就是調用合適的ViewResolver的resolveViewName方法：

protected View resolveViewName(String viewName, @Nullable Map<String, Object> model, Locale locale, HttpServletRequest request) throws Exception {if (this.viewResolvers != null) {for (ViewResolver viewResolver : this.viewResolvers) {View view = viewResolver.resolveViewName(viewName, locale);if (view != null) {return view;}}}return null; }

如果邏輯視圖采用視圖引用，即內部已包含View對象，直接取出就可以。

接下來，為response設置HTTP狀態碼，并調用View的render方法進行頁面渲染。以InternalResourceView為例，其render方法實現在AbstractView中：

public void render(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {Map<String, Object> mergedModel = createMergedOutputModel(model, request, response);prepareResponse(request, response);renderMergedOutputModel(mergedModel, getRequestToExpose(request), response); }

prepareResponse方法雖然不是空方法，但是由于if條件永遠不滿足，所以實際不做任何處理。實際起作用的只有createMergedOutputModel和renderMergedOutputModel兩個方法。

首先看前者，該方法同樣實現在AbstractView類，作用是將靜態和動態變量添加到模型中：

protected Map<String, Object> createMergedOutputModel(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) {Map<String, Object> pathVars = (this.exposePathVariables ?(Map<String, Object>) request.getAttribute(View.class.getName() + ".pathVariables") : null);int size = this.staticAttributes.size();size += (model != null ? model.size() : 0);size += (pathVars != null ? pathVars.size() : 0);Map<String, Object> mergedModel = new LinkedHashMap<>(size);mergedModel.putAll(this.staticAttributes);if (pathVars != null) {mergedModel.putAll(pathVars);}if (model != null) {mergedModel.putAll(model);}if (this.requestContextAttribute != null) {mergedModel.put(this.requestContextAttribute, createRequestContext(request, response, mergedModel));}return mergedModel; }

exposePathVariables變量默認為true。可以看到，添加屬性時，按照先靜態屬性再動態屬性的順序，即動態屬性優先級更高。

然后看后者，它的一個參數是getRequestToExpose的結果，它的兩個if判斷條件默認都不滿足，即不作處理直接返回：

protected HttpServletRequest getRequestToExpose(HttpServletRequest originalRequest) {if (this.exposeContextBeansAsAttributes || this.exposedContextBeanNames != null) {WebApplicationContext wac = getWebApplicationContext();Assert.state(wac != null, "No WebApplicationContext");return new ContextExposingHttpServletRequest(originalRequest, wac, this.exposedContextBeanNames);}return originalRequest; }

renderMergedOutputModel方法實現在InternalResourceView類，它首先將模型數據綁定到request上：

exposeModelAsRequestAttributes(model, request); exposeHelpers(request);

第二個方法是個擴展點，沒有默認實現。接下來解析View的位置：

protected String prepareForRendering(HttpServletRequest request, HttpServletResponse response) throws Exception {String path = getUrl();Assert.state(path != null, "'url' not set");if (this.preventDispatchLoop) {String uri = request.getRequestURI();if (path.startsWith("/") ? uri.equals(path) : uri.equals(StringUtils.applyRelativePath(uri, path))) {throw new ServletException("Circular view path [" + path + "]: would dispatch back " + "to the current handler URL [" + uri + "] again. Check your ViewResolver setup! " + "(Hint: This may be the result of an unspecified view, due to default view name generation.)");}}return path; }

這里拋出的異常肯定很多人都遇到過，使用SpringBoot時，如果沒有配置themeleaf且有如下代碼，在訪問時就會拋出這個異常：

@Controller public class TestController{@RequestMapping("/index")public String index(){return "index";} }

不過在Spring MVC中，由于preventDispatchLoop默認為false，所以在此處不會觸發回環檢查。

接下來就是獲取一個RequestDispatcher（使用InternalResourceView時，一般對應JSP文件），由它將剛剛設置到request中的模型數據發送到實際頁面：

// Obtain a RequestDispatcher for the target resource (typically a JSP). RequestDispatcher rd = getRequestDispatcher(request, dispatcherPath); if (rd == null) {throw new ServletException("Could not get RequestDispatcher for [" + getUrl() + "]: Check that the corresponding file exists within your web application archive!"); } // If already included or response already committed, perform include, else forward. if (useInclude(request, response)) {response.setContentType(getContentType());rd.include(request, response); } else {// Note: The forwarded resource is supposed to determine the content type itself.rd.forward(request, response);

至此，頁面渲染部分完成。
在這之后，調用處理器執行鏈的afterCompletion方法，處理異步事件或調用cleanupMultipart清理資源。

三、重點總結一下視圖的解析流程

首先Springboot默認不支持jsp引擎

視圖處理的方式

視圖解析：
? 返回值以 forward: 開始： new InternalResourceView(forwardUrl); --> 轉發request.getRequestDispatcher(path).forward(request, response);
? 返回值以 redirect: 開始： new RedirectView() --> render就是重定向
? 返回值是普通字符串： new ThymeleafView（）

視圖解析原理流程

目標方法處理的過程中，所有數據都會被放在 ModelAndViewContainer 里面。包括數據和視圖地址
方法的參數是一個自定義類型對象（從請求參數中確定的），把他重新放在 ModelAndViewContainer
任何目標方法執行完成以后都會返回 ModelAndView（數據和視圖地址）。
processDispatchResult 處理派發結果

文章部分轉自

總結

以上是生活随笔為你收集整理的springboot MVC视图解析流程源码分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：做产品经理的第1年、第5年和第10年..
下一篇：新手产品经理的职业规划