Page History

Reading a shared primitive variable in one thread may not yield the value of the most recent write to the variable from another thread. Consequently, the thread may observe a stale value of the shared variable. To ensure the visibility of the most recent update, either the variable must be declared volatile or the reads and writes must be synchronized.

Declaring a shared variable volatile guarantees visibility in a thread-safe manner only when both of the following conditions are met:

...

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 are accessed atomically. ( For more information on sharing those variables among multiple threads, see rule VNA05-J. Ensure atomicity when reading and writing 64-bit values.)

Noncompliant Code Example (Non-volatile Flag)

...

In this compliant solution, the done flag is declared volatile to ensure that writes are visible to other threads.

...

This compliant solution uses the intrinsic lock of the Class object to ensure that updates become are visible to other threads.

...

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 when a variable's new value depends on its current value. See rule VNA02-J. Ensure that compound operations on shared variables are atomic for more information.

...

...