Deep Java Memory Model (ii) volatile explanation

For the volatile modifier, we should not be unfamiliar with the use of common in multi-threading, such as multiple threads want to use a global variable as an identifier, or a shared variable, we will add a volatile modifier to the variable. Volatile is variable and unstable in Chinese. Indicates that the variable will be accessed by multiple threads and may be modified. So how does the JVM play the role of the volatile keyword and how does it work?

The previous in-depth Java memory model explains the reordering in the JVM, as well as four kinds of memory barriers. The JVM always implements functionality in a way that is understandable and easy to use. The garbage collector, for example, has a headache when it comes to memory applications and releases. The JVM is automatically managed by the garbage collector, which is secure and convenient. The same is true for volatile. The JVM's function with volatile is defined as the atomicity of the read and write of the variable, which is immediately visible to other threads for modification of the variable. We know that writing a variable is, in fact, at least two steps, the first step, changing the value of the local variable, which is in the write buffer. The second step is to update the write buffer to shared memory so that other threads can see the change. To ensure the atomicity of the operation, these two steps must be performed at once. For this, the JVM implements the following:

For example, define a volatile Boolean variable flag

When thread a writes local memory, the cache is flushed directly into main memory so that the variable is visible to other threads.

When thread B reads flag, the flag setting in local memory is invalidated, and the flag is read directly from main memory so that the flag read is up-to-date.

The above is a way for the JVM to perform a display of volatile. But the instructions are executed in one piece. How is the JVM implemented in terms of command control?

is a table in which the JVM is allowed to flush orders for volatile read-write and normal read-write instructions.

From the table we can see:

1, if the second operation is Votatile write, then no previous instruction can be reordered with it, that is, the preceding is not queued to volatile after writing.

2, if the first operation is a volatile read, then no subsequent instruction can be reordered with it, that is, the following will not be queued to the volatile read.

Typically, the JVM's reflow control over instructions is to insert a memory barrier in the middle.

The definitions in JMM are as follows:

Insert a storestore barrier before volatile writes.

Insert a storeload barrier after the volatile write.

Insert a loadload barrier after the volatile read.

Insert a loadstore barrier after the volatile read.

This achieves the semantic effect of volatile. We can use two graphs to visualize the process:

By understanding the specific features of volatile and the underlying implementation, the use of it can be used more handy, it embodies the Java memory model and Java thread relationship. Has a great effect on our effective and correct development. If the above content is not easy to understand, use a frequently used lock can describe his function, namely: each time the volatile variable write and read, to obtain the lock of the variable to execute. When writing, the variable is locked, and when the write value is flushed to memory, the lock is freed. When read, locks the variable and releases the lock when the value is read from the shared memory. I hope we can give you a little help.

　　

Deep Java Memory Model (ii) volatile explanation