最近同事发来一个bug，如图所示：
以前跑的一直是没问题，但不知为何突然会报这个错。
google一下搜到：http://www.gossamer-threads.com/lists/lucene/java-user/100965
其中ian.lea at gmail 提出几点：
1、文件路径问题。
2、使用SimpleFSLockFactory而不是默认的native class类。
3、使用lucene的最新版本。
由于无法远程调试这个问题还得等到下周同事过去才能去处理。
趁着这机会又去了解了一下Lucene中的Lock。
图1-lock实现类
图2-LockFactory实现类
SingleInstanceLockFactory：用一个lock对象来表示锁定，默认用于RAMDirectory。
Implements LockFactory for a single in-process instance, meaning all locking will take place through this one instance. Only use this LockFactory when you are certain all IndexReaders and IndexWriters for a given index are running against a single shared in-process Directory instance. This is currently the default locking for RAMDirectory.
NoLockFactory：就是不采用lock。
Use this LockFactory to disable locking entirely. Only one instance of this lock is created. You should call getNoLockFactory() to get the instance.
文件锁有两种NativeFSLockFactory和SimpleFSLockFactory。
SimpleFSLockFactory：锁的一种简单实现。
Implements LockFactory using File.createNewFile().
NOTE: the javadocs for File.createNewFile contain a vague yet spooky warning about not using the API for file locking. This warning was added due to this bug, and in fact the only known problem with using this API for locking is that the Lucene write lock may not be released when the JVM exits abnormally.
When this happens, a LockObtainFailedException is hit when trying to create a writer, in which case you need to explicitly clear the lock file first. You can either manually remove the file, or use the IndexWriter.unlock(Directory) API. But, first be certain that no writer is in fact writing to the index otherwise you can easily corrupt your index.
NativeFSLockFactory（Lucene3中开始设为默认锁）：是调用OS本身的锁定机制，这又是来自NIO的支持(private FileLock lock;lock = channel.tryLock();)。相比缺省的SimpleFSLockFactory，这种锁才是真正的锁。在File.createNewFile()的javadoc中，明确指出用这个方法来做锁是不可靠的。但是不是所有的文件系统都支持锁机制的，有些文件系统要经过配置才能支持（注释里提到NFS）。没办法的情况下，只好用SimpleFSLockFactory来凑个数。
Implements LockFactory using native OS file locks. Note that because this LockFactory relies on java.nio.* APIs for locking, any problems with those APIs will cause locking to fail. Specifically, on certain NFS environments the java.nio.* locks will fail (the lock can incorrectly be double acquired) whereas SimpleFSLockFactory worked perfectly in those same environments. For NFS based access to an index, it's recommended that you try SimpleFSLockFactory first and work around the one limitation that a lock file could be left when the JVM exits abnormally.
The primary benefit of NativeFSLockFactory is that lock files will be properly removed (by the OS) if the JVM has an abnormal exit.
Note that, unlike SimpleFSLockFactory, the existence of leftover lock files in the filesystem on exiting the JVM is fine because the OS will free the locks held against these files even though the files still remain.
在API中还有这么一句话：If you suspect that this or any other LockFactory is not working properly in your environment, you can easily test it by using VerifyingLockFactory, LockVerifyServer and LockStressTest.
当你猜测在你的环境中某个锁文件不能正常工作，则可以通过 VerifyingLockFactory, LockVerifyServer 和LockStressTest很容易地测试出来。
VerifyingLockFactory
A LockFactory that wraps another LockFactory and verifies that each lock obtain/release is "correct" (never results in two processes holding the lock at the same time). It does this by contacting an external server (LockVerifyServer) to assert that at most one process holds the lock at a time. To use this, you should also run LockVerifyServer on the host & port matching what you pass to the constructor.
LockVerifyServer
Simple standalone server that must be running when you use VerifyingLockFactory. This server simply verifies at most one process holds the lock at a time.
Run without any args to see usage.
LockStressTest
Simple standalone tool that forever acquires & releases a lock using a specific LockFactory. Run without any args to see usage.