...
- A write to a variable is independent from its current value.
- A write to a variable is independent from the result of any non-atomic compound operations involving reads and writes of other variables. (For more information, see guideline rule VNA02-J. Ensure that compound operations on shared variables are atomic.)
| Wiki Markup |
|---|
The first condition can be relaxed when you can be sure that only one thread will ever update the value of the variable \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. However, code that relies on a single-thread confinement is error-prone and difficult to maintain. This design approach is permitted under this guidelinerule, but is discouraged. |
Synchronizing the code makes it easier to reason about its behavior and is frequently more secure than simply using the volatile keyword. However, synchronization has somewhat higher performance overhead and can result in thread contention and deadlocks when used excessively.
Declaring a variable volatile or correctly synchronizing the code both guarantee that 64-bit primitive long and double variables will be accessed atomically. (For more information on sharing those variables among multiple threads, see guideline rule VNA05-J. Ensure atomicity when reading and writing 64-bit values.)
...
Synchronization is a more secure alternative in situations where the volatile keyword or a java.util.concurrent.atomic.Atomic* field is inappropriate, such as if a variable's new value depends on its current value. For more information, see guideline rule VNA02-J. Ensure that compound operations on shared variables are atomic.
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.
...
Any vulnerabilities resulting from the violation of this guideline rule are listed on the CERT website.
...