ReentrantLockis owned by the thread last successfully locking, but not yet unlocking it. A thread invoking
lockwill return, successfully acquiring the lock, when the lock is not owned by another thread.
Consequently, an unreleased lock in any thread will prevent other threads from acquiring the same lock. Programs must release all actively held locks on exceptional conditions. Intrinsic locks of class objects used for method and block synchronization are automatically released on exceptional conditions (such as abnormal thread termination).
This guideline is an instance of FIO04-J. Release resources when they are no longer needed. However, most Java lock objects are not closeable, so they cannot be automatically released using Java 7's
Noncompliant Code Example (Checked Exception)
This noncompliant code example protects a resource, an open file, by using a
ReentrantLock. However, the method fails to release the lock when an exception occurs while performing operations on the open file. When an exception is thrown, control transfers to the
catch block and the call to
unlock() never executes.
Noncompliant Code Example (
This noncompliant code example attempts to rectify the problem of the lock not being released by invoking
Lock.unlock() in the
finally block. This code ensures that the lock is released regardless of whether or not an exception occurs. However, it does not acquire the lock until after trying to open the file. If the file cannot be opened, the lock may be unlocked without ever being locked in the first place.
Compliant Solution (
This compliant solution encapsulates operations that could throw an exception in a
try block immediately after acquiring the lock (which cannot throw). The lock is acquired just before the
try block, which guarantees that it is held when the
finally block executes.
Compliant Solution (Execute-Around Idiom)
The execute-around idiom provides a generic mechanism to perform resource allocation and cleanup operations so that the client can focus on specifying only the required functionality. This idiom reduces clutter in client code and provides a secure mechanism for resource management.
In this compliant solution, the client's
doSomething() method provides only the required functionality by implementing the
doSomethingWithFile() method of the
LockAction interface without having to manage the acquisition and release of locks or the open and close operations of files. The
ReentrantLockAction class encapsulates all resource management actions.
Noncompliant Code Example (Unchecked Exception)
This noncompliant code example uses a
ReentrantLock to protect a
java.util.Date instance—recall that
java.util.Date is thread-unsafe by design.
A runtime exception can occur because the
doSomething() method fails to check whether
str is a null reference, preventing the lock from being released.
Compliant Solution (
This compliant solution encapsulates all operations that can throw an exception in a
try block and releases the lock in the associated
finally block. Consequently, the lock is released even in the event of a runtime exception.
doSomething() method also avoids throwing a
NullPointerException by ensuring that the string does not contain a null reference.
Some static analysis tools are capable of detecting violations of this rule.
|Release Locks in a "finally" block|
Do not abandon unreleased locks
The GERONIMO-2234 issue report describes a vulnerability in the Geronimo application server. If the user single-clicks the keystore portlet, the user will lock the default keystore without warning. This causes a crash and stack trace to be produced. Furthermore, the server cannot be restarted because the lock is never cleared.