overlaps(long, long)
Locks are shared amongst all threads in the acquiring process, and are therefore unsuitable for
intra-process synchronization.
Once a lock is acquired it is immutable in all its state except isValid(). The lock
will initially be valid, but may be rendered invalid by explicit removal of the lock, using
release(), or implicitly by closing the channel or exiting the process (terminating the JVM).
Platform dependencies
Locks are intended to be true platform operating system file locks, and therefore locks held by the
JVM process will be visible to other OS processes.
The characteristics of the underlying OS locks will show through in the Java implementation. For
example, some platforms' locks are 'mandatory' -- meaning the operating system enforces the locks
on processes that attempt to access locked regions of file; whereas other platforms' locks are
only 'advisory' -- meaning that processes are required to collaborate on ensuring locks are acquired
and there is a potential for processes not to play well. The only safe answer is to assume that
the platform is adopting advisory locks an always acquire shared locks when reading a region of file.
On some platforms the presence of a lock will prevent the file being memory mapped. On some platforms
closing a channel on a given file handle will release all the locks held on that file -- even if there
are other channels open on the same file (their locks will be released). The safe option here is to
ensure that you only acquire locks on a single channel for a particular file, and that becomes the
synchronization point.
Further care should be exercised when locking files maintained on network file systems since they often
have further limitations.
