Java NIO WatchService奇遇記

在擴充套件Apache Flume的Taildir Source的過程中，由於感覺其採用IO輪詢的方式，而不是Java NIO，會有效能問題，於是就打算通過Java NIO將相關的部分重寫一遍．

我們的想法是這樣的，先監控某個目錄，然後當有檔案修改事件觸發時，判斷一下被修改的檔案是否是某些特定的檔案，如果是，則讀取其新增的內容，併傳送給Channel.

通過Google,我們找到了WatchService這個東西，然後參考官方的原始碼實現了一遍．

開始沒有什麼問題．實際上是有問題，但是我沒有注意到．

用WatchService實現的程式碼如下:

我們可以看到，其中有一個死迴圈，不斷地讀取新的事件，判斷是否是我們要監控的檔案，如果是，則讀取新的內容併傳送給Channel.

問題是，它是死迴圈啊!!!

昨天下午在系統的其他部分時，由於擴充套件後的Flume也是其中的一個必須的元件，所以就一直開著Flume.期間，我就納悶，怎麼電量這麼不耐用呢?之前都是能夠撐兩個小時的，怎麼這次只用不到一個小時就沒電了?

用top命令檢視了一下，發現一個Java應用的CPU利用率一直都是100%+.

用ps命令檢視了一下對應的程式，發現就是我們的Flume程式．

此時，我恍然大悟．想到了可能是死迴圈導致的CPU利用率太高．

這時，想起了自己在改寫這部分時的初衷，是希望能夠有這麼一個介面，我們可以傳入要監聽的事件，然後傳入一個回撥函式．當觸發相應的事件時，就呼叫回撥函式．

而WatchService顯然不是我需要的．

再次Google了一下之後，發現有人推薦用一款叫JNotifier的庫．從StackOverflow上得知，這個庫需要呼叫一個本地庫，而這個本地庫是封裝了Linux上的某個呼叫，用C語言封裝的，打包成了一個so檔案．

所以，我們想用的話，就得先將這個so檔案下載下來，然後加入java.native.path中．開始我是拒絕的，但是看到它的API那麼簡單，楚楚動人，我就忍不住想要嘗試一下．然而，官網上並沒有明確說明我們要如何來做．

結合出現的問題，StackOverflow了好長時間，用他們提供的方法都沒有解決．直到發現有一個人提問說他在Java 1.7和Java 1.8下都嘗試過，但是都出現那個錯誤，底下有人回答說，Java 1.8就不行．看到這，我終於失去了耐心！我用的就是Java 1.8．

最終，我刪除了一切跟JNotify相關的內容，然後重新踏上了尋找之路．

後來，我發現了一個庫，叫Apache Commons VFS.畢竟是Apache的產品，用起來更放心一些．使用起來，發現它的API甚至更加簡單，最終實現的程式碼如下:

現在，Flume的CPU利用率就保持正常了．

但是，Apache Commons VFS的具體實現，我並沒有檢視．我不知道它到底是如何實現的，內部是否還是通過輪詢的方式實現的．雖然它現在能正常工作，但是我們並沒有對它進行過深度測試，所以，實際上，我們是不能信任它的．我們並不能認為它就完美無暇．因為它現在對我們就是一個黑匣子!