In-depth analysis of Java memory model: volatile-javaTutorial-php.cn

Characteristics of volatile

When we declare a shared variable as volatile, the reading/writing of this variable will be very special. A good way to understand the nature of volatile is to think of individual reads/writes to volatile variables as synchronizing these individual read/write operations using the same monitor lock. Below we use specific examples to illustrate. Please see the following sample code:

class VolatileFeaturesExample { volatile long vl = 0L; //使用volatile声明64位的long型变量 public void set(long l) { vl = l; //单个volatile变量的写 } public void getAndIncrement () { vl++; //复合（多个）volatile变量的读/写 } public long get() { return vl; //单个volatile变量的读 } }

Copy after login

Assume that multiple threads call the three methods of the above program respectively. This program is semantically equivalent to the following program:

class VolatileFeaturesExample { long vl = 0L; // 64位的long型普通变量 public synchronized void set(long l) { //对单个的普通 变量的写用同一个监视器同步 vl = l; } public void getAndIncrement () { //普通方法调用 long temp = get(); //调用已同步的读方法 temp += 1L; //普通写操作 set(temp); //调用已同步的写方法 } public synchronized long get() { //对单个的普通变量的读用同一个监视器同步 return vl; } }

Copy after login

As shown in the sample program above, a single read/write operation on a volatile variable is synchronized with a read/write operation on an ordinary variable using the same monitor lock. The execution effect is the same.

The happens-before rule of the monitor lock guarantees memory visibility between the two threads that release the monitor and acquire the monitor. This means that a read of a volatile variable can always be seen (any Thread) final write to this volatile variable.

The semantics of monitor locks determine that the execution of critical section code is atomic. This means that even for 64-bit long and double variables, as long as it is a volatile variable, reading and writing to the variable will be atomic. If there are multiple volatile operations or compound operations like volatile++, these operations are not atomic as a whole.

In short, volatile variables themselves have the following characteristics:
Visibility. A read from a volatile variable will always see the last write (by any thread) to the volatile variable.
Atomicity: Reading/writing any single volatile variable is atomic, but compound operations like volatile++ are not atomic.

happens before relationship established by volatile write-read

The above is about the characteristics of volatile variables themselves. For programmers, volatile has a greater impact on the memory visibility of threads than volatile itself. Features are more important and require more attention from us.

Starting from JSR-133, write-reading of volatile variables can achieve communication between threads.

From the perspective of memory semantics, volatile and monitor locks have the same effect: volatile writing and monitor release have the same memory semantics; volatile reading and monitor acquisition have the same memory semantics.

Please see the following example code using volatile variables:

class VolatileExample { int a = 0; volatile boolean flag = false; public void writer() { a = 1; //1 flag = true; //2 } public void reader() { if (flag) { //3 int i = a; //4 …… } } }

Copy after login

Assume that after thread A executes the writer() method, thread B executes the reader() method. According to the happens before rule, the happens before relationship established in this process can be divided into two categories:
According to the program order rule, 1 happens before 2; 3 happens before 4.
According to volatile rules, 2 happens before 3.
According to the transitivity rule of happens before, 1 happens before 4.

The graphical representation of the above happens before relationship is as follows: