Before we start to explain the Java multi-threaded cache model, let’s first look at the following code. The logic of this code is very simple: the main thread starts two sub-threads, one thread 1 and one thread 2. Thread 1 executes first, and thread 2 executes after sleeping for 2 seconds. The two threads use a shared variable shareFlag, with an initial value of false.If shareFlag is always equal to false, thread 1 will always be in an infinite loop, so we set shareFlag to true in thread 2.
public class VolatileTest { public static boolean shareFlag = false; public static void main(String[] args) throws InterruptedException { new Thread(() -> { System.out.print("开始执行线程1 =>"); while (!shareFlag){ //shareFlag = false则一直死循环 //System.out.println("shareFlag=" + shareFlag); } System.out.print("线程1执行完成 =>"); }).start(); Thread.sleep(2000); new Thread(() -> { System.out.print("开始执行线程2 =>"); shareFlag = true; System.out.print("线程2执行完成 =>"); }).start(); } }
If you have not learned the JMM thread model, maybe after reading the above code, you hope that the output result is as follows:
Start executing thread 1 => Start executing thread 2 => Thread 2 execution is completed => Thread 1 execution is completed =>
As shown in the figure below, normal people understand this code. First execute thread 1 and enter the loop. 2 Modify shareFlag=true, and thread 1 jumps out of the loop. Therefore, thread 1 that breaks out of the loop will print "Thread 1 execution completed =>", but after the author's experiment, **"Thread 1 execution completed =>" will not be printed, and thread 1 does not break out of the infinite loop**. This Why?
To explain the problems mentioned above, we need to learn the JMM (Java Memory Model) Java memory model. I think it is more accurate to call it Java multi-threaded memory model.
First of all, in JMM, each thread has its own working memory. When the program starts, the thread loads the shared variables (read&load) into In its own working memory,the memory variables loaded into the thread's working memory are copies of the shared variablesin the main memory. That is to say, there are three copies of shareFlag in memory at this time, and their values are all equal to false.
When thread 2 executesshareFlag=true, its working memory copy is modified toshareFlag=true, and the value of the copy is synchronized at the same time Write back (store&write) to main memory.
ButshareFlag=falsein the working memory of thread 1 has not changed, so thread 1 has been in an infinite loop. middle.
The modification of shared variables by thread 2 will not be perceived by thread 1, which is consistent with the above experimental results and JMM model. So how can thread 1 perceive that the value of the shared variable has changed? In fact, it is very simple. Just add the volatile keyword to the shareFlag shared variable.
public volatile static boolean shareFlag = false;
The underlying principle is like this. Adding the volatile keyword prompts JMM to follow the MESI cache consistency protocol. The protocol contains the following cache usage specifications (If you don’t understand it, you can ignore it. It will be used below. Describe it in simple language and examples).
Modified: Represents that the data of the current cache line is modified (Dirty), and is only modified in the cache of the current CPU; at this time, the The data in a cache row is different from the data in other caches and different from the data in the row in memory.
Exclusive: Indicates that the data of the current Cache line is valid data, and there is no such line of data in the cache of other CPUs; and the data of the current Cache line is different from the data in the memory. same.
Shared: This line of data will be cached in the Cache representing multiple CPUs, and the data in the Cache is consistent with the data in the memory;
Invalid: Indicates that the data in the current Cache line is invalid;
The cache above The usage specification may be too complicated. To put it simply,
When thread 2 modifies shareFlag (refer to Modify), inform the bus that I have modified the shared variable shareFlag,
Thread 1 monitors the Bus. When it learns that the shared variable shareFlag has been modified, it will delete the copy of shareFlag in its working memory to render it invalid.
When thread 1 needs to use shareFlag again and finds that there is no copy of the shareFlag variable in the working memory, it will reload (read&load) from the main memory
The above is the detailed content of Example analysis of volatile and JMM multi-threaded memory model of Java concurrent programming. For more information, please follow other related articles on the PHP Chinese website!