[[322816]]

不少讀者催我寫「過濾器和監聽器」，于是我就又來了。

什么是過濾器?

我們很容易發現，過濾器可以比喻成一張濾網。我們想想現實中的濾網可以做什么：在泡茶的時候，過濾掉茶葉。那濾網是怎么過濾茶葉的呢?規定大小的網孔，只要網孔比茶葉小，就可以實現過濾了!

引申在Web容器中，過濾器可以做：過濾一些敏感的字符串【規定不能出現敏感字符串】、避免中文亂碼【規定Web資源都使用UTF-8編碼】、權限驗證等等等，過濾器的作用非常大，只要發揮想象就可以有意想不到的效果

[[322819]]

這次的PDF共有「58」頁，PDF涉及到的內容：

• 過濾器入門和應用
• 監聽器入門和應用
• 幾道簡單的過濾器和監聽器面試題

過濾器的知識點

「學某項技術之前，首先要知道它能干什么，學了這項技術有什么好處，再細學」

知道了什么是過濾器以后，其實我們學的東西就不是很多了，感覺花半天就能學完了。

首先，我們來認識一下Filter接口和相對應的doFilter()方法以及它的參數。

學過我之前的「Servlet」教程，對doFilter()里邊的ServletRequest和ServletResponse應該就很了解了，我這里也不贅述了。唯一可能讓人難以理解的就是FilterChain這個接口。

而FilterChain接口里邊其實也是一個doFilter方法。

我們可以這樣理解：過濾器不單單只有一個，那么我們怎么管理這些過濾器呢?在Java中就使用了鏈式結構。把所有的過濾器都放在FilterChain里邊，如果符合條件，就執行下一個過濾器(如果沒有過濾器了，就執行目標資源)。

上面的話好像有點拗口，我們可以想象生活的例子：現在我想在茶杯上能過濾出石頭和茶葉出來。石頭在一層，茶葉在一層。所以茶杯的過濾裝置應該有兩層濾網。這個過濾裝置就是FilterChain，過濾石頭的濾網和過濾茶葉的濾網就是Filter。在石頭濾網中，茶葉是屬于下一層的，就把茶葉放行，讓茶葉的濾網過濾茶葉。過濾完茶葉了，剩下的就是茶

對上面的API了解完了以后，我們試著自己寫一個過濾器(實際上就是實現Filter接口，重寫doFilter()方法)，然后以注解/xml配置的方式來部署自己的過濾器。

隨后看一下FilterChain的執行順序是不是自己配置的那樣，再寫幾個常見的過濾器應用就好了，比如說「禁止瀏覽器緩存」「實現自動登錄」「編碼過濾器」「敏感詞過濾器」「壓縮資源過濾器」「HTML轉義過濾器」「緩存數據」…

工作中用「過濾器」多嗎?

三歪在工作時間不長哈，接觸了好多些系統，由我們自己去寫「過濾器」的場景還是不多的。但我覺得有一點可以好好學學，就是「責任鏈模式」。

之前為啥我寫了一篇「責任鏈模式」，其實就是這個設計模式在系統中用得挺多的，號稱能搞掂if else。

過濾器其實也是責任鏈模式的一種實現，FilterChain層層往下執行，直到最后沒有過濾器，就到了「目標資源」

什么是監聽器?

監聽器就是一個實現特定接口的普通Java程序，這個程序專門用于監聽一個Java對象的方法調用或屬性改變，當被監聽對象發生上述事件后，監聽器某個方法將立即被執行。

上面這句話應該也很好理解，比如說我有一個SanWai對象，里邊有一個eat()方法。每當SanWai.eat()的時候，我的監聽器可以監聽到SanWai.eat()被調用了，于是我們就可以搞一波邏輯，做別的事了。

• 比如說，三歪女朋友發現三歪要吃飯了，于是打電話讓三歪少吃點。

回到Servlet層面上，我們更多的監聽的是「Session」「Request」「ServletContext」這幾個對象的創建/銷毀/屬性內的變化。

針對監聽上面的幾個對象，我們可以做出一些小例子，比如說「統計網站的在線人數」「自動踢人」「定時清除Session的值」

監聽器在工作中用得多嗎?

監聽器在寫業務代碼的時候，同樣也用得不多，我幾乎沒怎么寫過監聽器的代碼。

但是理解監聽器這個概念我覺得還是很有必要的。以我的理解，大概可以認為「A發生了變化，B需要依賴A發生的變化做出處理」，這就是監聽器。

有人認為，這不就是「事件驅動」嗎?我覺得也可以那樣理解。

監聽器和過濾器再總結

監聽器和過濾器在工作中可能讓我們自己「手寫」的概率不是很大，但我覺得這兩個技術還是需要了解的。如果你了解過Struts2，你就會發現Struts2就是用的過濾器來實現很多的功能。監聽器在Spring源碼里邊也有很多的實現，我覺得都可以看看。

過濾器和監聽器還是需要理解它的思想，這塊對我們學習Spring也是很有幫助的。

現在已經工作有一段時間了，為什么還來寫過濾器和監聽器呢，原因有以下幾個：

• 我是一個對排版有追求的人，如果早期關注我的同學可能會發現，我的GitHub、文章導航的read.me會經常更換。現在的GitHub導航也不合我心意了(太長了)，并且早期的文章，說實話排版也不太行，我決定重新搞一波。
• 我的文章會分發好幾個平臺，但文章發完了可能就沒人看了，并且圖床很可能因為平臺的防盜鏈就掛掉了。又因為有很多的讀者問我：”你能不能把你的文章轉成PDF啊?“
• 我寫過很多系列級的文章，這些文章就幾乎不會有太大的改動了，就非常適合把它們給”持久化“。