Page History

Wiki MarkupAn exceptional condition may can circumvent the release of a lock. This can result in thread starvation and deadlock. According to the Java API \[[API 06|AA. Java References#API 06]\], class {{ReentrantLock}} documentationlock, leading to deadlock. According to the Java API [API 2014]:

A ReentrantLock is owned by the thread last successfully locking, but not yet unlocking it. A thread invoking lock will return, successfully acquiring the lock, when the lock is not owned by another thread.

This means that 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 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 try-with-resources feature.

Noncompliant Code Example (

...

Checked Exception)

This noncompliant code example protects a resource, an open file, by using a ReentrantLock but on an exceptional condition, a ReentrantLock. However, the method fails to release the lock . Control flow transfers to the catch block 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 to unlock() does not execute never executes.

public voidfinal doSomething(File file)class Client {
  private final Lock lock = new ReentrantLock();

  public void doSomething(File tryfile) {
    lock.lock()InputStream in = null;
     InputStreamtry {
      in = new FileInputStream( filefile);
      lock.lock();

      // DoPerform somethingoperations withon the open file.

      lock.unlock();
    } catch (FileNotFoundException fnfx) {
      // Handle the exception
  }
}

Note that the lock is not released even when the doSomething() method returns.

Compliant Solution

exception
    } finally {
      if (in != null) {
        try {
          in.close();
        } catch (IOException x) {
          // Handle exception
        }  
      }
    }
  }
}

Noncompliant Code Example (finally Block)

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.

public final class Client {
  private final Lock lock = new ReentrantLock();

  public void doSomething(File file) {
    InputStream in = null;
    try {
      in = new FileInputStream(file);
      lock.lock();
      // 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
        }
      }
    }
  }
}

Compliant Solution (finally Block)

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 This compliant solution uses a try-finally block immediately after acquiring the lock. This ensures that the lock is appropriately released even in the event of an exceptional condition. Also the lock is acquired outside the try block, which guarantees that the lock it is actually obtained held when the finally clause block executes.

public voidfinal doSomething(File file)class Client {
  private final Lock lock = new ReentrantLock();

  public void doSomething(File file) {
    InputStream in = null;
    lock.lock();
    try {
     InputStream in = new FileInputStream( file);
      // DoPerform somethingoperations withon the open file.
    } catch (FileNotFoundException fnf) {
      // HandleForward theto exceptionhandler
    } finally {
      lock.unlock();

      if (in != null) {
        try {
          in.close();
        } catch (IOException e) {
          // Forward to handler
        }
      }
    }
  }
}

Noncompliant Code Example (unchecked exception)

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 actionsThis noncompliant code example protects the thread-unsafe Date instance using a ReentrantLock. It also needs to catch Throwable to be compliant with EXC06-J. Do not allow exceptions to transmit sensitive information.

public interface LockAction {
  void doSomethingWithFile(InputStream in);
}

public final class ReentrantLockAction
class DateHandler {
  private Date datestatic final Lock lock = new Date()ReentrantLock();

  public static void doSomething(File file, LockAction action)  {
    InputStream in = null;
  final Lock lock.lock();
    try {
      in = new ReentrantLock FileInputStream(file);
      action.doSomethingWithFile(in);
    } catch (FileNotFoundException fnf) {
      // Forward to handler
    } finally {
      lock.unlock();

     public voidif doSomethingSafely(String strin != null) {
        try {
          doSomethingin.close(str);
        } catch (ThrowableIOException te) {
          // 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
      }
    });
  }
}

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.

final class DateHandler {

  private final Date date = new Date();

  private final Lock lock = new ReentrantLock();

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

    lock.unlock();
  }
}

However, A runtime exception can occur because the doSomething() method does not fails to check whether str is a null , a runtime exception in this component may prevent reference, preventing the lock from being released.

Compliant Solution (finally Block)

This compliant solution adds a finally block and moves the unlock() call into itencapsulates 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.

final class DateHandler {

  private final Date date = new Date();

  private final Lock lock = new ReentrantLock();

  public void doSomethingSafely(String str) {
    try {
      doSomething(str);
    } catch(Throwable t) {
      // Forwardstr tocould handler
    }
  }
be null
  public void doSomething(String str) {
    try {lock.lock();
      lock.lock();try {
      String dateString = date.toString();
      if (str != null && str.equals(dateString)) {
        // ...
      }
      // ...

    } finally {
      lock.unlock();
    }
  }
}

Consequently, the lock is released successfully even in the event of a runtime exception.

Exceptions

EX1 : Intrinsic locks are associated with the use of the synchronized keyword, and are automatically released on exceptional conditions such as abnormal thread termination.

Risk Assessment

The doSomething() method also avoids throwing a NullPointerException by ensuring that the string does not contain a null reference.

Risk Assessment

Failure to release locks on exceptional conditions could Failing to release a lock on an exceptional condition may lead to thread starvation and deadlock.

Automated Detection

...

Some static analysis tools are capable of detecting violations of this rule.

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.LCK08.RLF CERT.LCK08.LOCK	Release Locks in a "finally" block Do not abandon unreleased locks
ThreadSafe	Include Page ThreadSafe_V ThreadSafe_V	CCE_LK_UNRELEASED_ON_EXN	Implemented

Related Vulnerabilities

The GERONIMO-2234

References

\[[API 06|AA. Java References#API 06]\] Class {{ReentrantLock}}

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.

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedVOID CON14-J. Ensure atomicity of 64-bit operations      11. Concurrency (CON)      CON16-J. Do not expect sleep() and yield() methods to have any synchronization semantics