1.DispatcherServlet

属性：两个重要属性 — handler的映射和 handler的适配器

image.png

操作：getHandler和doDispatch，最关键的就是doDispatch()

getHandler（）：遍历所有的handlerMapping，让他们去拿handler，最后找到合适的handlerMapping，拿出handler链。
image.png
doDispatch（）：根据request调用上面的方法（遍历所有handlerMapping，拿出handler链），最后得到handler链，通过handler链拿出真正的handler@HandlerMethod，然后根据这个handler找到合适的Adapter
，最后通过adapter去执行此handler。
image.png

2. HandlerExecutionChain

属性：handler、interceptors(拦截器数组)、interceptorList（拦截器集合）
从这里也可以看出，处理执行链 就是一个handler(可以看成controller、里面有bean、method、methodParams)，和各种拦截器组成的一个类。
image.png
操作：大部分都是和拦截器有关的。不做介绍。不过看下这个，返回handler。
image.png

简单介绍一下Interceptor吧，共有三个主要的方法。注意参数都是 request、response、handler。（由此应该能退出拦截器的作用了吧。）
image.png

3. handlerMapping

属性无
操作：getHandlerI()、返回请求处理链
image.png
他的继承链（注意，所有实现这个接口的类必须实现getHandler，返回请求处理链）：
image.png

子类介绍

MatchableHandlerMapping接口继承了他，并且增加了一个方法。

image.png

AbstractHandlerMapping类实现了它

image.png
属性：属性没什么重要的，不过留意一下 urlPathHelper、interceptors、adaptedInterceptors
image.png
操作：这里面有几个很重要的getHandler()、getHandlerInternal()、urlPathHelper的setter、getter 。 前面的方法调用了后面的。后面是抽象方法，在子类AbstractUrlHandlerMapping里实现
image.pngimage.pngimage.pngimage.pngimage.pngimage.png

AbstractUrlHandlerMapping

属性：没有重要的，不写了
操作：比较熟悉的有getHandlerInternal()、lookupHandler()。第一个方法调用了第二个。而且第一个的返回结果是Handler。第二个方法没看懂，暂时先不写。
image.pngimage.png

完整的调用逻辑

好，由上面的铺垫，我们完整的梳理一遍逻辑
1.请求 -> 2.DispatcherServlet#doDispatch() -> 3.自身getHandler()得到HandlerExecutionChain ->4.从执行请求链里拿出handler，找的相应的adpater。
image.pngimage.png
细究步骤3：遍历所有的handlerMapping（HandlerMapping是个接口，里面只有一个getHandler()），每个mapping调用自己的getHandler()（其实调用的是AbstractHandlerMapping里的getHandler()，最后返回 请求执行链类型的handler），然后去找他的adapter类。
image.png

4. handler

到底是什么？

本质上是一个HandlerMethod，而这个handler被实例化成HandlerMethod的过程最终是由handlerMapping完成的。 HandlerMapping的一个子类RequestMappingInfoHandlerMapping调用自己的getHandlerInternal()，传入request，最终封装成一个 HandlerMethod。不细讲，知道是谁完成的就行
如下图，在mapping的getHandler(request)的时候被初始化成handlerMethod。（一层层的找下去）
image.png
image.png