作后台的,Filter确定没少配置,可是知晓其原理的可能很少。在这以前我也不懂,但这并不影响业务开发,同时也有其余的知识要学,因此一直就没看。这阵子有点闲,恰好在看《How Tomcat Works》的PipeLine相关内容。索性好好梳理一下FilterChain相关的知识。java
顾名思义,FilterChain就是一条过滤链。其中每一个过滤器(Filter)均可以决定是否执行下一步。web
过滤分两个方向,进和出:json
进:在把ServletRequest和ServletResponse交给Servlet的service方法以前,须要进行过滤数组
出:在service方法完成后,往客户端发送以前,须要进行过滤安全
定义多线程
通常,咱们定义Filter类通常经过实现Filter接口来完成,而后在doFilter方法中编写本身的过滤逻辑。因为方法参数中有Filter对象所在FilterChain的引用,故能够控制过滤链的进行。但控制内容,只能是app
1.向下执行ide
2.不向下执行。this
配置spa
在老项目中,通常直接在web.xml文件中配置。利用<filter></filter>配置过滤器名称,类以及过滤器在链中的位置。
而在Spring Boot项目中,则能够经过FilterRegisterBean来配置过滤器。
FilterChain的实现类是上图中的ApplicationFilterChain。一个ApplicationFilterChain对象包含几个主要参数
不少人,可能会疑惑,FilterChain是如何实现向下执行的。其实看到上面那些参数,你估计就已经明白了。即FilterChain持有全部Filter的配置信息,它们保存在一个数组中,而后经过移动pos,来获取后续的Filter并执行的。
触发方式:由上一个执行的Filter调用FilterChain的doFilter方法。
如下是ApplicationFilterChain的doFilter和internalDoFilter的源码
/** * Invoke the next filter in this chain, passing the specified request * and response. If there are no more filters in this chain, invoke * the <code>service()</code> method of the servlet itself. * * @param request The servlet request we are processing * @param response The servlet response we are creating * * @exception IOException if an input/output error occurs * @exception ServletException if a servlet exception occurs */ @Override public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { if( Globals.IS_SECURITY_ENABLED ) { final ServletRequest req = request; final ServletResponse res = response; try { java.security.AccessController.doPrivileged( new java.security.PrivilegedExceptionAction<Void>() { @Override public Void run() throws 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); } } }
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为字符串的长度。直接返回就能够了。
看到上面移动pos(本质上就是++操做),估计有人会跟我同样想到线程安全问题,即FilterChain是否会存在多线程访问的状况。若是存在多线程访问,因为每一个线程的过滤进度可能都不同,必然会互相干扰。
答案是这样,每一个请求都会建立一个新的FilterChain对象。
注意:Filter配置是针对整个Web项目的,而每一个FilterChain对象是针对每一个请求的。
我是怎么知道的?
猜想加验证。即定位ApplicationFilterChain的建立操做便可。ApplicationFilterChain对象由ApplicationFilterFactory工厂的createFilterChain方法生成。而这个方法在ApplicationDispatcher的invoke方法内被调用。这个invoke方法是Connector把新请求传递给Container的方式。
FilterChain就是典型的责任链模式的实现案例。相似的还有,Tomcat的Pipeline Task,Netty的ChannelPipeline.