lucene已經調用optimize和close方法，爲何索引路徑下還有上千個.cfs文件?

lucene已經調用optimize和close方法，爲何索引路徑下還有上千個.cfs文件?
lucene作中文搜索增長索引的時候，已經調用了optimize方法，爲何索引路徑下還有上千個.cfs文件?

在網上查到的資料裏有這樣的提法，「若是lucene的索引目錄下出現了不少文件, 確定是有問題的. 幾個方面.首先lucene在執行寫操做時, 會先在目錄下寫如一個write.lock的文件鎖定這個目錄,以免別的索引再操做這個路徑. 不然那樣確定會亂. 鎖定以後, 開始寫索引, 寫索引時lucene建了幾個或者幾十個臨時片斷文件, 都彷佛又短又亂的字符.cfs的文件. 當索引創建完畢後,沒有執行 indexWriter.optimize();方法, 他就不會合並那些亂七八糟的文件. 因此,索引建完後, 必定要執行 上面的優化方法, 保持目錄下保留3個文件便可. 也就是不少臨時文件會合併到一個文件中去. 切不可大意刪除. 但當數據不少時, 另行考慮策略.」

按照該提法在個人索引目錄下應該只有三個文件：egments.gen segments_a08, 還有一個相似 _uw.cfs名字的東西.

可是實際狀況倒是對近5W條紀錄重建索引，執行增長到索引庫的操做，最後產生了上千個.cfs文件，和一個segments_8pi文件，以及相似於_4cq.tii、_4cq.fdt、_4cq.fnm這樣的擴展名不固定的文件，請問這種狀況是因爲什麼緣由形成的？
重建索引庫的程序思路是這樣的：
1.清空索引庫，也就是刪除索引目錄下的全部文件
2.把全部紀錄從數據庫裏取出來;
3.把每條紀錄加入處處理lucene的線程的處理對列裏;
4.在處理lucene線程的run方法中對處理對列的每個對象調用IndexWriter對象的addDocument方法增長到索引庫,隨後依次調用optimize和close方法。

固然該思路來講，每一次addDocument以後都調用optimize對性能會有很大的影響，可是先不考慮性能，單從程序的邏輯上來講，我以爲是沒有問題的，可是就是不明白爲何個人索引目錄下會有上千個.cfs文件，和一個segments_8pi文件，以及相似於_4cq.tii、_4cq.fdt、_4cq.fnm這樣的擴展名不固定的文件？這種現象正常嗎？若是不正常的話，應該如何解決？

 

 

lucene已經調用optimize和close方法，爲何索引路徑下還有上千個.cfs文件?
[此問題的推薦答案]
根據你的描述，我推測你在lucene裏使用了indexSearcher方法，而且對檢索結果進行了delete操做，可是用完以後並無把indexSearcher關閉。所形成的後果就是，當你調用indexSearcher相關方法的時候，lucene索引庫目錄下的某些文件都處於被使用狀態，這時候即便調用optimize方法，也沒法對這些處於被使用狀態的文件進行操做，達不到優化的目的，這樣的文件就會越累積越多，最終超過操做系統所能支持的目錄文件的極限。
本貼來自ZDNetChina中文社區 http://bbs.zdnet.com.cn ,本貼地址： http://bbs.zdnet.com.cn/viewthread.php?tid=492303