Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
Programs are forbidden to lock on an object of a class that implements either or both of the {{Lock}} and {{Condition}} interfaces of the {{java.util.concurrent.locks}} package. Using the intrinsic locks of these classes is a questionable practice even in cases where the code may appear to function correctly. This problem generally arises when code is refactored from intrinsic locking to the {{java.util.concurrent}} dynamic-locking utilities.

h2. Noncompliant Code Example ({{ReentrantLock}} Lock Object)

The {{doSomething()}} method in this noncompliant code example synchronizes on the intrinsic lock of an instance of {{ReentrantLock}} rather than on the reentrant mutual exclusion {{Lock}} encapsulated by {{ReentrantLock}}.

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

public void doSomething() {
  synchronized(lock) {
    // ...
  }
}
{code}


h2. Compliant Solution ({{lock()}} and {{unlock()}})

This compliant solution uses the {{lock()}} and {{unlock()}} methods provided by the {{Lock}} interface.

{code:bgColor=#ccccff}
private final Lock lock = new ReentrantLock();

public void doSomething() {
  lock.lock();
  try {
    // ...
  } finally {
    lock.unlock();
  }
}
{code}

In the absence of a requirement for the advanced functionality of the {{java.util.concurrent}} package's dynamic-locking utilities, it is better to use the {{Executor}} framework or other concurrency primitives such as synchronization and atomic classes.

h2. Risk Assessment

Synchronizing on the intrinsic lock of high-level concurrency utilities can cause nondeterministic behavior because the class can end up with two different locking policies.

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| LCK03-J | medium | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} |


h3. Related Vulnerabilities 

Any vulnerabilities resulting from the violation of this rule are listed on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+CON36-J]. 


h2. Bibliography 
{mc} TODO check references {mc}

| \[[API 2006|AA. Bibliography#API 06]\] | |
| \[[Findbugs 2008|AA. Bibliography#Findbugs 08]\] | |
| \[[Pugh 2008|AA. Bibliography#Pugh 08]\] | "Synchronization" |
| \[[Miller 2009|AA. Bibliography#Miller 09]\] | Locking |
| \[[Tutorials 2008|AA. Bibliography#Tutorials 08]\] | [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html] |

----
[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!|LCK02-J. Do not synchronize on the class object returned by getClass()]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!|08. Locking (LCK)]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!|LCK04-J. Do not synchronize on a collection view if the backing collection is accessible]