Will Volatile Protect Me From All Behind-the-scenes Multi-threading Hazards?

I used to think there are only two multithreading hazards: Race condition: a thread reads x, and before it can write back another thread write x. Unstable state: a thread writes x

Solution 1:

I don't know about the first and the third issue (some link about the first one would be nice if you're sure about it) but I'm sure it fixes your second issue because volatile ensures the flush of the local cache.

See this or this about this topic.

Update

I think I found the perfect link for your question:

http://javarevisited.blogspot.com/2011/06/volatile-keyword-java-example-tutorial.html#ixzz2vjymNleY

1. About reordering

By the way use of volatile keyword also prevents compiler or JVM from reordering of code or moving away them from synchronization barrier.

2. About caching

Volatile keyword in Java is used as an indicator to Java compiler and Thread that do not cache value of this variable and always read it from main memory

3. About atomic read and write

In Java reads and writes are atomic for all variables declared using Java volatile keyword (including long and double variables).