...
For information about the atomicity of a grouping of calls to independently atomic methods that belong to thread-safe classes, see guideline rule VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic.
The Java Language Specification also permits reads and writes of 64-bit values to be non-atomic. For more information, see guideline rule VNA05-J. Ensure atomicity when reading and writing 64-bit values.
...
The second execution order involves the same operations, but t2 starts and finishes before t1.
Compliance with guideline rule LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code can reduce the likelihood of misuse by ensuring that untrusted callers cannot access the lock object.
...
| Wiki Markup |
|---|
This approach is forbidden for getter methods that perform any additional operations other than returning the value of a volatile field without use of synchronization. Unless read performance is critical, this technique may lack significant advantages over synchronization \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
Guideline Rule VNA06-J. Do not assume that declaring a reference volatile guarantees visibility of the members of the referenced object also addresses the volatile-read, synchronized-write pattern.
...
In this noncompliant code example, multiple threads can invoke the setValues() method to set the a and b fields. Because this class fails to test for integer overflow, users of the Adder class must ensure that the arguments to the setValues() method can be added without overflow. (For more information, see guideline rule NUM00-J. Detect or prevent integer overflow.)
...
The SureLogic Flashlight tool can diagnose violations of this guideline rule as instance fields with empty locksets.
...
Any vulnerabilities resulting from the violation of this guideline rule are listed on the CERT website.
...