Atomicity applies to "simple operations" on primitive types except for longs and doubles.
Reading and writing primitive variables other than long and double is guaranteed to go to
and from memory as indivisible (atomic) operations. However, the JVM is allowed to
perform reads and writes of 64- bit quantities (long and double variables) as two separate
32-bit operations, raising the possibility that a context switch could happen in the middle of a
read or write, and then different tasks could see incorrect results (this is sometimes called
word tearing, because you might see the value after only part of it has been changed).
However, you do get atomicity (for simple assignments and returns) if you use the volatile
keyword when defining a long or double variable (note that volatile was not working
properly before Java SE5). Different JVMs are free to provide stronger guarantees, but you
should not rely on platform-specific features.
Atomic operations are thus not interruptible by the threading mechanism. Expert
programmers can take advantage of this to write lock-free code, which does not need to be
synchronized. But even this is an oversimplification. Sometimes, even when it seems like an
atomic operation should be safe, it may not be. Readers of this book will typically not be able
to pass the aforementioned Goetz Test, and will thus not be qualified to try to replace
synchronization with atomic operations. Trying to remove synchronization is usually a sign
of premature optimization, and will cause you a lot of trouble, probably without gaining
much, or anything.
On multiprocessor systems (which are now appearing in the form of multicore processors—
multiple CPUs on a single chip), visibility rather than atomicity is much more of an issue
than on single-processor systems. Changes made by one task, even if they’re atomic in the
sense of not being interruptible, might not be visible to other tasks (the changes might be
temporarily stored in a local processor cache, for example), so different tasks will have a
different view of the application’s state. The synchronization mechanism, on the other hand,
forces changes by one task on a multiprocessor system to be visible across the application.
Without synchronization, it’s indeterminate when changes become visible.
The volatile keyword also ensures visibility across the application. If you declare a field to be
volatile, this means that as soon as a write occurs for that field, all reads will see the change.
This is true even if local caches are involved—volatile fields are immediately written through
to main memory, and reads occur from main memory.
It’s important to understand that atomicity and volatility are distinct concepts. An atomic
operation on a non-volatile field will not necessarily be flushed to main memory, and so
another task that reads that field will not necessarily see the new value. If multiple tasks are
accessing a field, that field should be volatile; otherwise, the field should only be accessed
via synchronization. Synchronization also causes flushing to main memory, so if a field is
completely guarded by synchronized methods or blocks, it is not necessary to make it
volatile.
Any writes that a task makes will be visible to that task, so you don’t need to make a field
volatile if it is only seen within a task.
volatile doesn’t work when the value of a field depends on its previous value (such as
incrementing a counter), nor does it work on fields whose values are constrained by the
values of other fields, such as the lower and upper bound of a Range class which must
obey the constraint lower <= upper.
It’s typically only safe to use volatile instead of synchronized if the class has only one
mutable field. Again, your first choice should be to use the synchronized keyword—that’s
the safest approach, and trying to do anything else is risky.
What qualifies as an atomic operation? Assignment and returning the value in a field will
usually be atomic.