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
.
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.
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 dynamic locking utilities of package java.util.concurrent
, prefer using the Executor
framework or other concurrency primitives such as synchronization and atomic classes.