Base class for Directory implementations that store index
files in the file system.
There are currently three core
subclasses:

SimpleFSDirectory is a straightforward
implementation using java.io.RandomAccessFile.
However, it has poor concurrent performance
(multiple threads will bottleneck) as it
synchronizes when multiple threads read from the
same file.

MMapDirectory uses memory-mapped IO when
reading. This is a good choice if you have plenty
of virtual memory relative to your index size, eg
if you are running on a 64 bit JRE, or you are
running on a 32 bit JRE but your index sizes are
small enough to fit into the virtual memory space.
Java has currently the limitation of not being able to
unmap files from user code. The files are unmapped, when GC
releases the byte buffers. Due to
this bug in Sun's JRE, MMapDirectory's FSDirectory.FSIndexInput.close()
is unable to close the underlying OS file handle. Only when
GC finally collects the underlying objects, which could be
quite some time later, will the file handle be closed.
This will consume additional transient disk usage: on Windows,
attempts to delete or overwrite the files will result in an
exception; on other platforms, which typically have a "delete on
last close" semantics, while such operations will succeed, the bytes
are still consuming space on disk. For many applications this
limitation is not a problem (e.g. if you have plenty of disk space,
and you don't rely on overwriting files on Windows) but it's still
an important limitation to be aware of. This class supplies a
(possibly dangerous) workaround mentioned in the bug report,
which may fail on non-Sun JVMs.
Applications using Thread.interrupt() or
Future.cancel(boolean) should use
SimpleFSDirectory instead. See MMapDirectory
java doc for details.

Unfortunately, because of system peculiarities, there is
no single overall best implementation. Therefore, we've
added the open(java.io.File) method, to allow Lucene to choose
the best FSDirectory implementation given your
environment, and the known limitations of each
implementation. For users who have no reason to prefer a
specific implementation, it's best to simply use open(java.io.File). For all others, you should instantiate the
desired implementation directly.

open

Creates an FSDirectory instance, trying to pick the
best implementation given the current environment.
The directory returned uses the NativeFSLockFactory.

Currently this returns MMapDirectory for most Solaris
and Windows 64-bit JREs, NIOFSDirectory for other
non-Windows JREs, and SimpleFSDirectory for other
JREs on Windows. It is highly recommended that you consult the
implementation's documentation for your platform before
using this method.

NOTE: this method may suddenly change which
implementation is returned from release to release, in
the event that higher performance defaults become
possible; if the precise implementation is important to
your application, please instantiate it directly,
instead. For optimal performance you should consider using
MMapDirectory on 64 bit JVMs.

setLockFactory

Set the LockFactory that this Directory instance should
use for its locking implementation. Each * instance of
LockFactory should only be used for one directory (ie,
do not share a single instance across multiple
Directories).

getLockID

Return a string identifier that uniquely differentiates
this Directory instance from other Directory instances.
This ID should be the same if two Directory instances
(even in different JVMs and/or on different machines)
are considered "the same index". This is how locking
"scopes" to the right index.