LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects

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.

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.

private final Lock lock = new ReentrantLock();

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

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.

private final Lock lock = new ReentrantLock();

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

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.

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.

Related Vulnerabilities

Any vulnerabilities resulting from the violation of this rule are listed on the CERT website.

Bibliography

null      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!]      null