Page History

Misuse of synchronization primitives is a common source of concurrency issues. A significant number of concurrency vulnerabilities arise from locking on the wrong kind of object. An analysis of the JDK 1.6.0 source code unveiled at leastdiscovered 31 bugs that fell into this category \[[Pugh 08|AA. Java References#Pugh 08]\]. It is important to recognize the entities with whom synchronization is required rather than indiscreetly scavenging for objects to synchronize on. <span style="color: red">we need a more precise statement about what specifically this guideline requires</span>

Noncompliant Code Example (Boolean lock object)

This noncompliant code example uses a Boolean field synchronizes on the (initialized) for synchronizationboolean.

private final Boolean initialized = Boolean.FALSE;

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

There can only be two possible validThe {{initialized}} variable can only assume the values - {{true}} and {{false}} (discounting {{null}}) that {{initialized}} can assume. Consequently, any other code that synchronizes on a {{Boolean}} variable with the same value, may induce unresponsiveness and deadlocks \[[Findbugs 08|AA. Java References#Findbugs 08]\]. 

Noncompliant Code Example (Boxed primitive)

 <span style="color: red">Not sure I completely understand this.  Is the problem that there are only two actual objects that allocated so that if two different threads syncrhronize on thesse objects they'll stomp on each other?</span>

Noncompliant Code Example (Boxed primitive)

This This noncompliant code example locks on a boxed Integer object.

int lock = 0;
private final Integer Lock = lock; // Boxed primitive Lock will beia shared

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

Boxed types are allowed to may use the same instance for a range of integer values and consequently, suffer from the same problem as Boolean constants. If the value of the primitive can be represented as a byte, the wrapper object is reused. Note that the use of the boxed Integer wrapper object is insecure; instances of the Integer object constructed using the new operator (new Integer(value)) are unique and not reused. In general, holding a lock on any data type that contains a boxed value is insecure.

...

When explicitly constructed, an Integer object has a unique reference and its own intrinsic lock that is not shared with other Integer objects or boxed integers having the same value. While this is an acceptable solution, it may cause maintenance problems. why? A more appropriate solution is to synchronize on an internal private final lock Object as described nextin the following compliant solution.

Compliant Solution (internal private final lock Object)

...

The following table summarizes the examples flagged as violations by SureLogic Flashlight:

...