In Java and other JVM languages, "volatile" reads and writes are part of the concurrency toolbox.But adding volatile on variables can be a mistake.This is a poorly understood concept.Let's gain a better understanding.Misconceptions #
Some common ones:
Volatile variables ensure "visibility" - but the notion is misleading, because it's not about visibility per se, as all updates to variables are eventually seen by all other threads, and marking a variable as volatile doesn't necessarily publish changes to that variable any sooner (although in fairness, x86 CPUs have stronger ordering guarantees than ARM CPUs in this regard, so there may be differences of behavior for normal variables, depending on what you're doing);
Volatile variables are not for "synchronization" - which is false, as volatile reads and writes are a form of synchronization, even if the guarantees are weaker than when using locks or when using compare-and-set (CAS).
Some common ones:
Volatile variables ensure "visibility" - but the notion is misleading, because it's not about visibility per se, as all updates to variables are eventually seen by all other threads, and marking a variable as volatile doesn't necessarily publish changes to that variable any sooner (although in fairness, x86 CPUs have stronger ordering guarantees than ARM CPUs in this regard, so there may be differences of behavior for normal variables, depending on what you're doing);
Volatile variables are not for "synchronization" - which is false, as volatile reads and writes are a form of synchronization, even if the guarantees are weaker than when using locks or when using compare-and-set (CAS).
[
add
]
[
|
|
...
]