在使用SpringMVC拦截器的时候，我们接触的最多的便是HandlerInterceptor接口，因为我们所有的自定义拦截器都必须要实现HandlerInterceptor接口，那么就先从HandlerInterceptor接口开始一步步分析。
HandlerInterceptor接口
包含三个方法:
default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
return true;
}
default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable ModelAndView modelAndView) throws Exception {
}
default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
@Nullable Exception ex) throws Exception {
}
根据注释部分我们知道如下内容：
preHandle是在找到处理handler对象的HandlerMapping之后，HandlerAdapter调度handler之前执行。
postHandle是在HandlerAdapter调度handler之后，DispatcherServlet渲染视图之前执行，可以通过ModelAndView来向视图中添加一些信息等。
afterCompletion是在渲染视图结束后执行，主要可以用来进行事后的资源清理。
其中postHandle和afterCompletion方法是反顺序执行的。也就是说第一个拦截器会最后一个执行。关于HandlerInterceptor的执行顺序我们可以在HandlerExecutionChain类中找到。
HandlerExecutionChain类
这个类由一个handler和若干的HandlerInterceptor构成。那么这个类的作用就显而易见了，就是将拦截器和handle组合起来执行。就是对handle进行了包装。
这个类中有几个主要的方法：
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;
}
void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv)
throws Exception {
HandlerInterceptor[] interceptors = getInterceptors();
if (!ObjectUtils.isEmpty(interceptors)) {
for (int i = interceptors.length - 1; i >= 0; i--) {
HandlerInterceptor interceptor = interceptors[i];
interceptor.postHandle(request, response, this.handler, mv);
}
}
}
void triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, @Nullable Exception ex)
throws Exception {
HandlerInterceptor[] interceptors = getInterceptors();
if (!ObjectUtils.isEmpty(interceptors)) {
for (int i = this.interceptorIndex; i >= 0; i--) {
HandlerInterceptor interceptor = interceptors[i];
try {
interceptor.afterCompletion(request, response, this.handler, ex);
}
catch (Throwable ex2) {
logger.error("HandlerInterceptor.afterCompletion threw exception", ex2);
}
}
}
}
从函数名中我们可以看出这些方法分别是做什么的，分别是执行interceptorList中所有interceptor的preHandle、postHandle和afterCompletion方法。
先从applyPreHandle()看起，我们发现这个方法就是做的这样一个工作，按照列表中interceptor的顺序来执行它们的preHandle方法，直到有一个返回false。再看一下返回false后这个方法所做的工作，这时会调用triggerAfterCompletion方法，此时this.interceptorIndex指向上一个返回true的interceptor的位置，所以它会按逆序执行所有返回true的interceptor的afterCompletion方法。换言之，也就是对于任意的返回false的interceptor都不会执行afterCompletion方法。而且是中断之前所有的preHandle执行完成之后才会执行afterCompletion方法。
接下来是applyPostHandle()，这个方法较为简单，就是按照逆序执行所有interceptor的postHandle方法。
最后的triggerAfterCompletion()也是一样，就是从最后一次preHandle成功的interceptor处逆序执行afterCompletion。
HandlerMapping接口
HandlerExecutionChain是通过HandlerMapping的getHandler方法返回的。
继承该接口的类是来实现请求和handler对象的映射关系的。
这个接口中只有这样一个方法
HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
根据函数名，参数及返回值我们不难猜出这个接口的作用，就是根据request返回HandlerExecutionChain。至于HandlerMapping在springMVC中有多种实现，我们此处就不深究了。
对于getHandler最后的调度部分便是springMVC的最外层DispatcherServlet类了
DispatcherServlet类
DispatcherServlet类中调用HandlerMapping的getHandler的方法为getHandler（同名）
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
for (HandlerMapping hm : this.handlerMappings) {
if (logger.isTraceEnabled()) {
logger.trace(
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "'");
}
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
从代码中不难看出整个逻辑就是依次判断servlet中的每个handlerMapping是否能够匹配该请求，直到找到那个匹配的然后返回处理结果。
对于HandlerExecutionChain的调用我们可以在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);
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (logger.isDebugEnabled()) {
logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
}
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);
}
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);
}
}
}
}
private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
@Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
@Nullable Exception exception) throws Exception {
boolean errorView = false;
if (exception != null) {
if (exception instanceof ModelAndViewDefiningException) {
logger.debug("ModelAndViewDefiningException encountered", exception);
mv = ((ModelAndViewDefiningException) exception).getModelAndView();
}
else {
Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
mv = processHandlerException(request, response, handler, exception);
errorView = (mv != null);
}
}
// Did the handler return a view to render?
if (mv != null && !mv.wasCleared()) {
render(mv, request, response);
if (errorView) {
WebUtils.clearErrorRequestAttributes(request);
}
}
else {
if (logger.isDebugEnabled()) {
logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() +
"': assuming HandlerAdapter completed request handling");
}
}
if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
// Concurrent handling started during a forward
return;
}
if (mappedHandler != null) {
mappedHandler.triggerAfterCompletion(request, response, null);
}
}
从上面代码中我们可以验证第一部分所说的HandlerInterceptor接口中三个方法的执行顺序：
preHandle是在找到处理handler对象的HandlerMapping之后，HandlerAdapter调度handler之前执行。
postHandle是在HandlerAdapter调度handler之后，DispatcherServlet渲染视图之前执行。
afterCompletion是在渲染视图结束后执行。
总结
那么整个拦截器的处理过程我们便可以很清晰地分为两种情况，一种是所有拦截器preHandle都返回true的情况，另一种是有拦截器preHandle返回false的情况。
我们先假设我们有三个拦截器A,B,C,D。
对于第一种情况，那么在DispatcherServlet中分别依次调用HandlerExecutionChain类中applyPreHandle、applyPostHandle和triggerAfterCompletion方法，
那么所有方法的执行顺序为
A.pre -> B.pre -> C.pre -> D.pre
-> D.post -> C.post -> B.post -> A.post
-> D.after -> C.after -> B.after -> A.after
对于第二种情况，我们不妨设C拦截器的preHandle返回为false。
这时DispatcherServlet类调用HandlerExecutionChain类中applyPreHandle方法，然后由applyPreHandle调用triggerAfterCompletion方法，
那么执行情况如下
A.pre -> B.pre -> C.pre
-> B.after -> A.after
