最近處理了一個需求，大概是這樣的：
- 己方搭建好FTP服務器
- 對方往該服務器的指定目錄（假設叫 目錄A）上傳文件
- 己方需要將對方上傳好的文件(處於上傳中狀態的文件不能進行處理)解析並更新到數據庫中
- 己方對 目錄A 只有 “讀”的權限，即，不能對 目錄A中的文件進行刪除、重命名、移動等操作。
對於這個需求，我一開始想出的 解決方案 是：
- 開啓一個線程，定期去讀取 目錄A 下的所有文件
- 將每兩次讀取的文件列表進行對比，新出現的文件名對應的文件就是對方新上傳的
- 對於新的文件，先記錄下它的 大小 和 最後修改時間，然後，隔2秒，再次去讀它的這兩個屬性值。如果這兩個值保持不變了，那麼就說明文件上發傳好了。如果發生了改變，那 麼，就再隔2秒再去確定一次。
- 確定文件上傳好了之後，解析文件並上更新到數據庫中
這個方案在一般情況下是可以勝任的，但是它隱藏以下兩個小問題：
- 讀取目錄A的間隔的不太好設定，設定得小的話，會使得讀取的頻率太頻繁；設定得大的話，又可能導致文件大量積壓
- 獲取 大小 和 最後修改時間 這兩個屬性的值的時間間隔也不好確定，上面說的是 2秒，是我自己的假想。因爲當遇到大文件時，極有可能在2秒之內是不會傳完的。如果FTP是搭建在 windows 操作系統上的話，會有下面這個問題:
一個文件在傳輸之初時，就已經將文件大小確定了，在傳輸過程中，通過 java 中 File 類的 lengh()去查看的話，它的值是不會發生變化的。
對於 最後修改時間這個屬性，只有在文件創建之初和文件傳輸完比之後，纔會發變改變，在傳輸過程中，通過 java 的 File 類的 lastModifiedTime() 去查看的話，它的值也是不會發變化的 - 如果FTP是搭建在 Unix 操作系統上的話，是沒有上面這個問題，在整個文件傳輸過程中， 大小 和 最後修改時間 這兩個屬性是一直在變化的。(我在 CentOS7 上驗證過)
既然上面這個方案有缺陷，那就想想其他方案吧。
後來，在同事的點撥下，找到了 JDK7 中增加的新的 API：File Watch Service。
這個API的思路，其實跟 觀察者 模式是一樣的：對指定的目錄註冊一個 Watcher，當目錄下的文件發生變化時，Java通知你這個 Watcher 說文件變化了。這樣一來，你就可以進行處理了。
下面直接上代碼：
import java.io.File;
import java.io.IOException;
import java.nio.file.FileSystems;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.WatchEvent;
import java.nio.file.WatchKey;
import java.nio.file.WatchService;
import static java.nio.file.StandardWatchEventKinds.*;
public class Sample {
private WatchService watcher;
private Path path;
public Sample(Path path) throws IOException {
this.path = path;
watcher = FileSystems.getDefault().newWatchService();
this.path.register(watcher, OVERFLOW, ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY);
}
public void handleEvents() throws InterruptedException {
// start to process the data files
while (true) {
// start to handle the file change event
final WatchKey key = watcher.take();
for (WatchEvent<?> event : key.pollEvents()) {
// get event type
final WatchEvent.Kind<?> kind = event.kind();
// get file name
@SuppressWarnings("unchecked")
final WatchEvent<Path> pathWatchEvent = (WatchEvent<Path>) event;
final Path fileName = pathWatchEvent.context();
if (kind == ENTRY_CREATE) {
// 說明點1
// create a new thread to monitor the new file
new Thread(new Runnable() {
public void run() {
File file = new File(path.toFile().getAbsolutePath() + "/" + fileName);
boolean exist;
long size = 0;
long lastModified = 0;
int sameCount = 0;
while (exist = file.exists()) {
// if the 'size' and 'lastModified' attribute keep same for 3 times,
// then we think the file was transferred successfully
if (size == file.length() && lastModified == file.lastModified()) {
if (++sameCount >= 3) {
break;
}
} else {
size = file.length();
lastModified = file.lastModified();
}
try {
Thread.sleep(500);
} catch (InterruptedException e) {
return;
}
}
// if the new file was cancelled or deleted
if (!exist) {
return;
} else {
// update database ...
}
}
}).start();
} else if (kind == ENTRY_DELETE) {
// todo
} else if (kind == ENTRY_MODIFY) {
// todo
} else if (kind == OVERFLOW) {
// todo
}
}
// IMPORTANT: the key must be reset after processed
if (!key.reset()) {
return;
}
}
}
public static void main(String args[]) throws IOException, InterruptedException {
new Sample(Paths.get(args[0])).handleEvents();
}
}
對於上面代碼中 “說明點1” ，補充以下幾點說明：
- 這種通過判斷 文件大小 和 文件最後修改時間 處理方式只限於 Unix 操作系統，原因在上面已經說過了。
- 對於 windows 系統，應該在產生 ENTRY_CREATE 這個事件後，繼續監聽，直到產了一個該文件的“ENTRY_MODIFY”事件，或者 ENTRY_DELETE 事件，才說明該文件是傳輸完畢或者被取消傳輸了。
- 內嵌的 Thread 最好另建一個 類，這樣看起來會比較容易理解。
參考文檔