introduction
Java's memory model is the main memory and the working memory. When we call the program, the variable values are read from the main memory and then copied to a copy to operate on this copy. Update this copy to the main memory at the end. But this is only for single thread, what if it is multithreaded? And the operation is the same variable value, how should the visibility between these two threads be defined?
happens-Before
Introduction
- After java uses the JMM model, then use happens-before to illustrate the visibility between two threads
- In JMM, if the result of an operation needs to be visible to another operation, then there must be a happens-before relationship between the two operations. The two operations mentioned here can be within one thread or between different threads.
rule
- Program sequence rules: For each operation in a thread, the previous operations happen-before the subsequent operations. This means that we can always get the value of the upper variable in the lower variable in a method.
- Monitor lock rule: For unlocking a lock, happens-before is to lock the lock. For monitor locks, think about sychronized. When we lock an object, after unlocking, the next thread will know that the lock is unlocked, and then add the lock. Another understanding is that the lock and unlock of the monitor are visible between threads.
- Volatile variable rules: For volatile writes, subsequent reads are all happens-before. The two functions of volite prevent the reordering of instructions and the visibility of threads between variables. Among them, the modified variable is visible between threads, which is what we call visible between threads here.
- Sometimes people wonder why volatile can guarantee that shared variables can be seen between threads? One answer is that after the volatile keyword is added to this shared variable, subsequent threads will first update the data in the working memory into the main memory and then get it. Think carefully about whether this is far-fetched. If there are many threads sharing this variable, is it possible to pull these working memory variables into the main memory to update, then which one should the main memory take? No explanation. Then we use this happens-before variable rule to explain. Just say that he follows the happens-before rule. Then this can still be said in the past. Then someone is entangled again, then what happened-before? Is this the fucking norm? ? ?
What exactly is happens-before?
- There is so much nonsense on it, I think I am dizzy.
- To emphasize again:After java uses the JMM model, use happen-before to illustrate the visibility between two threads
- How can it be happens-before? How to follow happens-before, how can it be visible between two threads?
- Visibility between threads, memory sharing and message passing in two ways. Then if we use sychronized locks to lock a certain method and multiple threads call this method, then it can be said that these threads are happens-before.
- There is also a member variable that is modified by the volatile keyword. If there are multiple threads to modify the variable, there is a happens-before relationship between these threads.
- Take a look at the following picture from (Java Concurrent Programming Art). My personal understanding is to follow the rules defined by jMM and ensure inter-thread safety. These multiple threads can use happens-before to describe their relationship.
to sum up
- After the third time java uses the JMM model, then use happens-before to illustrate the visibility between the two threads
- After writing, I feel that this thing is nothing.
reference
"The Art of Java Concurrent Programming"