FileLock

Class Overview

A FileLock represents a locked region of a file.

Locks have certain properties that enable collaborating processes to avoid the lost update problem or reading inconsistent data. Logically, a file lock can be exclusive or shared. Multiple processes can hold shared locks on the same region of a file, but only a single process can hold an exclusive lock on a given region of a file and no other process can simultaneously hold a shared lock overlapping the exclusive lock. An application can determine whether a FileLock is shared or exclusive via the isShared() method.

Locks held by a particular process cannot overlap one another. Applications can determine whether a proposed lock will overlap by using the overlaps(long, long)) method. Locks held in other processes may overlap locks held in this process. 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 virtual machine).

Platform dependencies

Locks are intended to be true platform operating system file locks, and therefore locks held by the virtual machine process will be visible to other operating system processes.

The characteristics of the underlying operating system 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 files; whereas other platforms' locks are only 'advisory' -- meaning that processes are required to collaborate to ensure locks are acquired and there is a potential for processes to not play well. To be on the safe side, it is best to assume that the platform is adopting advisory locks and always acquire shared locks when reading a region of a file.

On some platforms, the presence of a lock will prevent the file from 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 also 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.

Summary

[Expand] Inherited Methods

From class java.lang.Object Object clone() Creates and returns a copy of this Object. boolean equals(Object o) Compares this instance with the specified object and indicates if they are equal. void finalize() Called before the object's memory is reclaimed by the VM. final Class<? extends Object> getClass() Returns the unique instance of Class that represents this object's class. int hashCode() Returns an integer hash code for this object. final void notify() Causes a thread which is waiting on this object's monitor (by means of calling one of the wait() methods) to be woken up. final void notifyAll() Causes all threads which are waiting on this object's monitor (by means of calling one of the wait() methods) to be woken up. String toString() Returns a string containing a concise, human-readable description of this object. final void wait() Causes the calling thread to wait until another thread calls the notify() or notifyAll() method of this object. final void wait(long millis, int nanos) Causes the calling thread to wait until another thread calls the notify() or notifyAll() method of this object or until the specified timeout expires. final void wait(long millis) Causes the calling thread to wait until another thread calls the notify() or notifyAll() method of this object or until the specified timeout expires.