Static shared data must 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 use.
Noncompliant Code Example (nonstatic lock object for static
data)
This noncompliant code example uses a nonstatic lock object to guard access to a static
field. If two Runnable
tasks, each consisting of a thread are started, they will create two instances of the lock object and lock on each separately.
class CountBoxes implements Runnable { static volatile int counter; // ... Object lock = new Object(); public void run() { synchronized(lock) { counter++; // ... } } public static void main(String[] args) { Runnable r1 = new CountBoxes(); Thread t1 = new Thread(r1); Runnable r2 = new CountBoxes(); Thread t2 = new Thread(r2); t1.start(); t2.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 member.
class CountBoxes implements Runnable { static volatile int counter; // ... public synchronized void run() { counter++; // ... } // ... }
The problem is that this lock is associated with each instance of the class and not with the class object 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.
class CountBoxes implements Runnable { static int counter; // ... private static final Object lock = new Object(); public void run() { synchronized(lock) { counter++; // ... } // ... }
There is no requirement of declaring the counter
variable as volatile
when synchronization is used.
Risk Assessment
Using an instance lock to protect static shared data provides no synchronization properties and can lead to non-deterministic behavior.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
CON34- J |
medium |
probable |
medium |
P8 |
L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[API 06]]
VOID CON00-J. Synchronize access to shared mutable variables 11. Concurrency (CON) CON03-J. Do not use background threads during class initialization