Versions Compared

Key

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

Misuse of synchronization primitives is a common source of concurrency issues. Synchronizing on objects that may be reused can result in deadlock and non-deterministic nondeterministic behavior.

Noncompliant Code Example (Boolean Lock Object)

...

The Boolean type is unsuitable for locking purposes because it allows only two values: TRUE and FALSE. Boolean literals containing the same value share unique instances of the Boolean class Boolean in the Java Virtual Machine ( JVM). In this example, initialized references the instance corresponding to the value FALSE. If any other code inadvertently synchronizes on a Boolean literal with the value FALSE, the lock instance is reused and the system can become unresponsiveness or deadlocked.

...

Wiki Markup
According to the Java API class \[[API 06|AA. Java References#API 06]\] class {{java.lang.String}} documentation

...

Consequently, an interned String object behaves like a global variable in the JVM. As demonstrated in this noncompliant code example, even if every instance of an object maintains its own lock field lock, the field references a common String constant. Locking on String constants has the same problem as locking on Boolean constants.

Additionally, hostile code from any other package can exploit this vulnerability, if the class is accessible. (For more information, see guideline LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.)

...

A String instance differs from a String literal. The instance has a unique reference and its own intrinsic lock that is not shared by other string object instances or literals. A better approach is to synchronize on a private final lock object as shown in the following compliant solution.

...

For more information on using an Object as a lock, see guideline LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

...

A significant number of concurrency vulnerabilities arise from locking on the wrong kind of object. It is important to consider the properties of the lock object rather than indiscreetly scavenging for objects to synchronize on.

Rule Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

CON08 LCK01-J

medium

probable

medium

P8

L2

Automated Detection

The following table summarizes the examples flagged as violations by FindBugs:

Noncompliant Code Example

Flagged

Checker

Message

Boolean lock object

Yes

DL_SYNCHRONIZATION_ON_BOOLEAN

Synchronization on Boolean could deadlock

Boxed primitive

Yes

DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE

Synchronization on Integer could deadlock

interned String object

No

n/a

n/a

String literal

Yes

DL_SYNCHRONIZATION_ON_SHARED_CONSTANT

Synchronization on interned String could deadlock

Related Vulnerabilities

...

References

Wiki Markup
\[[API 06|AA. Java References#API 06]\] Class String, Collections
\[[Findbugs 08|AA. Java References#Findbugs 08]\]
\[[PughMiller 0809|AA. Java References#PughReferences#Miller 0809]\] "Synchronization"Locking
\[[MillerPugh 0908|AA. Java References#MillerReferences#Pugh 0908]\] Locking"Synchronization"
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html]

...