Regarding java volatile, I have a few points to explain,
volatile guarantees visibility. That is, the value obtained by the thread is the latest. Thread1 changes the value of var, then when Thread2 reads it, it will be the changed value, not the previous one. To be more specific, my The understanding is this (please point out if I am wrong), modern computers are multi-core or multi-CPU, and a variable may exist in the registers of different CPUs at the same time. If there is no volatile guarantee, then the same variable will have different values at the same time. Value. Volatile guarantees that the value of the variable is read/written from main memory every time, thus ensuring visibility.
volatile ensures that the compiler will not over-optimize. I have seen the following example, the approximate code is like this:
public class Thread1 extends Thread {
private boolean flag = false;
public void run() {
while(!flag) {
// ...
}
}
public void close() {
flag = true;
}
}
But after the external process called close(), Thread1 did not exit. I used the jdk debug version to get the assembly code of hotspot. I found that while(!flag) was optimized by the compiler into while(true).
For long or double, reading and writing are not atomic operations. With the addition of volatile, reading and writing for long or double are atomic operations.
Used to modify multi-thread shared variables. Use this keyword to ensure that the jvm will not read or write from thread variables, but directly operate shared variables
My understanding is: If there is a variable that is read by multiple threads but only written by one thread, then using volatile on this variable can ensure that the correct value is read. A classic application of volatile is Double-checked locking, which is a method to correctly and efficiently implement the singleton pattern in a multi-threaded environment.
Reference:
Does Java need to lock when reading a variable through multiple threads?
Volatile guarantees the visibility of modified variables but does not guarantee atomic operations. The classic application is Double-checked locking. For example, modify a boolean variable in a multi-threaded environment.
Regarding java volatile, I have a few points to explain,
volatile guarantees visibility. That is, the value obtained by the thread is the latest. Thread1 changes the value of var, then when Thread2 reads it, it will be the changed value, not the previous one. To be more specific, my The understanding is this (please point out if I am wrong), modern computers are multi-core or multi-CPU, and a variable may exist in the registers of different CPUs at the same time. If there is no volatile guarantee, then the same variable will have different values at the same time. Value. Volatile guarantees that the value of the variable is read/written from main memory every time, thus ensuring visibility.
volatile ensures that the compiler will not over-optimize. I have seen the following example, the approximate code is like this:
But after the external process called close(), Thread1 did not exit. I used the jdk debug version to get the assembly code of hotspot. I found that while(!flag) was optimized by the compiler into while(true).
Used to modify multi-thread shared variables. Use this keyword to ensure that the jvm will not read or write from thread variables, but directly operate shared variables
My understanding is: If there is a variable that is read by multiple threads but only written by one thread, then using volatile on this variable can ensure that the correct value is read. A classic application of volatile is Double-checked locking, which is a method to correctly and efficiently implement the singleton pattern in a multi-threaded environment.
Reference:
Volatile guarantees the visibility of modified variables but does not guarantee atomic operations. The classic application is Double-checked locking. For example, modify a boolean variable in a multi-threaded environment.
The poster can read this article by infoq: volatile