18) 第二章 索引：锁策略－－Lucene自身提供的锁实现

  首先需要清楚一个大前提：在同一个索引文件上，一次只能存在一个writer！

  那如果有多个IndexWriter要访问一个索引文件该怎么办？加锁！

  Lucene自身提供了4种锁策略：

    1) SimpleFSLockFactory

       这是基于文件系统的索引默认使用的锁的实现方式。

       SimpleFSLockFactory的思路其实就是在IndexWriter访问索引文件的时候，创建一个名为write.lock的文件，再有别的IndexWriter访问该索引文件时，由于发现了write.lock文件的存在，会先暂时等待，直到write.lock被删除。而write.lock则会在某个IndexWriter访问索引文件结束后删除。该实现内部通过调用Java API：File.createNewFile完成。

    2) NativeFSLockFactory

       此实现基于java.nio，它有一个明显的好处是，当IndexWriter发生异常或JVM宕掉的时候，不会残留write.lock文件，因此你也省却了在此种情况下手工清理write.lock文件的麻烦。而如果你选择的是SimpleFSLockFactory，恰巧在索引的时候停电了，同样贫困的客户又没有装备用电源，这时，你只能等来电时，穿着拖鞋、带着倦意来到电脑前，去删除那个万恶的write.lock文件，否则下次服务启动时将不能正常索引。

       既然如此，我们就用NativeFSLockFactory得了，何必要SimpleFSLockFactory呢？因为NativeFSLockFactory在某些共享文件系统中无法正常工作，尤其是NFS

    3) SingleInstanceLockFactory

       这是个内存锁，也正是RAMDirectory的默认实现。

    4) NoLockFactory

       说它是种锁实现有点勉强，它的作用就是不加锁。如果你能保证我们之前提到的“大前提”总是成立，那么就选择它吧！