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

This article will explain in detail what the volatile and Java memory model with high concurrency in java is. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Public class Demo09 {public static boolean flag = true; public static class T1 extends Thread {public T1 (String name) {super (name);} @ Override public void run () {System.out.println ("thread" + this.getName () + "in") While (flag) {;} System.out.println ("thread" + this.getName () + "stopped");}} public static void main (String [] args) throws InterruptedException {new T1 ("T1") .start () / / dormant for 1 second Thread.sleep (1000); / / set flag to false flag = false;}}

If you run the above code, you will find that the program cannot be terminated.

There is a loop in the run () method of thread T1, which controls whether the loop ends through flag. The main thread hibernates for 1 second and sets flag to false. Thread T1 detects flag as false and prints "Thread T1 stopped". Why is it different from what we expected? Running the above code, we can tell that the flag seen in T1 has always been true, and after the main thread sets flag to false, it is not seen in the T1 thread, so it has been a dead loop.

So why can't you see the flag modified by the main thread in T1?

To explain this, we need to take a look at the java memory model (JMM), where communication between Java threads is controlled by the Java memory model (JMM for short in this article), and JMM determines when writes by one thread to shared variables are visible to another thread. From an abstract point of view, JMM defines the abstract relationship between threads and main memory: shared variables between threads are stored in main memory (main memory), each thread has a private local memory (local memory), and the thread is stored in local memory to read / write copies of the shared variables. Local memory is an abstract concept of JMM and does not really exist. It covers caching, write buffers, registers and other hardware and compiler optimizations. The abstract diagram of the Java memory model is as follows:

As you can see from the figure above, thread A needs to communicate with thread B and must go through the following two steps:

1. First, thread A flushes the updated shared variables in local memory A to main memory

two。 Thread B then goes to main memory to read the shared variables that have been updated by thread A.

The following is a diagram to illustrate these two steps:

As shown in the figure above, local memory An and B have copies of the shared variable x in main memory. Assume that initially, the x value in all three memory is 0. When thread An executes, it temporarily stores the updated x value (assumed to be 1) in its local memory A. When thread An and thread B need to communicate, thread A first flushes the modified x value in its local memory to the main memory, and the x value in the main memory becomes 1. Then, thread B reads the updated x value of thread An into the main memory, and the x value of thread B's local memory becomes 1. Taken as a whole, these two steps are essentially thread A sending a message to thread B, and the communication process must pass through the main memory. JMM provides memory visibility guarantees for java programmers by controlling the interaction between the main memory and the local memory of each thread.

After learning about JMM, let's take a look at the question at the beginning of the article. There are two possibilities why thread T1 cannot see the value of flag modified by the main thread to false:

1. After the main thread modifies the flag, it is not flushed to the main memory, so T1 cannot see it.

two。 The main thread flushes the flag to the main memory, but T1 always reads the value of flag in its working memory and does not go to the main memory to get the latest value of flag

Is there any way to solve the above two situations?

Whether there is such a way: after the copy in the working memory is modified in the thread, it is immediately flushed to the main memory; every time a shared variable is read in the working memory, it is reread in the main memory and then copied to the working memory.

Java provides us with a way to use volatile to modify shared variables to achieve the above effect. Variables modified by volatile have the following characteristics:

1. When reading in a thread, each read will read the latest value of the shared variable in the main memory, and then copy it to the working memory

two。 The copy of the variable in the working memory is modified in the thread, which will be refreshed to the main memory immediately after modification.

Let's modify the sample code at the beginning:

Public volatile static boolean flag = true

Modify the flag variable with volatile, then run the program to output:

Thread T1 in thread T1 stopped

Now the program can stop normally. Volatile solves the problem of visibility of shared variables in multithreading. Visibility refers to whether changes made by one thread to a shared variable are visible to another thread. \

This is the end of the article on "what is java's highly concurrent volatile and Java memory model". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

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.