Versions Compared

Key

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

Static shared data should not be protected using instance locks because these 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. If the class can interact with untrusted code, the lock must also be private and final, as per guideline LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

...

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

Code Block
bgColor#FFcccc
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 example 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 (see guideline VNA02-J. Ensure that compound operations on shared variables are atomic).

...

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

Code Block
bgColor#FFcccc
public final class CountBoxes implements Runnable {
  private static volatile int counter;
  // ...

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

...

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

...

There is no need to declare the counter variable volatile when using synchronization is used.

Risk Assessment

Using an instance lock to protect static shared data can result in non-deterministic nondeterministic behavior.

Rule Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

CON13 LCK06-J

medium

probable

medium

P8

L2

Automated Detection

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

Noncompliant Code Example

Flagged

Message

non-static lock object for static data

No

No obvious issues

method synchronization for static data

No

No obvious issues

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

Noncompliant Code Example

Flagged

Message

non-static lock object for static data

Yes

modeling problem: static region "counter" should be protected by a static field

method synchronization for static data

Yes

modeling problem: static region "counter" should be protected by a static field

Related Vulnerabilities

...

References

Wiki Markup
\[[API 062006|AA. Java References#API 06]\]

Issue Tracking

...

...

LCK05-J. Synchronize access to static fields that may be modified by untrusted code      12. Locking (LCK)