| Wiki Markup |
|---|
It is inappropriate to lock on an object of a class that implements either the {{Lock}} or {{Condition}} interface (or both) of package {{java.util.concurrent.locks}}. Using intrinsic locks of these classes is a questionable practice even though the code may appear to function correctly. This problem is commonly uncovered 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 the intrinsic lock of an instance of {{ReentrantLock}} instead of the reentrant mutual exclusion {{Lock}} encapsulated by {{ReentrantLock}}. |
...
{code |
:bgColor | =#FFcccc | }
private final Lock lock = new ReentrantLock();
public void doSomething() {
synchronized(lock) {
// ...
}
}
|
Similarly, it is inappropriate to lock on an object of a class that implements either the Lock or Condition interface (or both) of package java.util.concurrent.locks. Using intrinsic locks of these classes is a questionable practice even though the code may appear to function correctly. This problem is commonly seen when code is refactored from intrinsic locking to the java.util.concurrent dynamic locking utilities.
Compliant Solution (lock() and unlock())
Instead of using the intrinsic locks of objects that implement the Lock interface, such as ReentrantLock, use the lock() and unlock() methods provided by the Lock interface.
| Code Block |
|---|
|
{code}
h2. Compliant Solution ({{lock()}} and {{unlock()}})
Instead of using the intrinsic locks of objects that implement 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}
If there is no requirement for using the advanced functionality of the dynamic locking utilities of package {{java.util.concurrent}}, prefer using 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 non-deterministic behavior because the class may end up with two different locking policies.
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON39- J | medium | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} |
h3. Automated Detection
The following table summarizes the examples flagged as violations by FindBugs:
||Noncompliant Code Example||Flagged||Checker||Message||
|{{ReentrantLock}} lock object|No||n/a|
The following table summarizes the examples flagged as violations by [SureLogic Flashlight|http://www.surelogic.com/]:
||Noncompliant Code Example||Flagged||Message||
|{{ReentrantLock}} lock object|No|No obvious issues|
h3. Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+CON36-J].
h2. References
{mc} TODO check references {mc}
\[[API 06|AA. Java References#API 06]\] Class String, Collections
\[[Findbugs 08|AA. Java References#Findbugs 08]\].
\[[Pugh 08|AA. Java References#Pugh 08]\] "Synchronization"
\[[Miller 09|AA. Java References#Miller 09]\] Locking
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html]
----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON00-J. Synchronize access to shared mutable variables] [!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!|CON03-J. Do not use background threads during class initialization] |
