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