Memory semantics of the Java memory model-final domain

An introduction

Speaking of final you must know that it is a keyword in Java, so what does it do in Java, you know? If you do not know, please go to this article to understand the next https://www.cnblogs.com/yuanfy008/p/8021673.html

Today, let's talk about the memory semantics of the final domain in JMM.

Re-ordering rules for final fields

To get to the point, for final domains, compilers and processors must follow two reordering rules (JSR-133 only enhances the final domain):

　1) write to a final field within the constructor, and then assign a reference to the referenced variable in the constructor, and the two operation cannot be reordered.

2) The first time you read a reference to an object containing a final field, and the final field is then first read, the two operations cannot be reordered.

　　Here we illustrate these two points by case (assuming thread 1 executes writer () and then another thread executes the reader () method):

 Public classFinalexample {Static volatile BooleanFlag =true; inti = 0; Final intJ; StaticFinalexample obj;  PublicFinalexample () {//constructor Functioni = 1;//write normal fieldsj = 2;//Write final field    }     Public Static voidWriter () {//Thread 1 Writeobj =Newfinalexample (); }     Public Static voidReader () {//Thread 2 Readfinalexample example = obj;//Read Object referenceSystem.out.println (EXAMPLE.I);//Read normal domainSystem.out.println (EXAMPLE.J);//Read final field    }}

　　A reorder rule that writes a final field prevents the final field from being sorted out of the constructor. The implementation of this rule consists of the following two aspects:

　　1) JMM prohibit the compiler bar from the final field of the write-reordering to the constructor function.

2) The compiler inserts a storestore barrier before the constructor return after the final field is written. This barrier prohibits the processor from ordering the final domain's write-back to the constructor.

　　So thread 1 execution order such as (where the order of writing ordinary fields is not guaranteed, theoretically there are three cases, to verify that the normal domain has a reordering of the results is a bit difficult, because there is no guarantee that thread 1 to reorder the normal domain, thread 2 can read its previous 0 value):

　　the reordering rules for the Read final field are: In one thread, the first read of this object refers to the final domain contained in the first read of the object, and JMM prohibits the processor from reordering the two operations. Where the compiler inserts a loadload barrier before the read final domain operation . because the Loadload barrier is inserted, the operation to read the normal domain i is not reordered to the Read final field, but does not guarantee that it will reflow to the front of the read object reference. So one of the execution sequences of thread 2 can be imagined, and there is no drawing of the execution sequence of thread 2.

Three final field is a reference type

　　If the Finaly field is a reference type, what is handled in JMM? for reference types, the collation of the Write final field adds the following constraint to the compiler and processor: write to the member domain of a final referenced object within the constructor, and then assign the reference to a reference variable outside of the constructor to the constructed object. There is no reordering between these two operations.

above and above should be noted: only in the constructor method. It is also necessary to ensure that the above rules require a condition: within the constructor, the reference to the constructed object cannot be made visible to other threads, i.e. the corresponding reference cannot be "escaped" in the constructor. The following cases:

　　

classFinalreferenceescapeexample {Final inti; StaticFinalreferenceescapeexample obj;  Publicfinalreferenceescapeexample () {i= 1; 1 obj= This;//2 This reference escapes    }     Public Static voidwriter () {//thread 1Newfinalreferenceescapeexample (); }     Public Static voidReader () {//thread 2if(obj! =NULL) {System.out.println (OBJ.I); }    }}

　　The above program, the first step to write the final field and the second step is not guaranteed to reorder. So when the first and second steps are re-queued after thread 1 finishes this step (obj = this), the time slice is given to the second thread, and thread 2 will get the value before the final domain is initialized, which is definitely against the program's original intention.

　　

Memory semantics of the Java memory model-final domain