前言做后台，滤波器一定配置得不多，但知道其原理的可能不多。 在那之前我不知道，这不影响业务开发。 同时，因为还有其他知识，所以一直没看。 我这一段时间很闲，正好在看《How Tomcat Works》的PipeLine相关内容。 干脆整理一下关于过滤器链的知识吧。
类图
过滤器链的作用是冷樱桃，过滤器链是过滤链。 每个“过滤器”(Filter )确定是否执行以下步骤：
过滤器分为两个方向，进出：
(进制)在将servlet请求和servlet请求传递给servlet服务方法之前，必须进行过滤
出：服务方法完成后，在发送到客户端之前，必须进行过滤
Filter定义和配置定义
通常，要定义Filter类，请实现Filter接口，并在doFilter方法中编写自己的过滤器逻辑。 方法参数包含对包含Filter对象的FilterChain的引用，因此可以控制过滤器链的进度。 但是，控件的内容是
1 .向下执行
2 .不向下执行。
配置
在旧项目中，通常直接设置为web.xml文件。 使用过滤器/过滤器设置过滤器名称、类和过滤器在链中的位置。
在Spring Boot项目中，可以使用FilterRegisterBean设置过滤器。
过滤器通道的运行原理过滤器通道的实现类是上图中的应用程序过滤器通道。 ApplicationFilterChain对象包含多个主要参数
n=filter个数pos=下一个要执行的filter的位置servlet=pos=n，即过滤完成时，调用servlet的servlet方法，请求有关servlet文件filter的配置信息也就是说，过滤器通道具有所有过滤器的构成信息，它们被保存在一个数组中，然后通过移动pos来取得后续的过滤器并执行。
触发方式：从上次运行的Filter中调用FilterChain的doFilter方法。
以下是ApplicationFilterChain的doFilter和internalDoFilter的源代码
/* * invokethenextfilterinthischain，passingthespecifiedrequest * and response.iftherearenomorefiltersinthischain， invoke * the code service (/codemethodoftheservletitself.* * @ paramrequesttheservletrequestweareprocessing * @ paramresponspons @ exceptionioexceptionifaninput/outputerroroccurs * @ exceptionservletexceptionifaservletexceptionoccurs */@ overridepublicvoiddofilter (servletrequestrequest，servletresponseresponse (throwsioexception，Servletexception(if ) ) GGE try { Java.security.access controller.do privileged (new Java.security.privilegedexceptionactionvoid ) @overrideproide
ws ServletException, IOException { internalDoFilter(req,res); return null; } } ); } catch( PrivilegedActionException pe) { Exception e = pe.getException(); if (e instanceof ServletException) throw (ServletException) e; else if (e instanceof IOException) throw (IOException) e; else if (e instanceof RuntimeException) throw (RuntimeException) e; else throw new ServletException(e.getMessage(), e); } } else { internalDoFilter(request,response); } } private void internalDoFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { // Call the next filter if there is one if (pos < n) { ApplicationFilterConfig filterConfig = filters[pos++]; try { Filter filter = filterConfig.getFilter(); if (request.isAsyncSupported() && "false".equalsIgnoreCase( filterConfig.getFilterDef().getAsyncSupported())) { request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR, Boolean.FALSE); } if( Globals.IS_SECURITY_ENABLED ) { final ServletRequest req = request; final ServletResponse res = response; Principal principal = ((HttpServletRequest) req).getUserPrincipal(); Object[] args = new Object[]{req, res, this}; SecurityUtil.doAsPrivilege ("doFilter", filter, classType, args, principal); } else { filter.doFilter(request, response, this); } } catch (IOException | ServletException | RuntimeException e) { throw e; } catch (Throwable e) { e = ExceptionUtils.unwrapInvocationTargetException(e); ExceptionUtils.handleThrowable(e); throw new ServletException(sm.getString("filterChain.filter"), e); } return; } // We fell off the end of the chain -- call the servlet instance try { if (ApplicationDispatcher.WRAP_SAME_OBJECT) { lastServicedRequest.set(request); lastServicedResponse.set(response); } if (request.isAsyncSupported() && !servletSupportsAsync) { request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR, Boolean.FALSE); } // Use potentially wrapped request from this point if ((request instanceof HttpServletRequest) && (response instanceof HttpServletResponse) && Globals.IS_SECURITY_ENABLED ) { final ServletRequest req = request; final ServletResponse res = response; Principal principal = ((HttpServletRequest) req).getUserPrincipal(); Object[] args = new Object[]{req, res}; SecurityUtil.doAsPrivilege("service", servlet, classTypeUsedInService, args, principal); } else { servlet.service(request, response); } } catch (IOException | ServletException | RuntimeException e) { throw e; } catch (Throwable e) { e = ExceptionUtils.unwrapInvocationTargetException(e); ExceptionUtils.handleThrowable(e); throw new ServletException(sm.getString("filterChain.servlet"), e); } finally { if (ApplicationDispatcher.WRAP_SAME_OBJECT) { lastServicedRequest.set(null); lastServicedResponse.set(null); } } } FilterChain的执行结构 doFilter1 { //Filter1的doFilter方法 ... doFilter2 { //Filter2的doFilter方法 ... doFilter3 { ... doFilterN { ... service(request, response); } } } operation1();}对于CoyoteAdapter来说，它只调用了一次FilterChain的doFilter方法。这个方法内部到底执行了什么，它不知道，它只知道当这个方法返回的时候，它就把响应内容返回给客户端。
在这个doFilter内部嵌套执行多个Filter的doFilter方法，结构有点类似递归。如上，当所有Filter都完成的时候，会调用Servlet的service方法。最后逐层返回，执行完operaion1()。FilterChain的调用就算完成了。
不调用service的情况
可能出现在chain中的某个环节检测到，请求不合规。则可以直接返回，而不用执行doFilter方法。也就不会交给servlet执行。
那必要的提示信息怎么办？
在实际应用中可能要告知用户的违规情况，这其实挺简单的。因为在doFilter方法中，request和response的引用已经有了，直接操作response就可以了。比如你要返回一个JSON格式的错误信息。你就可以在Repsonse的OutputStream中写入相应的JSON字符串。然后设置Content-Type为application/json，设置Content-Length为字符串的长度。直接返回就可以了。
FilterChain对象与请求的关系看到上面移动pos（本质上就是++操作），估计有人会跟我一样想到线程安全问题，即FilterChain是否会存在多线程访问的情况。如果存在多线程访问，由于每个线程的过滤进度可能都不一样，必然会互相干扰。
答案是这样，每个请求都会创建一个新的FilterChain对象。
注意：Filter配置是针对整个Web项目的，而每个FilterChain对象是针对每个请求的。
我是怎么知道的？
猜测加验证。即定位ApplicationFilterChain的创建操作即可。ApplicationFilterChain对象由ApplicationFilterFactory工厂的createFilterChain方法生成。而这个方法在ApplicationDispatcher的invoke方法内被调用。这个invoke方法是Connector把新请求传递给Container的方式。
责任链模式FilterChain就是典型的责任链模式的实现案例。类似的还有，Tomcat的Pipeline Task，Netty的ChannelPipeline.