Page History

...

Consequently, an unreleased lock in any thread will stop 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 noncompliant code example protects a resource using a ReentrantLock but fails to release the lock if an exception occurs while performing operations on the open file. If When an exception is thrown, control transfers to the catch block and the call to unlock() is not executed fails to execute.

public final class Client {
  public void doSomething(File file) {
    final Lock lock = new ReentrantLock();
    try {
      lock.lock();
      InputStream in = new FileInputStream(file);
      // Perform operations on the open file
      lock.unlock();
    } catch (FileNotFoundException fnf) {
      // Handle the exception
    }
  }
}

Note that the lock is not releasedstill held, even when the doSomething() method returns.

This noncompliant code example does not also fails to close the input stream and, consequently, also violates rule FIO06-J. Ensure all resources are properly closed when they are no longer needed.

...

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 or not an exception occurs.

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
        }
      }
    }
  }
}

...

This noncompliant code example uses a ReentrantLock to protect a java.util.Date instance , which is not thread-– recall that java.util.Date is thread-_un_safe by design. The doSomethingSafely() method must catch Throwable to comply with rule ERR06-J. Do not allow exceptions to expose sensitive information.

final class DateHandler {
  private final Date date = new Date();
  final Lock lock = new ReentrantLock();

  public void doSomethingSafely(String str) {
    try {
      doSomething(str);
    } catch(Throwable t) {
      // Forward to handler
    }
  }

  public void doSomething(String str) {
    lock.lock();
    String dateString = date.toString();
    if (str.equals(dateString)) {
      // ...
    }
    lock.unlock();
  }
}

Because A runtime exception can occur because the doSomething() method fails to check if whether str is null, a runtime exception can occur, preventing the lock from being released.

...

Consequently, the lock is released even in the event of a runtime exception. The doSomething() method also ensures that the string is not non-null to avoid throwing a NullPointerException.

...

Automated Detection

...

Related Vulnerabilities

GERONIMO-2234

...

...