在将 Lucene.Net 与 ASP.NET 一起使用时，我可以想象一个 Web 请求可以触发对索引的更新，而另一个 Web 请求正在执行搜索。Lucene.Net 是否内置了管理并发访问的能力，还是我必须管理它，以避免“被另一个进程使用”错误？
编辑：在阅读文档和实验之后，这就是我认为我学到的：有两个问题，线程安全和并发。多线程是“安全的”，因为您不能对索引做任何坏事。但是，这是安全的，代价是一次只有一个对象锁定索引。第二个对象会出现并抛出异常。因此，您不能打开搜索并期望另一个线程中的作者能够更新索引。如果一个线程忙于更新索引，那么尝试创建搜索器将会失败。
此外，搜索者会看到他们打开时的索引，因此如果您保留它们并更新索引，他们将不会看到更新。
我希望我的搜索者看到最新的更新。
我的设计，到目前为止似乎还有效，是我的作者和搜索者共享一个锁，这样他们就不会失败——他们只是等待——直到当前的写入或搜索完成。
根据这个页面，
索引和搜索不仅是线程安全的，而且是进程安全的。这意味着：
- 多个索引搜索器可以同时读取 lucene 索引文件。
- 索引编写器或读取器可以在搜索进行时编辑 lucene 索引文件
- 多个索引写入器或读取器可以尝试同时编辑 lucene 索引文件（关闭索引写入器/读取器很重要，这样它将释放文件锁定）。但是，查询解析器不是线程安全的，因此每个使用索引的线程都应该有自己的查询解析器。
然而，索引编写器是线程安全的，因此您可以在人们搜索索引时更新索引。但是，您必须确保具有打开索引搜索器的线程关闭它们并打开新的，以获取新更新的数据。
You may have issues, if your indexing thread is creating a new document which results in merging of some index segments, then the merged segments will be deleted and new segment will be created. The problem is that your index searcher loaded up all the segments when it was opened, such that is has "pointers" to those segments which existed when it was opened. Now if the index writer does a segment merge and deletes a segment, your index searcher will still think that segment file exists and will fail with a "file not found error". What you really need to do is seperate your writable index from your searchable index, by using SOLR or doing your own index snapshot replication similar to what SOLR does. I have build very similar system to SOLR using .NET and Lucene.NET on Windows, using NTFS hard-links to make efficient snapshot replication. I can give you more info if you are interested.
与管理对索引的并发写入相比，您没有问题。我有一条更简单的 SOLR 路径，因为它作为服务器运行，所以它为我抽象了大部分差异。