Tell me about my understanding of the volatile keyword in Java

First cite two articles from other authors: 1.http://www.infoq.com/cn/articles/ftf-java-volatile 2.http://blog.csdn.net/hupitao/article/ details/45227891

"The volatile keyword ensures that each thread can read the latest variable value", and to understand this sentence first clear the relationship between CPU, register, and memory. Quote a paragraph in the passage:

There is a second line of assembly code when a shared variable modified with a volatile variable is written, and by looking at the IA-32 architecture software Developer's Manual, the lock prefix instruction will cause two things under the multi-core processor.

• Writes the data for the current processor cache row back to system memory.
• This write-back operation causes invalid data to be cached on the other CPU in the memory address.

In order to improve processing speed, not directly communicate with the memory, but first read the system memory data into the internal cache before the operation, but do not know when to write to memory, if the declaration of volatile variables to write, the JVM will send a lock prefix to the processor instructions, Writes the data from the cached row of this variable back to the system memory. But even if you write back to memory, if the other processor cache value is old, and then perform the calculation operation will be problematic, so under multiprocessor, in order to ensure that the cache of the processor is consistent, the cache consistency protocol is implemented, each processor by sniffing the data propagated on the bus to check whether the value of its cache is out of date , when the processor finds that the memory address corresponding to its cache line is modified, the cache line of the current processor is set to an invalid state, and when the processor modifies the data, it forces the data to be read from the system memory into the processor cache.

Let's talk about the n++ operation:

The volatile n is a thread-safe problem at this point, first 1.cpu reads the value of n from memory to the cache, then 2.cpu reads the value in the cache, 3. Add 1 to the value of N, and 4. Write to the cache, followed by 5. Write to memory.

Thread A executes the 1,2,3---out of the CPU time slice--thread B also executes 1,2,3---thread A writes to the cache--thread B writes to the cache--thread a writes into memory (note that at this point, forcing the data to be read from the system memory into the processor cache), the value of n is added two times,  However, the value added to the cache is 1. A thread safety issue has occurred. Therefore, volatile does not guarantee atomicity.

Operation: N=1+1, before the value of n in the cache may be old, the volatile n is forced to write to memory and the register is forced to flush.

Quote the article again:

1. Once you have finished writing, any thread accessing this field will get the most recent value. 2, before you write, will ensure that all previous events have occurred, and any updated data values are also visible, because the memory barrier will be the previous write values are flushed to the cache.

Why is volatile not atomic?

Understand the memory barrier this CPU instruction, back to the previous JVM directive: from load to store to memory barrier, a total of 4 steps, the last step of the JVM let the value of this latest variable is visible on all threads, The final step is to have all CPU cores get the latest values, but the middle steps (from load to store) are unsafe, and if the other CPUs modify the value, they will be lost.

Summary: The volatile keyword only guarantees that a get operation reads the most recent value, while a set operation is written to memory, forcing the data to be read from the system memory into the processor cache without atomicity.

Tell me about my understanding of the volatile keyword in Java