CON34-J. Do not use an instance lock to protect shared static data

Static shared data should not be protected using instance locks because the instance locks are ineffective when two or more instances of the class are created. Consequently, the shared state is not safe for concurrent access unless a static lock object is used. Ideally, the lock should also be private and final, as per CON04-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

Noncompliant Code Example (non-static lock object for static data)

This noncompliant code example uses a non-static lock object to guard access to a static field counter. If two Runnable tasks are started, they will create two instances of the lock object and lock on each separately.

public final class CountBoxes implements Runnable {
  private static volatile int counter;
  // ...
  private final Object lock = new Object();    

  public void run() {
    synchronized(lock) {
      counter++; 
      // ... 
    } 
  }

  public static void main(String[] args) {
    for(int i = 0; i < 2; i++) {
      new Thread(new CountBoxes()).start();
    }
  }
}

This does not prevent either thread from observing an inconsistent value of counter because the increment operation on volatile fields is not atomic in the absence of proper synchronization.

Noncompliant Code Example (method synchronization for static data)

This noncompliant code example uses method synchronization to protect access to a static class field counter.

public final class CountBoxes implements Runnable {
  private static volatile int counter;
  // ...

  public synchronized void run() {
    counter++; 
    // ... 
  }
  // ...
}

In this case, the intrinsic lock is associated with each instance of the class and not with the class itself. Consequently, threads constructed using different Runnable instances may observe inconsistent values of the counter.

Compliant Solution (static lock object)

This compliant solution declares the lock object as static and consequently, ensures the atomicity of the increment operation.

public class CountBoxes implements Runnable {
  private static int counter;
  // ...
  private static final Object lock = new Object();    
  
  public void run() {
    synchronized(lock) {
      counter++; 
      // ...
  }
  // ...
}

There is no requirement for declaring the counter variable as volatile when synchronization is used.

Risk Assessment

Using an instance lock to protect static shared data does not provide any synchronization properties and can lead to non-deterministic behavior.

Automated Detection

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

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

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]]

Issue Tracking

VOID CON00-J. Synchronize access to shared mutable variables      11. Concurrency (CON)      CON03-J. Do not use background threads during class initialization