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

This article shares with you the content of a sample analysis of JMM instruction reordering. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

First, why should instructions be reordered?

In the computer system, in order to complete the results faster, the instructions will be reordered according to the logical relationship and instruction size, in order to achieve the effect of super pipeline, but after the code execution, the output of the results is guaranteed to be consistent.

There are two more principles in JVM:

The rule of as-if-serials applies to single thread and is handled automatically by default.

The rule of happens-before applies to multithreading, of course, through corresponding locks and keywords.

Second, how is the reordering of JMM (Java Memory Manager) instructions implemented?

We know that JIT compiles the appropriate code to execute according to the CPU architecture, so there may not be a consensus at the assembly level, such as X86, which is implemented only by lock, while other CPU architectures are LoadLoad,StoreStore,LoadStore,StoreLoad.

In fact, it's easier to understand at the JIT level, where we define a class.

(note: this class may not be consistent with the actual effect of JIT, depending on how aggressive JIT is.)

Package com.apptest;public class VolatileWatcher {private String A; private String B; private String C; private String D; private String E; public void run () {String a = "a"; String b = "b"; String c = "c"; String d = "d"; String e = "e"; A = a; B = b; C = c D = d; E = e; System.out.println (A); System.out.println (B); System.out.println (C); System.out.println (D); System.out.println (E);}}

So if you reorder, the effect might be as follows

Package com.apptest;public class VolatileWatcher {private String A; private String B; private String C; private String D; private String E; public void run () {String a = "a"; String b = "b"; String c = "c"; String d = "d"; String e = "e"; A = a; System.out.println (A); B = b System.out.println (B); C = c; System.out.println (C); D = d; System.out.println (D); E = e; System.out.println (E);}}

This is the result of possible reordering of JIT. In fact, registers and CPU will also be reordered, but eventually memory consistency will be guaranteed.

Third, how to prohibit instruction reordering?

In Java, there are only two keywords that prohibit instruction reordering, one is volatile and the other is final, which can also explain why final and volatile can not modify the same variable at the same time, because their functions overlap.

3. 1 do you want to ban it

First of all, to determine whether to prohibit reordering, reordering often occurs in multithreading problems, if the program is executed in serial, there is no need at all, therefore, single-threaded reference types (excluding constants and string constants, these types of references are recommended to add final) are not recommended to add final and volatile, of course, final needs to consider in depth, because sometimes we need to do some strong constraints, but generally speaking, we do not add.

3.2 principle

In multithreading, the maintenance of hanpens-before principles is not handled by JVM itself, but also needs to be instructed at the code level. In addition, the corresponding JIT compiles the instructions into instructions for registers and CPU to comply with.

The final effect of instruction reordering

Read operation

Write operation

3.3 effect demonstration

Going back to the beginning of the article, we add volatile modification to the C variable of VolatileWatcher, so the result of JIT reordering may be as follows

Public class VolatileWatcher {private String A; private String B; private volatile String C; private String D; private String E; public void run () {String a = "a"; String b = "b"; String c = "c"; String d = "d"; String e = "e"; B = b; A = a; C = c / / write barrier E = e; D = d; System.out.println (A); System.out.println (B); System.out.println (C); / / read barrier System.out.println (D); System.out.println (E);}}

We find that An and B cannot be reordered across the write barrier of C variables, but the An and B above the barrier can also be reordered, and E and D cannot cross the read barrier, but E and D can be sorted between the read barrier and the write barrier. (here it is deliberately written as A _ order outside the barrier, mainly to illustrate the function of the barrier, depending on the actual effect.)

4. What is the difference between final and volatile?

We know that final modifies read-only variables and has a strong "read-only" constraint. All final-decorated variables need to be initialized in the constructor (the final field outside the class will eventually be inserted into super (...).) After that, volatile is generally used to read and write multithreaded variables, but they all have the ability to implement a memory barrier, so to speak, to prohibit reordering.

Differences:

The write operation of the final field acts only on the constructor.

The read operation of final field is basically the same as that of volatile.

Thank you for reading! This is the end of this article on "sample Analysis of JMM instruction reordering". 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, you can share it 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.