我的问题被认为是Lucene .NET 2.9.2
假设我使用IndexWriter更新了索引，这导致调度程序开始合并后台中的段。如果我在合并完成之前致电Commit会怎样？将调用调用Commit的线程并等待合并完成，或者两个线程是否独立？
答案对于我的搜索实现非常重要，因为我依赖FieldCache来解决性能问题，如果Commit不等待合并完成，我可能会出错DocIds ...
更新
我要做的是DocId与Appliciation Id之间的映射 - 因此在使用IndexSearcher搜索方法时，我不需要获取应用程序ID的存储值。
所以我试图在索引期间构建映射，将该映射保存到二进制文件 - 并在我的搜索中 - 将该文件加载到数组（内存中......）。所以文件版本必须包含IndexReader（希望很清楚......）
例如： （索引流程代码）
IndexWriter writer = //initialize writer
//modify index using the writer add\delete\update doc methods...
//get updated reader to the index
IndexReader r1= wrtier.GetReader();
//read all values for all documents for specific field name.
long[] ids = FieldCache_Fields.DEFAULT.GetLongs(r1, "ID");
//serialize the array to a file (code not provided)
Dictionary<string,string> metaData = new Dictionary<string,string>();
metaData.Add("FileName", /*full path to the serialized file*/);
writer.Commit(metaData);
（搜索者流程代码）
IndexReader r2 = //IndexRead.Open...
Dictionary<string,string> metaData = r2.GetCommitUserData()
string fullPathToFile = metaData["FileName"]; //get the file name that was serialized
//load the array from the file (=deserialize file)
long[] ids = //load from file
//now I can convert internal DocId to my Application Id, and save time instead of fetching data from the stored field (which takes more time...)
基本上我的问题是：在假设没有对索引进行其他修改的情况下，两个读者r1和r2的DocIds是否有可能不适合？
答案 0 :(得分：1)
后台合并不会阻止您的提交。
但是我不明白你的FieldCache问题：IndexReader是不可变的，fieldcache实例永远不会变得无效..