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的形式给容器中减少。
发表回复