What is VOLATILE in Java?

Java provides weaker form of synchronization called ‘volatile variable’ to ensure any update to variable is propagated to all other threads. Locking guarantees both visibility and atomicity but volatile only guarantees visibility.

The Visibility effect of volatile variables extends beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to volatile variable become visible to B after reading the volatile variable. So writing to a volatile variable works like entering into a synchronized block. However its not recommended to rely on volatile variables too heavily for visibility as it makes code more fragile and hard to understand.

Volatile variables are not thread safe for 64 bit operations as they are Non-atomic. Using volatile for 32 bit operations are fine but when you use it with 64 bit numeric variables, like double and long, JVM is permitted to divide 62 bit read or write operation into two 32 bit read or write operation. If read and writes are happening in two different threads its possible reader might read 32 bit updated value and 32 bit old value and overall unexpected dirty value as volatile doesn't guarantee atomicity. 

For atomic read-modify-write support Java provide 9 different flavors of Atomic Variables/References which can be used to overcome above problem.

Atomic, Volatile, Transient

java.util.concurrent.atomic Description

A small toolkit of classes that support lock-free thread-safe programming on single variables. In essence, the classes in this package extend the notion ofvolatile values, fields, and array elements to those that also provide an atomic conditional update operation of the form:

  boolean compareAndSet(expectedValue, updateValue);

This method (which varies in argument types across different classes) atomically sets a variable to the updateValue if it currently holds theexpectedValue, reporting true on success. The classes in this package also contain methods to get and unconditionally set values, as well as a weaker conditional atomic update operation weakCompareAndSet. The weak version may be more efficient in the normal case, but differs in that any given invocation of weakCompareAndSet method may fail, even spuriously (that is, for no apparent reason). A false return means only that the operation may be retried if desired, relying on the guarantee that repeated invocation when the variable holds expectedValue and no other thread is also attempting to set the variable will eventually succeed. All primitive types are having atomic wrapper classes.

AtomicInteger

AtomicFloat

Atomic Double

VOLATILE:

-----------

Declaring a volatile Java variable means:

• The value of this variable will never be cached thread-locally: all reads and writes will go straight to "main memory";
• Access to the variable acts as though it is enclosed in a synchronizedblock, synchronized on itself.

It can be used as a counter at class level or for implementing lock object etc.

TRANSIENT:

------------

The modifier transient can be applied to field members of a class to turn off serialization on these field members. Every field marked as transient will not be serialized. You use thetransient keyword to indicate to the Java virtual machine that the transient variable is not part of the persistent state of an object.

The transient modifier applies to variables only.

Like other variable modifiers in the Java system, you use transient in a class or instance variable declaration like this:

class TransientExample {
    transient int hobo;
    . . .
}

Q. Can transient variable may be static or final?

Surprisingly, the java compiler does not complaint if you declare a static member field astransient. However, there is no point in declaring a static member field as transient, sincetransient means: "do not serialize", and static fields would not be serialized anyway.

On the other hand, an instance member field declared as final could also be transient, but if so, you would face a problem a little bit difficult to solve: As the field is transient, its state would not be serialized, it implies that, when you deserialize the object you would have to initialize the field manually, however, as it is declared final, the compiler would complaint about it.