Simple analysis of Java volatitle multithreading problem _java

We know that setting the value of a variable in Java is an atomic operation except for a variable of type long and double, that is, it is not necessary to synchronize a simple read-write operation for a variable value.

Before JVM 1.2, Java's memory model implementations always read variables from main memory, and there was no need for special attention. As the JVM matures and optimizes, it is now important to use the volatile keyword in a multithreaded environment. Under the current Java memory model, threads can store variables in local memory (such as machine registers) instead of reading and writing directly in main memory. This can cause a thread to modify the value of a variable in main memory, while another thread continues to use its copy of the variable value in the register, resulting in inconsistent data. To solve this problem, just like in this program, declare the variable as volatile (unstable), which instructs the JVM that the variable is unstable and is read in main memory every time it is used. Generally speaking
, the flags that are shared among tasks in a multitasking environment should be volatile modified.

Volatile decorated member variables are forced to reread the value of the member variable from shared memory each time it is accessed by the thread. Also, when a member variable changes, the thread is forced to write the change value back to the shared memory. So at any given moment, two different threads always see the same value for a member variable.

The Java language specification states that in order to achieve optimal speed, the thread is allowed to save private copies of shared member variables, and only when a thread enters or leaves a synchronized code block, it is compared to the original value of the shared member variable.

This way, when multiple threads interact with an object at the same time, it is important to notice that the thread gets the change in the shared member variable in a timely manner.

The volatile keyword is the hint VM: You cannot save its private copy for this member variable, but you should interact directly with the shared member variable.

Recommendation: Use volatile on member variables accessed by two or more threads. You do not have to use when the variable you want to access is already in a synchronized code block, or it is a constant.

Because using volatile masks the necessary code optimizations in the VM, it is less efficient, so use this keyword when necessary.

In the implementation of a virtual machine, the basic type of Int,char is a word length. Long and double account for two word length. In the implementation of some virtual machines in , two words may be manipulated as the two-atom word length.

If you do not modify long and double with volatile, if you access the variable by multithreading, the result is confusing due to the overall atomicity of the long operation.
For example: int, one thread writes to 4, and the other writes 5. Finally it must be 4 or 5. And a long type may be a messy number.