Page History

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

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

public final class Client {
  private [API 06|AA. Java References#API 06]\]:

{quote}
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.
{quote}

This means that an unreleased lock in any thread will stop other threads from acquiring the same lock. Note that this guideline does not apply to classes that only use method or block synchronization because these concurrency primitives ensure that the respective monitor locks are released on exceptional conditions.


h2. Noncompliant Code Example (checked exception)

This noncompliant code example protects a resource using a {{ReentrantLock}} but fails to release the lock on an exceptional condition. Control flow transfers to the {{catch}} block and the call to {{unlock()}} does not execute.

{mc} lock is package-private so that a caller can access and use it from the same package/component. No need to provide a getter method really. {mc}

{code:bgColor=#FFcccc}
public void doSomething(File file) {
  final Lock lock = new ReentrantLock();

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

Note that the lock is not released even when the {{doSomething()}} method terminates or returns. 


h2. Compliant Solution ({{try}}-{{finally}} block)

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 just outside the try block, which guarantees that it is held when the finally block executes.

{code:bgColor=#ccccff}
public void doSomething(File file) {
   } finally {
      lock.unlock();
      if (in != null) {
        try {
          in.close();
        } catch (IOException e) {
          // Forward to handler
        }
      }
    }
  }
}

public final 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();

  }
}
{code}


h2. Noncompliant Code Example (unchecked exception)

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

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

public final class ReentrantLockAction {
  private static noncompliant code example uses a {{ReentrantLock}} to protect a {{java.util.Date}} instance, which is not thread-safe by design. It also needs to catch {{Throwable}} to be compliant with [EXC06-J. Do not allow exceptions to transmit sensitive information]. 

{mc} Do not declare lock as private as it need package-wide accessibility for illustrative purposes {mc}

{code:bgColor=#FFcccc}
final class DateHandler {
  private final Date date = new Date();
  final Lock lock = new ReentrantLock();

  public static void doSomethingSafely(String str) {doSomething(File file, LockAction action)  {
    InputStream in = null;
    lock.lock();
    try {
      doSomething(strin = new FileInputStream(file);
      action.doSomethingWithFile(in);
    } catch (ThrowableFileNotFoundException tfnf) {
      // Forward to handler
    } finally {
    }  lock.unlock();

     public voidif doSomething(String strin != null) {
         lock.lock();
try {
      String  dateString = datein.toStringclose();
    if (str.equals(dateString))    } catch (IOException e) {
          // ...Forward to handler
        }
    lock.unlock();  }
    }
  }
{code}

However, because the {{doSomething()}} method does not check whether {{str}} is {{null}}, a runtime exception in this component may prevent the lock from being released.


h2. Compliant Solution ({{try}}-{{finally}} block)

This compliant solution adds a {{finally}} block that contains the {{unlock()}} call. 

{code:bgColor=#ccccff}
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
      }
    });
  }
}

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) {
    lock.lock();
    try {
      String dateString = date.toString();
      if (str != null && str.equals(dateString)) {
        // ...
      }
    } finally {
  // ...

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

Consequently, the lock is released even in the event of a runtime exception. The {{doSomething()}} method also checks the string for null to avoid the {{NullPointerException}}.


h2. Exceptions

*EX1* : Intrinsic locks of class objects used for method and block synchronization are automatically released on exceptional conditions such as abnormal thread termination.


h2. Risk Assessment

Failing to release locks on exceptional conditions may lead to thread starvation and deadlock.

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON15- J | low | likely | low | {color:#cc9900}{*}P9{*}{color} | {color:#cc9900}{*}L2{*}{color} |



h3. Automated Detection

TODO


h3. Related Vulnerabilities

[GERONIMO-2234|http://issues.apache.org/jira/browse/GERONIMO-2234]

h2. References

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

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON14-J. Ensure atomicity of 64-bit operations]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON16-J. Do not expect sleep(), yield() and getState() methods to have any synchronization semantics]

}

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();
    try {
      String dateString = date.toString();
      if (str != null && str.equals(dateString)) {
        // ...
      }
      // ...

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