FileSystemWatcher vs polling監視文件更改我需要設置一個應用程序來監視在本地或網絡驅動器上的目錄中創建的文件。請問FileSystemWatcher一個計時器或投票將是最好的選擇。我過去曾使用過這兩種方法，但并不廣泛。兩種方法都存在哪些問題（性能，可靠性等）？
3 回答
不負相思意
TA貢獻1777條經驗 獲得超10個贊
我看到文件系統觀察器在生產和測試環境中失敗了。我現在認為它很方便，但我認為它不可靠。我的模式是使用文件系統觀察程序來監視更改，但偶爾進行輪詢以捕獲丟失的文件更改。
編輯：如果您有用戶界面，您還可以讓用戶“刷新”更改而不是輪詢。我會將它與文件系統觀察器結合起來。
飲歌長嘯
TA貢獻1951條經驗 獲得超3個贊
我遇到的最大問題是當緩沖區滿了時丟失文件。很容易修復 - 只需增加緩沖區。請記住，它包含文件名和事件，因此請將其增加到預期的文件數量（試用和錯誤）。它確實使用了無法分頁的內存，因此如果內存不足，它可能會強制其他進程進行分頁。
這是關于緩沖區的MSDN文章： FileSystemWatcher .. ::。InternalBufferSize屬性
每個MSDN：
增加緩沖區大小是昂貴的，因為它來自無法換出到磁盤的非分頁內存，因此請盡可能減小緩沖區。要避免緩沖區溢出，請使用NotifyFilter和IncludeSubdirectories屬性過濾掉不需要的更改通知。
由于一次預計會有大量批次，我們使用16MB。工作正常，永遠不會錯過文件。
我們還在開始處理之前讀取了所有文件，即使只有一個......將文件名安全地緩存（在我們的例子中，放入數據庫表中）然后處理它們。
對于文件鎖定問題，我產生了一個進程，它等待文件解鎖等待一秒鐘，然后是兩秒鐘，然后是四個等等。我們從不投票。這已經生產了大約兩年沒有錯誤。
www說
TA貢獻1775條經驗 獲得超8個贊
的FileSystemWatcher也可能錯過在繁忙時間的變化，如果排隊改變的次數溢出提供的緩沖液中。這不是.NET類本身的限制，而是基礎Win32基礎結構的限制。根據我們的經驗，最小化此問題的最佳方法是盡快將通知出列并在另一個線程上處理它們。
如上面的@ChillTemp所述，觀察者可能無法處理非Windows共享。例如，它在安裝的Novell驅動器上根本不起作用。
我同意一個很好的折衷方案是偶爾進行民意調查，以便找出任何錯過的變化。
- 3 回答
- 0 關注
- 292 瀏覽
添加回答
舉報
0/150
提交
取消