前言
做後臺的，Filter肯定沒少配置，但是知曉其原理的可能不多。在這之前我也不懂，但這並不影響業務開發，同時也有其他的知識要學，所以一直就沒看。這陣子有點閒，剛好在看《How Tomcat Works》的PipeLine相關內容。索性好好梳理一下FilterChain相關的知識。
類圖
FilterChain的作用
顧名思義，FilterChain就是一條過濾鏈。其中每個過濾器（Filter）都可以決定是否執行下一步。
過濾分兩個方向，進和出：
進：在把ServletRequest和ServletResponse交給Servlet的service方法之前，需要進行過濾
出：在service方法完成後，往客戶端傳送之前，需要進行過濾
Filter的定義與配置
定義
一般，我們定義Filter類一般通過實現Filter介面來完成，然後在doFilter方法中編寫自己的過濾邏輯。由於方法引數中有Filter物件所在FilterChain的引用，故可以控制過濾鏈的進行。但控制內容，只能是
1.向下執行
2.不向下執行。
配置
在老專案中，一般直接在web.xml檔案中配置。利用<filter></filter>配置過濾器名稱，類以及過濾器在鏈中的位置。
而在Spring Boot專案中，則可以通過FilterRegisterBean來配置過濾器。
FilterChain的執行原理
FilterChain的實現類是上圖中的ApplicationFilterChain。一個ApplicationFilterChain物件包含幾個主要引數
- n => filter個數
- pos => 下一個要執行的filter的位置
- Servlet => 當pos >= n，即過濾完成時，呼叫Servlet的service方法，把請求交給Servlet
- filters => Filter的相關配置資訊
很多人，可能會疑惑，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); } } }
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.