SpringMVC之拦截器
1、HandlerInterceptor 定义
直接看下SpringMVC中的接口：
public interface HandlerInterceptor {
/**
* 预处理回调方法，实现处理器的预处理，第三个参数为响应的处理器，自定义Controller
* 返回值：true表示继续流程（如调用下一个拦截器或处理器）；false表示流程中断
* 不会继续调用其他的拦截器或处理器，此时我们需要通过response来产生响应
*/
default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
throws Exception {
return true;
}
/**
* 后处理回调方法，实现处理器的后处理（渲染视图之前）
* 此时我们可以通过modelAndView（模型和视图对象）对模型数据进行处理或对视图进行处理
* modelAndView也可能为null，如API接口返回JSON数据时
*/
default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
@Nullable ModelAndView modelAndView) throws Exception {
}
/**
* 整个请求处理完毕回调方法，即在视图渲染完毕时回调
* 如性能监控中我们可以在此记录结束时间并输出消耗时间
* 还可以进行一些资源清理，类似于try-catch-finally中的finally，但仅调用处理器执行链中
*/
default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
@Nullable Exception ex) throws Exception {
}
}
2、HandlerInterceptor的作用时机
每个请求进来的时候，都会经过DispatcherServlet中的doDispatch方法，然后根据请求选择执行的handler
那么具体的就应该看一下这里如何选择的。
那么看一下HandlerExecutionChain的组成
HandlerExecutionChain的组成
这里的handler就是具体的用来处理request请求的对象，这里的interceptorList对象就是用来保存所有的拦截器的。
3、拦截器在请求处理阶段作用
3.1、前置拦截位置
可以看到在请求还未到达controller中的处理逻辑的时候，拦截器会先来进行执行前置拦截方法。
看一下具体的调用过程
1、首先按照顺序来获取得到拦截器链中的每个元素，挨个遍历执行；
2、如果拦截器拦截成功，那么将会记录一下当前拦截器成功的下标；如果拦截器拦截失败，那么将直接调用后置处理方法；
3、如果多个拦截器中，有一个拦截器执行是失败的，那么将会导致整个请求响应的是一个空的页面。所以一般来说，拦截器的设置是很重要的。
3.2、后置拦截
controller中的方法执行结束了，即返回了ModelAndView，这个时候还没有进行视图解析和填充阶段。
将会来执行后置处理方法
如果拦截器链中的所有前置拦截都是拦截成功了，现在开始按照倒叙遍历链表。但是这个时候却没有记录下标。
3.3、最终处理方式
如果执行程序出现了异常信息或者是成功执行之后，最终都将会来调用拦截器链路中的最终处理方式。
在前置拦截中记录的下标会在这里来发挥作用，这里只会执行前置拦截成功后的最终拦截方法，而不会执行拦截失败的最终拦截方法。
比如说：有A、B、C三个拦截器
A、B都执行了对应的preHandle方法，但是C的preHandle返回FALSE，那么最终处理将会执行B、A的最终处理方法。而不会调用C的最终处理方式。
3.4、拦截器的执行顺序
拦截器中某个拦截器执行失败
拦截器都执行成功的场景
4、HandlerInterceptor被加载到容器时机
首先需要明确的是web容器已经创建起来了，然后Tomcat也启动了，bean的扫描也结束了。
下面但是还没有完成单例bean的实例化。也就是说容器中只有少量的bean定义和多个bean定义信息。
而最终肯定是需要来完成对应的bean加载过程。
在WebMvcAutoConfiguration自动配置类中，会有一个关于RequestMappingHandlerMapping的配置。
其实不管是在WebMvcAutoConfiguration还是在WebMvcConfigurationSupport中，都会有RequestMappingHandlerMapping的配置。
先来看WebMvcAutoConfiguration自动配置类中关于RequestMappingHandlerMapping的配置
先来看下默认添加的拦截器
AbstractHandlerMapping
- 实际上拦截器都是初始化并保存在 AbstractHandlerMapping 里，直到 getHandle -> getHandleExcuteChain 时会使用 HandlerMapping 里面的拦截器去初始化 HandlerExcuteChain
HandlerExecutionChain
- handlerMethod 和 handlerExcuteChain 的包装类
MappedInterceptor
- 一个包括includePatterns和excludePatterns字符串集合并带有HandlerInterceptor的类。 很明显，就是对于某些地址做特殊包括和排除的拦截器。
HandlerInterceptor 解析与初始化
解析
SpringMVC 配置拦截器
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/**"/>
<mvc:exclude-mapping path="/login"/>
<mvc:exclude-mapping path="/index"/>
<bean class="package.interceptor.XXInterceptor"/>
</mvc:interceptor>
</mvc:interceptors>
这里配置的每个mvc:interceptor都会被解析成MappedInterceptor。
- 其中子标签<mvc:mapping path="/**"/>会被解析成MappedInterceptor的includePatterns属性；
- <mvc:exclude-mapping path="/**"/>会被解析成MappedInterceptor的excludePatterns属性；
- class会被解析成MappedInterceptor的interceptor属性。
mvc:interceptors这个标签是被InterceptorsBeanDefinitionParser类解析。
初始化
interceptor的初始化是在初始化 HandlerMapping 时完成的，HandlerMapping 多数是通过继承 AbstractHandlerMapping 实现的
因为 AbstractHandlerMapping 实现 ApplicationContextAware 接口，bean 初始化完成后会执行 setApplicationContext 方法，通过源码看到最终执行如下方法：
对应源码实现：
protected void initApplicationContext() throws BeansException {
//空实现，用于扩展拦截器
extendInterceptors(this.interceptors);
//直接加载spring 容器中所有实现了MappedInterceptor接口的拦截器
detectMappedInterceptors(this.adaptedInterceptors);
//把extendInterceptors中的扩展方法加入到adaptedInterceptors集合中
initInterceptors();
}
看看实现：
protected void detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors) {
// 加载所有的 MappedInterceptor
mappedInterceptors.addAll(
BeanFactoryUtils.beansOfTypeIncludingAncestors(
obtainApplicationContext(), MappedInterceptor.class, true, false).values());
}
protected void initInterceptors() {
if (!this.interceptors.isEmpty()) {
for (int i = 0; i < this.interceptors.size(); i++) {
Object interceptor = this.interceptors.get(i);
if (interceptor == null) {
throw new IllegalArgumentException("Entry number " + i + " in interceptors array is null");
}
//List<MappedInterceptor>
if (interceptor instanceof MappedInterceptor) {
this.mappedInterceptors.add((MappedInterceptor) interceptor);
}
//添加到List<HandlerInterceptor>
else {
this.adaptedInterceptors.add(adaptInterceptor(interceptor));
}
}
}
}
拦截器时序原理
当请求进来后，最终执行DispatcherServlet的doDispatch方法开始处理请求，如下
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);
// 初始化 HandlerExecutionChain 与添加拦截器
// 此处开始遍历HandlerMapping，获取HandlerExecutionChain，这里方法执行完后，针对此次请求，已经确定有几个拦截器可以被执行了
mappedHandler = getHandler(processedRequest);
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
//开始这行preHandler的预处理方法，会遍历HandlerExecutionChain 中的所有拦截器，并执行器preHandler方法，如果有方法返回false，则直接返回，不在继续执行
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
//开始真正执行Handler方法
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
applyDefaultViewName(processedRequest, mv);
//具体Controler中的方法执行完成后开始执行拦截器的postHandler方法，注意此时是和preHandler的执行顺序是相反的
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
//开始遍历并执行拦截器的AfterCompletion方法，注意此时是根据handlerIndex反向执行的
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);
}
}
}
}
AbstractHandlerMapping中获取HandlerExecutionChain的过程如下
- 请求进来后，在HandlerMapping中会根据具体的请求path来选择合适的拦截器
- 因为在初始化HandlerMapping的时候，已经把所有的HandlerInterceptor全部加载完成了
看下具体实现过程：
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;
// 如果匹配上就放入 HandlerExecutionChain 的 interceptors 中
if (mappedInterceptor.matches(lookupPath, this.pathMatcher)) {
chain.addInterceptor(mappedInterceptor.getInterceptor());
}
}
else {
// 直接加载到HandlerExecutionChain中来
chain.addInterceptor(interceptor);
}
}
return chain;
}
拦截器和Filter的区别
- 1、Filter是web容器定义的，由servlet容器来加载并执行，基本可以拦截所有请求，interceptor是spring mvc这种web框架定义的，用于在handler执行前后执行的，仅针对handler进行拦截，且是spring 来加载并执行的；
- 2、针对执行顺序，自然是filter先被执行，然后是拦截器的执行，拦截器是按照顺序执行prehandler，然后按照相反的顺序执行postHandler的，且不论方法执行成功与否，会按照相反的和preHander相反的顺序执行afterCompletion【仅执行已经执行过preHander方法的拦截器】；
转载参考：https://blog.csdn.net/weixin_43934607/article/details/113950408
