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

This article mainly introduces "the principle and usage of happens-before in JMM". In daily operation, I believe that many people have doubts about the principle and use of happens-before in JMM. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "the principle and usage of happens-before in JMM". Next, please follow the editor to study!

There is a very important concept in JMM that is very helpful for us to understand JMM, and that is happens-before rules. Happens-before rule is very important, it is the main basis to judge whether there is competition in the data and whether the thread is safe. JSR-133S uses the happens-before concept to illustrate memory visibility between two operations. In JMM, if the result of one operation needs to be visible to another, then there is a happens-before relationship between the two operations.

So what is happens-before? In JSR-133, the happens-before relationship is defined as follows:

If one operation happens-before another operation, it means that the result of the first operation is visible to the second operation, and the order in which the first operation is executed will precede the second operation.

The existence of a happens-before relationship between the two operations does not mean that the specific implementation of the Java platform must be executed in the order specified by the happens-before relationship. If the results after reordering are consistent with the results performed according to the happens-before relationship, then this reordering is not illegal (that is, JMM allows such reordering)

The happens-before rules are as follows:

Program order rules: each operation in a thread, happens-before any subsequent operations in that thread.

Monitor rule: unlock a lock, and happens-before then locks the lock.

Volatile rule: write to a volatile variable, happens-before to any subsequent read to a volatile variable.

Transitivity: if A happens-before B happens-before C, then A happens-before C.

Thread startup rule: the start () method of the Thread object, happens-before any subsequent operations of this thread.

Thread termination rule: any operation in a thread, happens-before monitors the termination of the thread. We can detect that the thread has terminated execution by means of the end of the Thread.join () method, the return value of Thread.isAlive (), and so on.

Thread interrupt operation: the call to the thread interrupt () method, happens-before detects the occurrence of the interrupt event in the code of the interrupted thread, and can detect whether the thread is interrupted by the Thread.interrupted () method.

Object termination rule: the initialization of an object is complete, and happens-before is at the beginning of the object's finalize () method.

The above eight happens-before rules are relatively simple. Here, LZ only analyzes the third volatile variable rule. The analysis is as follows:

From the figure above, we can see that there are four happens-before relationships, which are as follows:

1 happens-before 2 and 3 happens-before 4 are generated by program sequencing rules.

2 happens-before 3 is generated by volatile rules. As mentioned above, when you read a volatile variable, you can always see the previous writes to the volatile variable.

1 happens-before 4 is generated by transitive rules.

At this point, many children's shoes may understand happens-before as "chronological order". Here, LZ emphasizes that happens-hefore cannot be understood as "chronological order". Here LZ uses a piece of code to explain the difference between writing happens-before and "chronological order". The code is as follows:

Public class VolatileTest4 {private int a = 0; public int getA () {return a;} public void setA (int a) {this.a = a;}}

The above code is a set of simple setter/getter methods. Now suppose there are two threads An and B, thread A first executes setA (10), and then thread B accesses the getA () method of the same object, so how much does thread B receive at this time?

The answer is: not sure.

Let's take a look at the principles of happens-before:

Here, the two methods are called in two threads, not in one thread, so the sequence of the program does not apply.

There is no synchronization speed in the code, and all monitor rules do not apply.

The variable an in the code is an ordinary variable, so the volatile rule does not apply.

The subsequent thread startup, interrupt, termination and object termination have nothing to do with this, so these rules do not apply.

None of the happens-before applies, so the transitivity rule does not apply.

Here, although thread An executes before thread B in time, because the code does not apply the happens-before rules at all, we cannot determine how many values are received by B first. In other words, the above code is not thread-safe.

For the above code, how do we fix the problem of thread unsafety? Here, we just need to satisfy any of the rules 2 and 3 of the happens-before rules. That is, either define the setter/getter method as the synchronized method, or add a volatile modifier to the variable a.

From the above example, we can conclude that an operation "occurs first in time" does not mean that it will happens-before other operations. Which operation happens-before other operations, does it mean that the operation "happened first in time"? The answer is also no, let's take a look at the following example:

Int I = 1nint m = 2

The above two assignment operations are in the same thread, according to the program sequence rule, "int I = 1;" this operation happens-before "int m = 2;" this operation, but "int m = 2;" this operation may be performed by the processor first, which does not affect the correctness of the happens-before principle. Because this reordering is allowed in JMM.

Finally, we come to the conclusion that there is little relationship between the time sequence and the happens-before principle, so we should not be disturbed by the time sequence when we measure the concurrency security issues, everything must be based on the happens-before principle.

At this point, the study of "the principle and use of happens-before in JMM" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.