Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Instances of classes that implement either or both of the Lock and Condition interfaces of the java.util.concurrent.locks package are known as high-level concurrency objects. Using the intrinsic locks of such objects is a questionable practice even in cases where the code may appear to function correctly. 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 forbiddenprohibited. 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 rather than on the reentrant mutual exclusion Lock encapsulated by ReentrantLock.

Code Block
bgColor#FFcccc

private final Lock lock = new ReentrantLock();

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

...

This compliant solution uses the lock() and unlock() methods provided by the Lock interface.

Code Block
bgColor#ccccff

private final Lock lock = new ReentrantLock();

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

In the absence of a requirement for 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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

LCK03-J

medium

probable

medium

P8

L2

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="deb55462-6a4d-4f55-9a1b-6409c2240beb"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5642960b-3186-499a-b79e-73a02f9a780a"><ac:plain-text-body><![CDATA[

[[Findbugs 2008

AA. Bibliography#Findbugs 08]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="062177f1-d958-45a6-94ee-feeb9c02c519"><ac:plain-text-body><![CDATA[

[[Pugh 2008

AA. Bibliography#Pugh 08]]

"Synchronization"

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c16fa74c-ac5a-4559-a317-f94230fdba39"><ac:plain-text-body><![CDATA[

[[Miller 2009

AA. Bibliography#Miller 09]]

Locking

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a55ab01e-03c7-473e-b261-b180ac6eba83"><ac:plain-text-body><![CDATA[

[[Tutorials 2008

AA. Bibliography#Tutorials 08]]

[Wrapper Implementations

http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html]

]]></ac:plain-text-body></ac:structured-macro>

Automated Detection

ToolVersionCheckerDescription
SonarQube
Include Page
SonarQube_V
SonarQube_V
S2442Implemented


Bibliography


...

Image Added      Image AddedImage Removed      08. Locking (LCK)