Page History

...

private final Boolean initialized = Boolean.FALSE;

synchronized(initialized) { 
  if (!initialized) {
    // Perform initialization
    initialized = Boolean.TRUE;
  }
}

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

...

When explicitly constructed, an Integer object has a unique reference and its own intrinsic lock that is not shared by other Integer objects or boxed integers having the same value. While this is an acceptable solution, it may cause maintenance problems. It is always better to synchronize on a private final raw Object as described next.

Compliant Solution (private final internal raw Object)

This compliant solution uses an internal private final lock object. This is one of the few cases where a raw Object is useful.

...

This does not mean that a subclass using getClass() can only synchronize on the Class object of the base class. In fact, it will lock on its own Class object, which may or may not be want what the programmer had in mind. The intent should be appropriately documented or annotated.

...

Explicitly define the name of the class through name qualification (superclass in this examplecompliant solution) in the synchronization block.

...

Again, the class object being synchronized must not be accessible to hostile code, as discussed in the previous examplecompliant solution. Furthermore, care must be taken so that untrusted inputs are not accepted as arguments while loading classes using Class.forname() (see SEC05-J. Do not expose standard APIs that use the immediate caller's class loader instance to untrusted code for more information).

Noncompliant Code Example (ReentrantLock lock object)

...

It is recommended to not use the intrinsic locks on of objects of classes that implement Lock or Condition objects interfaces. If there is no real need of 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.

Noncompliant Code Example (collection view)

...

private final Map<Integer, String> map = Collections.synchronizedMap(new HashMap<Integer, String>());
private final Set<Integer> set = map.keySet();

synchronized(set) {  // Incorrectly synchronizes on set
  for(Integer k : set) { 
    // Do something 
  }
}

When using synchronization wrappers, the synchronization object must be the {{Collection}} object. The synchronization is necessary to enforce atomicity ([CON07-J. Do not assume that a grouping of calls to independently atomic methods is atomic]). This noncompliant code example demonstrates inappropriate synchronization resulting from locking on a Collection view instead of the Collection object itself \[[Tutorials 08|AA. Java References#Tutorials 08]\]. 

The {{java.util.Collections}} classinterfaces' documentation \[[API 06|AA. Java References#API 06]\] states:

...

// ...
Map<Integer, String> map = Collections.synchronizedMap(new HashMap<Integer, String>());

synchronized(map) {  // Synchronize on map, not set
  for(Integer k : map) { 
    // Do something  
  }
}

...

Risk Assessment

Synchronizing on an incorrect variable inappropriate field can provide a false sense of thread safety and result in nondeterministic non-deterministic behavior.

...