我正在使用Lucene.net版本2.9.1，并在调用Optimize时遇到以下问题：
我注意到一些优化调用可能需要几个小时，而当这需要很长时间时，索引和优化的过程不会被杀死。
当我使用源代码时，我设法跟踪问题：导致此行为的调用是Optimize(int maxNumSegments, bool doWait) - 并且在此方法中，对OptimizeMergesPending()的重复调用始终返回true，并且循环继续工作并调用此方法，直到此调用将返回，否则可能需要很长时间。
这提出了以下问题：
1.什么可以导致OptimizeMergesPending()保持回归真实？
2.什么可能导致杀死索引和优化过程的失败？
3.你知道Lucene.net的新版本是否会出现同样的行为吗？
由于
答案 0 :(得分：3)
xmldocs for IndexWriter.OptimizeMergesPending表示如果pendingMerges或runningMerges中的任何合并都是优化合并，它将返回true。 inline documentation for IndexWriter.DoWait表示它只会等待一秒钟，以避免可能无法触发某些通知的问题，由呼叫者重新评估等待条件。我已链接到2.9.4g源代码，因此较新的版本也包含此行为。
一个不可杀死的进程是一个操作系统问题，只要它没有在内核/系统调用中被阻止，你就应该始终能够终止进程。我们需要查看进程转储来调试这些问题。 （或者更好地解释你是如何试图杀死这个过程的......）
反的问题;
IndexWriter.Optimize？ Lucene可以处理多个段，事实上，当只有少数段发生变化时重新打开索引比重新打开包含整个索引的全新段更容易。如果您对当前段的处理有问题，您可以编写自己的MergePolicy。 It has been deprecated as of 3.5，Lucene.Net目前落后（目前高达3.0.3，正在进行4.x的移植）。lock (this) {...}这很糟糕，如果您锁定了编写器，可能会导致死锁问题。这可能看起来好像你的代码挂起了，你可能已经构建的任何干净的线程终止都不会被触发（因为线程只是阻塞）。IndexWriter.Optimize()，在实际合并期间以及重新打开读卡器时，都会导致不必要的cpu和io加载。