1.SpringMVC 的执行流程
2.SpringBoot 申请映射原理
1.SpringMVC 的执行流程
在咱们刚开始学习 springMVC 的时候,咱们必定学过springMVC 的执行流程:
咱们简述一下SpringMVC 的执行流程:
1.客户端发送申请 ,申请被DispatcherServlet(中央处理器) 捕捉。
2.DispatcherServlet对申请 URL 进行解析 ,取得资源标识符URI,依据URI 调用 HandlerMapping(处理器映射器) 取得执行链 (具体哪个 Handler(Controller) 执行该办法,以及该 Handler 的拦截器,参数转换器器等等),以 HandlerExecutionChain 对象返回给 DispatcherServlet(中央处理器)。
3.DispatcherServlet依据取得的 Handler,抉择对应的 HandlerAdapter(如果胜利取得,就执行拦截器的 preHandler(…)办法)。
4.HandlerAdapter 对 Request 参数进行解析,并和 Handlerr 的参数进行绑定,调用反射执行 Handlerr 办法。
5.Handlerr 执行结束当前,向 Dispatcher 返回一个 ModelAndView 对象。
6. 依据返回的 ModelAndView,抉择一个适合的 ViewResolver 返回给 DispatcherServlet。
7.ViewResolver 依据 ModelAndView,渲染视图
8. 返回后果
以往咱们通过这个流程只能死记硬背,不过咱们明天依据源码来剖析一下它的整体流程,并且着重剖析一下第 2 步(申请映射)。
2.SpringBoot 申请映射原理
用 一句话 解释:申请映射,就是 通过拜访门路找到对应 Controller的过程!
如何跟踪源码?咱们能够在 Controller 上打一个断点,并且跟踪断点的堆栈信息,就能够找到 DispatcherServlet,并且找到对应的执行办法了。
而后 dispatcherServlet 的外围办法咱们就找到了 doDispatch 办法:
刨去一些预处理,查看,参数转换等逻辑,咱们能够看出,这执行逻辑和上图 SpringMVC 的执行逻辑截然不同。
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.
// 依据门路找到 Handler
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
// 依据 Handler 找到 HandlerAdapter(处理器适配器)HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = HttpMethod.GET.matches(method);
if (isGet || HttpMethod.HEAD.matches(method)) {long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
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);
}
// 解决 handler 的执行后果(视图解析)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);
}
}
}
}
这样咱们就对 springMVC 的执行逻辑有了一个 hello Wrold 级别的了解,接下来咱们着重解说一下 通过申请是如何获取 Handler 的,也就是上面这一行,咱们能够在这一行下面打一个断点。
mappedHandler = getHandler(processedRequest);
再发送一个申请进入这个办法,咱们会发现这样一个逻辑:
@Nullable
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;
}
通过函数名称能够得出,Spring 通过遍历的形式 , 试图通过 request 来取得对应的 hanler。咱们能够打个断点看看 Spring 里有多少种 HandlerMapping。
其实看见这些对象的名字,咱们就能够得出咱们以后的 自定义 controller 申请 是通过 RequestMappingHandlerMapping 来解决的,RequestMappingHandlerMapping 中的 mappingRegistry 更是证实了这一点,它保留了以后我的项目的所有 controller 门路。
咱们 查看获取 handler 的细节:
咱们能够看到 spring调用了一个办法 来取得一个 handler 对象,咱们持续往里看:
发现还调用了一个办法,咱们持续往里看:
再往里面一层咱们发现,这里通过申请门路获取到了 handler 对象:
这是 最初一个外围办法,咱们往里看,源码的逻辑就会高深莫测:
咱们最初来梳理一下申请映射逻辑:
1. 先通过 申请门路 来找出 哪个 处理器映射器 能解决这个申请门路。
2. 通过 对应的处理器映射器 来找 到申请门路对应的 handler,并返回。
3.RequestMappingHandlerMapping 中 保留 了@RequestMapping 和 handler 的映射规定 ,当咱们容器启动的时候,SpringMVC 就会扫描所有的 Controller 注解,并把 对应关系保留在 RequestMappingHandlerMapping外面。
4.SpringBoot 也主动配置了一些初始门路,比方拜访“/”就能拜访到 index.html。
5. 当一个申请门路进入 springMVC 的时候,会挨个尝试所有的 handlerMapping 看是否有申请信息,如果没有则寻找下一个,如果咱们须要自定义的映射解决,也能够通过 @Bean 的形式给容器中减少。