【雜談】FilterChain相關知識整理

前言

　　作後臺的，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.