Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is volatile". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what is volatile?"

Three features of volatile:

Ensures visibility between threads

Atomicity cannot be guaranteed.

Prevent reordering

Visibility:

First of all, each thread has its own working memory, in addition to a cpu main memory, working memory is a copy of the main memory. When the thread is working, it cannot directly manipulate the value in the main memory, but copies the value of the main memory to its own working memory; when modifying the variable, it will first modify it in the working memory, and then refresh it to the main memory.

Note: when a thread needs to copy values from main memory to working memory

When the lock is released in the thread

When thread switching

When CPU has idle time (such as when a thread sleeps)

Suppose a shared variable flag is false, and after thread an is changed to true, its working memory is modified and flushed to main memory. At this time, when thread b operates on flag, it does not know that a has been modified, which is also said to be invisible to b. So we need a mechanism to notify all threads in time after the value of main memory has been modified to ensure that they can see the change.

Public class ReadWriteDemo {/ / for flag does not add volatile public boolean flag = false; public void change () {flag = true; System.out.println ("flag has changed:" + flag);} public static void main (String [] args) {ReadWriteDemo readWriteDemo = new ReadWriteDemo () / / create a thread to modify flag, such as a thread new Thread (new Runnable () {@ Override public void run () {try {Thread.sleep (3000); readWriteDemo.change ()) described above } catch (InterruptedException e) {e.printStackTrace ();}) .start (); / / main thread, such as b thread while (! readWriteDemo.flag) {} System.out.println ("flag:" + readWriteDemo.flag);}}

According to the analysis, without volatile, the main thread (b thread) cannot see that the child thread (a thread) has modified the value of flag. In other words, in the view of the main thread, in no special case, flag is always false, the judgment condition of while (! readWriteDemo.flag) {} is true, and the system will not execute to System.out.println ("flag:" + readWriteDemo.flag).

To avoid chance, I let the program run for six minutes. As you can see, the child thread does modify the value of flag, and the main thread, as we expected, does not see the change in flag and has been in an endless loop. If you add a volatile to the flag variable, the expected result is that the child thread modifies the variable is visible to the main thread, and the main thread exits the loop.

As you can see, in less than a minute, after the child thread modifies the value of flag, the main thread immediately exits the loop, indicating that the change in the flag variable is immediately perceived.

What's interesting: if the interval between the two threads of ab is not long, when the b thread also delays reading for 10s (not immediately), you will find that the changes between the two threads are also visible, why, there is a solution on stakc overflow, when the cpu executing the thread is free, it will go to main memory to read the following shared variables to update the value in working memory. More interestingly, at the time of writing this article, cpu and memory are like this, but they can be executed normally, but problems can explain the role of volatile.

How to ensure visibility:

First of all, let's talk about the java memory model. Java's memory model defines the protocol for the interaction between working memory and main memory, and defines eight atomic operations:

Lock: locks the variables of the main memory and is exclusive to a thread.

Unlock: the lock added by lock is unlocked so that other threads have a chance to access this variable.

Read: reads the variable values in the main memory into the worker thread.

Load: saves the value read by read to a copy of the variable in working memory.

Use: the code execution engine that passes the value to the thread.

Assign: reassigns the value returned by the execution engine processing to the variable copy.

Store: stores the value of a copy of the variable in main memory.

Write: writes the value stored by store to a shared variable in main memory.

I checked the information on the Internet, and I also read different blogs. It was mentioned that volatile actually added a lock prefix instruction at the bottom. The instructions for the lock prefix are also written on it. What if you write to a variable with volatile. JVM sends a lock prefix instruction to the processor, and thread a locks the variable in main memory, modifies it, and then flushes it to main memory. The b thread will also lock the variables in main memory, but will find that the variables in main memory are different from the values of working memory, and will read the latest values from main memory. This ensures that each thread can make changes to variables visible.

Atomicity:

In the programming world, atomicity refers to an operation that cannot be divided, and an operation is either performed or not performed at all, and is the smallest unit of execution.

Public class TestAutomic {volatile int num = 0; void add () {num++;} public static void main (String [] args) throws InterruptedException {TestAutomic testAutomic = new TestAutomic (); for (int I = 0; I < 1000) New Thread (new Runnable () {@ Override public void run () {try {Thread.sleep (10); testAutomic.add ();} catch (InterruptedException e) {e.printStackTrace ()) }) .start ();} / / wait 12 seconds for all child threads to execute Thread.sleep (12000); System.out.println (testAutomic.num);}}

* * expected phenomenon: * * it is said that atomicity can no longer be guaranteed, so the result should be not equal to 1000

The results of different computers are different, mine is 886, maybe yours is not, but all show that volatile can not guarantee the atomicity of the operation.

Why can't atomicity be guaranteed:

This starts with the num++ operation, which can be divided into three steps:

Read the value of I and load it into working memory

I plus 1 operation

Write the value of I back to working memory and refresh it to main memory

We know that the execution of threads is random, assuming that thread an and thread b all have num=0 in the working memory, thread a grabs the execution power of cpu first, adds 1 operation in working memory, and has not been refreshed to main memory; b thread gets the execution power of cpu at this time, also adds 1; then thread a refreshes to main memory num=1, and thread b refreshes to main memory, which is also num=1, but num should be equal to 2 after two operations.

Solution:

Use the synchronized keyword

Use atomic classes

Reorder:

For the program we write, cpu will reorder instruction lines according to how to make the program more efficient. What does that mean?

A = 2 b = new B (); c = 3tern d = new D ()

After optimization, the real order of instructions may be:

A = 2TAC = 3TX b = new B (); d = new D ()

Not all instructions are reordered. Whether they are reordered or not depends on whether they can make the instructions more efficient. There is another case.

A = 2b = a

These two lines of code will not be reordered under any circumstances, because the second instruction relies on the first instruction, and the reordering is based on the fact that the final result remains the same after sorting. Here is an example of how volatile prevents reordering:

Public class TestReorder {private static int a = 0, b = 0, x = 0, y = 0; public static void main (String [] args) throws InterruptedException {while (true) {a = 0; b = 0; x = 0; y = 0 / / a thread new Thread (new Runnable () {@ Override public void run () {try {Thread.sleep (10); a = 1; x = b) } catch (InterruptedException e) {e.printStackTrace ();}) .start () / / b thread new Thread (new Runnable () {@ Override public void run () {try {Thread.sleep (10); b = 1; y = a } catch (InterruptedException e) {e.printStackTrace ();}) .start (); / / the main thread sleeps 100ms to ensure that all child threads have finished executing Thread.sleep; System.out.println ("a =" + a + ") B = "+ b +"; x = "+ x +"; y = "+ y);}

Remember that it was said above that if the sleeping time of two threads is about the same, it is visible between them.

Expected results:

If you finish executing thread a (a = 1, x = b = 0) and then thread b (b = 1, y = a = 1), the final result is a = 1; b = 1; x = 0; y = 1

If you finish executing thread b (b = 1, y = a = 0) and then thread a (a = 1, x = b = 1), the final result is a = 1; b = 1; x = 1; y = 0

If the a thread procedure is executed (a = 1), followed by the b thread (b = 1) [why y = a must be equal to 1, because the change between them is visible], finally the a thread (x = b = 1) is executed, and the final result a = 1; b = 1; x = 1; y = 1

It can be found that in addition to the three situations expected above, there is also a case of a = 1; b = 1; x = 0; y = 0, which I believe you all know is caused by reordering. Either a thread reorder performs x = b first; then a = 1 position; or b thread reorder performs y = a first; then b = 1 position; or both threads are reordered.

What if private volatile static int a = 0, b = 0, x = 0, y = 0; what happens with the volatile keyword?

In order to ensure correctness, after running for another 5 minutes, it can be found that there will really be no such situation again.

How to prevent reordering

Let's first talk about the role of four memory barriers.

Memory barrier functions StoreStore barrier prevents upper normal write and lower volatile write reorder StoreLoad barrier prohibits upper volatile write and lower volatile read / write reorder LoadLoad barrier prohibits normal read below and volatile read reorder above LoadStore barrier prohibits normal write below and volatile read reorder above

It may be more abstract to see the function, give a direct example.

For S1; StoreStore; S2, ensure that the write operation of S1 is visible to other threads before S2 and subsequent write operations.

For S; StoreLoad; L, ensure that S writes are visible to other threads before L and subsequent read / write operations.

For L1; LoadLoad; L2, ensure that L1 finishes reading data before L2 and subsequent read operations.

For L; LoadStore; S, ensure that L has finished reading data before S and subsequent operations.

So how does volatile ensure order?

Insert a StoreStore barrier before each volatile write operation, and add an StoreLoad barrier after each write operation.

Insert the LoadLoad barrier before each volatile read operation and the LoadStore barrier after the read operation.

For example, what if there is a write S for the volatile variable and a read L for the volatile variable.

For writing: S1; StoreStore; S; StoreLoad L this prevents reordering of S (protecting the volatile variable in the middle).

For reading the same truth: L1; LoadLoad; L; LoadStore S, also protect the volatile variable well.

At this point, I believe you have a deeper understanding of "what is volatile", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.