ItPrograms isare inappropriateforbidden to lock on an object of a class that implements oneeither or both of the following {{Lock}} and {{Condition}} interfaces of the {{java.util.concurrent.locks}} package: {{Lock}} and {{Condition}}. Using the intrinsic locks of these classes is a questionable practice even in thoughcases where the code may appear to function correctly. This problem isgenerally commonly discoveredarises 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 insteadthan ofon 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()}})
InsteadThis ofcompliant using the intrinsic locks of objects that implement solution uses the {{Lock}} interface, such as {{ReentrantLock}}, use 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}
IfIn the thereabsence isof noa requirement for using 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]
| 