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 in guideline LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.
...
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 See guideline VNA02-J. Ensure that compound operations on shared variables are atomic.).
Noncompliant Code Example (Method Synchronization for Static Data)
...
This compliant solution declares the lock object as static and, consequently, ensures the atomicity of the increment operation.
...
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
| Wiki Markup |
|---|
\[[API 2006|AA. Bibliography#API 06]\] |
...