It is inappropriate to lock on an object of a class that implements one or both of the following interfaces of the {{java.util.concurrent.locks}} package: {{Lock}} and {{Condition}}. Using the intrinsic locks of these classes is a questionable practice even though the code may appear to function correctly. This problem is commonly discovered 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}} instead of 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()}})
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 {{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 non-deterministic behavior because the class can end up with two different locking policies.
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON10-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. References
{mc} TODO check references {mc}
\[[API 06|AA. Java References#API 06]\]
\[[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!|CON13-J. Do not use an instance lock to protect shared static data] [!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!|CON36CON31-J. Ensure that tasks submitted to a thread pool are interruptible]
| 