檢查文件是否存在沒有太多的垃圾

我想要做到以下幾點：我有一個數據庫填充文件名稱位於目錄下。該目錄不斷變化（正在添加和刪除下載的文件）。我的應用程序應該首次掃描該目錄並將這些文件添加到數據庫中。應用程序第二次運行時，它需要檢查數據庫中的文件名是否仍然在目錄中可用。檢查文件是否存在沒有太多的垃圾

因爲我使用下面的僞代碼檢查：

get the filename from the database 
check if exists (file f = new File(filename)) 
       if (f.exists()){ 
        mark as existing; 
        } else { 
        mark is as deleted 
        } 

if it does, then mark it as existing, else mark it as removed (later will clean the database up)

問題是：我如何檢查數據庫中的所有文件，如果它們存在，而不會產生多少垃圾？文件可能超過1000個。使用「新文件（...）」運行循環1000次以上會導致太多垃圾。

任何幫助表示讚賞。

來源

2012-01-19 Ermir

File()對象真的很小。它只有其中的路徑字符串並且引用了FileSystem對象。它看起來像是浪費資源，但事實並非如此。

將File對象視爲一個路徑字符串，只有很少的幫助方法來處理文件路徑。它與文件描述符或其他重要資源無關。

不要在分析前進行優化。您最終將得到非最佳維護代碼難度。

來源

2012-01-19 19:12:46

這是正確的 - 文件並沒有真正打開文件，但這是解決問題的錯誤方法。 – 2012-01-19 19:13:49

@MichałŠrajer。感謝你的回答。我做了一個簡單的應用程序，看起來像文件對象是一個普通的文件名約100字節。那可能不是我的應用程序的瓶頸。將進一步描述。 +1 – Ermir

文件可能超過1000個。使用「新文件（...）」運行循環1000次以上會導致太多垃圾。

真的嗎？你測試過了嗎？我不認爲這是現代系統下的一個重要問題。（什麼是你最擔心什麼？JVM的垃圾收集？）

否則，獲取當前目錄，然後調用.list()或.listFiles()，負載爲Set性能（一HashSet可能會做很好的），然後就詢問反對集合。（你仍然會在Set中創建Strings和條目，這可能與GC的一個類似問題有關）。這裏可能存在的問題是，您現在正在JVM中將可能「大量」的元素加載到內存中 - 而不是檢查按需讀取數據庫中的每一行。

我會堅持你已經列出的代碼。 +1爲Michal的答案 - 請查看更多詳細信息，爲什麼這麼做不應該擔心。

來源

2012-01-19 19:12:09 ziesemer

那麼，我已經剖析了應用程序，並且掃描時內存變得很高。這就是爲什麼我認爲文件創建將導致此問題。現在很明顯，這只是一個刺痛，它對文件本身沒有任何影響。感謝你的回答。 +1 :) – Ermir

以另一種方式做 - 就是將一組行添加到數據庫表中。然後掃描文件所在的目錄，並獲取文件名列表，並將該列表與「從filestable中選擇名稱」類型的查詢進行比較。

來源

2012-01-19 19:12:38

這也是一種可能性，但不知道它會對性能產生什麼影響。非常感謝您的評論。 – Ermir

檢查文件是否存在沒有太多的垃圾

回答

相關問題