Page History

It is inappropriate to lock on an object of a class that implements one Instances of classes that implement either or both of the following Lock and Condition interfaces of the java.util.concurrent.locks package : Lock and Conditionare known as high-level concurrency objects. Using the intrinsic locks of these classes such objects is a questionable practice even though in cases where the code may appear to function correctly. This problem is commonly discovered . Code that uses the intrinsic lock of a Lock object is likely to interact with code that uses the Lock interface. These two components will believe they are protecting data with the same lock, while they are, in fact, using two distinct locks. As such, the Lock will fail to protect any data.

Consequently, programs that interact with such objects must use only the high-level locking facilities provided by the interfaces; use of the intrinsic locks is prohibited. This problem generally arises when code is refactored from intrinsic locking to the java.util.concurrent dynamic-locking utilities.

Noncompliant Code Example (ReentrantLock

...

)

The doSomething() method in this noncompliant code example synchronizes on the intrinsic lock of an instance of ReentrantLock instead of rather than on 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 This compliant solution uses 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 In the absence of a 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 use other concurrency primitives such as synchronization and atomic classes.

...

Synchronizing on the intrinsic lock of high-level concurrency utilities can cause nondeterministic behavior because the class can end up with two different resulting from inconsistent locking policies.

References

\[[API 2006|AA. Java References#API 06]\]
\[[Findbugs 2008|AA. Java References#Findbugs 08]\]
\[[Pugh 2008|AA. Java References#Pugh 08]\] "Synchronization"
\[[Miller 2009|AA. Java References#Miller 09]\] Locking
\[[Tutorials 2008|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html]

Automated Detection

Bibliography

...

Image Added      Image AddedImage Removed      12. Locking (LCK)