...
This noncompliant code example protects a resource using a ReentrantLock but 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() fails to execute.
| Code Block | ||
|---|---|---|
| ||
public final class Client {
public void doSomething(File file) {
final Lock lock = new ReentrantLock();
InputStream in = null;
try {
lock.lock();
in = new FileInputStream(file);
// Perform operations on the open file
lock.unlock();
} catch (FileNotFoundException x) {
// Handle exception
} finally {
if (in != null) {
try {
in.close();
} catch (IOException x) {
// Handle exception
}
}
}
}
}
|
...
This compliant solution encapsulates operations that could throw an exception in a try block immediately after acquiring the lock. The lock is acquired just before the try block, which guarantees that it is held when the finally block executes. Invoking Lock.unlock() in the finally block ensures that the lock is released regardless of whether an exception occurs or not.
| Code Block | ||
|---|---|---|
| ||
public final class Client {
public void doSomething(File file) {
final Lock lock = new ReentrantLock();
InputStream in = null;
lock.lock();
try {
in = new FileInputStream(file);
// Perform operations on the open file
} catch (FileNotFoundException fnf) {
// Forward to handler
} finally {
lock.unlock();
if (in != null) {
try {
in.close();
} catch (IOException e) {
// Forward to handler
}
}
}
}
}
|
...
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.
| Code Block | ||
|---|---|---|
| ||
public interface LockAction {
void doSomethingWithFile(InputStream in);
}
public final class ReentrantLockAction {
public static void doSomething(File file, LockAction action) {
Lock lock = new ReentrantLock();
InputStream in = null;
lock.lock();
try {
in = new FileInputStream(file);
action.doSomethingWithFile(in);
} catch (FileNotFoundException fnf) {
// Forward to handler
} finally {
lock.unlock();
if (in != null) {
try {
in.close();
} catch (IOException e) {
// Forward to handler
}
}
}
}
}
public final class Client {
public void doSomething(File file) {
ReentrantLockAction.doSomething(file, new LockAction() {
public void doSomethingWithFile(InputStream in) {
// Perform operations on the open file
}
});
}
}
|
...
This noncompliant code example uses a ReentrantLock to protect a java.util.Date instance – recall that java.util.Date is thread-unsafe by design.
| Code Block | ||
|---|---|---|
| ||
final class DateHandler {
private final Date date = new Date();
final Lock lock = new ReentrantLock();
public void doSomething(String str) {
lock.lock();
String dateString = date.toString();
if (str.equals(dateString)) {
// ...
}
// ...
lock.unlock();
}
}
|
...
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.
| Code Block | ||
|---|---|---|
| ||
final class DateHandler {
private final Date date = new Date();
final Lock lock = new ReentrantLock();
public void doSomething(String str) {
lock.lock();
try {
String dateString = date.toString();
if (str != null && str.equals(dateString)) {
// ...
}
// ...
} finally {
lock.unlock();
}
}
}
|
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
LCK08-J | low | likely | low | P9 | L2 |
Automated Detection
Some static analysis tools are capable of detecting violations of this rule.
| Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| ThreadSafe |
| CCE_LK_UNRELEASED_ON_EXN | Implemented |
Related Vulnerabilities
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. Futhermore, the server cannot be restarted because the lock is never cleared.
...
[API 2006] | Class |