The instruction rearrangement:
jvm will reorder instructions, when executed the code, in order to improve the efficiency of the processor, enter the code can be optimized, it does not guarantee the execution of each program statement in the order consistent with the order of the code,
Significance: The characteristics of the processor (CPU multi-level cache system, a multi-core processor, etc.) to an appropriate reordering machine instructions, may cause the machine instructions being more consistent execution characteristics of the CPU, maximize machine performance.
Common reordering has three levels:
Compiler optimization reordering : Compiler in single-threaded programs without changing the semantics of the premise, you can rearrange the order of execution of the statement.
ILP reordering : if the data dependency does not exist, the processor may change the execution of machine instructions corresponding to the statement sequence.
Reordering memory system : a processor using the cache and write buffer, such that load and store operations which appear likely to be out of order execution.
Impact on the single and multithreaded instruction reordering 5.1
Single-threaded:
For single-threaded concerned, because the compiler, runtime and processors must comply with as-if-serial semantics. No matter how reordering, single-threaded execution results will not change. So we need to consider the harm caused by the rearrangement of instructions, just enjoy it with the benefits of it.
Multithreading:
Question: For multi-threaded, the instruction rearrangement may bring us great harm (referring to a singleton double-checking mechanism).
Solution: by a memory barrier prohibiting reordering: JMM by inserting a specific type of memory barriers, to inhibit a particular type of processor and compiler discouraged ordering reordering.
Learning instruction reordering, let us know, because the instruction rearrangement, multi-threaded development, is the presence of a lot of order and visibility issues.
5.2 memory barrier
Memory barrier fence or memory (Memory Barrier), a memory state is to allow the CPU units visible to a technology other processing units.
There are two memory barrier ability:
as codes before and after the division of a fence, there is no data dependency reordering instruction code, to ensure a certain degree of ordering programs before and after the stop fences.
Forced to write dirty data buffer / cache write-back to main memory, so that the corresponding data in the cache fails to ensure the visibility of data.
There are three types of memory barriers and Pseudo type:
lfence: namely read barrier (the Load Barrier) , insert a read barrier before reading the instructions, you can let the data cache failure, re-load data from main memory to ensure that the reading of the latest data.
sfence: that is, write barrier (Barrier Store) , insert after the write command write barrier, allowing the write cache of the latest data is written back to main memory to ensure data is written immediately visible to other threads.
MFENCE , omnipotent barrier, and ability ifence of sfence.
Lock prefix : Lock memory is not a barrier, but it can complete a similar versatile memory barrier function.
Note: In Java: to achieve a memory barrier technology is volatile. volatile memory barrier is to use pseudo-prefixes embodiment Lock type realized (described further specific implementation)
6.Happens-before (the principle of first occurrence)
Jvm would just say our procedures in order to improve the operating efficiency of reordering optimization instruction, but instruction reordering happens-before need to comply with the rules, we can not say how you want to row on how to row, if that would not be very confusing.
6.1 happens-before rule
1. The program sequence rules: a thread, according to the order of the code book EDITORIAL preceding operation occurs at a later writing operation
2. Blocking rule: after a first operation unLock occurred in the face of the same amount lock lock operation
3.volatile variable rules: Write operations on a variable advance occurred in the face of this variable after the read operation. If a thread to go write a variable, then a thread to read, then write operations will certainly occur in the first read operation.
4. passing rules: if A happen-before operating Procedure B, B happen-before operating the operation C, the operation can be derived Ahappen-before C.
The thread starts rule: start Thread object () method of each of a first action occurs in this thread
6. Thread break the rules: a call to thread interrupt () method first occurred in the interrupted thread code detection to interrupt event occurs
7. Thread the end of the rule: thread in all operations take place in advance of the termination detection thread, we can end by Thread.join () method, Thread.isAlive () return value means detects that the thread has terminated execution
8. End of rule objects: an object initialization completion occurred in his first start finalize () method
On the order of 6.2 times and happen-before principle
1. a prior operation time occurs in another operation "does not mean" a further happen-before operating the operation
2. The operation happen-before another operation "does not mean" occurs before another operation on a operation time
7. Simple to understand instructions rearrangement, Happens-before the DCL singleton
Low performance problem for synchronous implementation delay loading method (single idler embodiment mode) is generated, using the DCL, i.e. double check method lock (Double Check Lock) to avoid each call getInstance () method are synchronized. Implementation as follows:
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {}
public static LazySingleton getInstance() {
if (instance == null) {
synchronized(LazySingleton.class){
if(instance == null){
instance = new LazySingleton();
}
}
}
return instance;
}
}
DCL for instance carried out two null judgment, the first layer is determined primarily to avoid unnecessary synchronization, the second layer is determined to create an instance in the case of the null.
But DCL is having unsafe sex, let's take a look at the following scenario:
A thread is assumed to perform instance = new LazySingleton () sentence, where a word appears, but in fact it is not an atomic operation, these words only to look after the corresponding assembly code is compiled JVM execution found this sentence is translated into eight assembly instructions, generally do three things:
- Examples LazySingleton to allocate memory.
- Initialization LazySingleton () constructor
- The instance of the object pointer to the allocated memory space (note that this step instance on a non-null).
However, since the Java compiler instruction rearrangement, and before JDK1.5 JMM (Java Memory Medel, i.e. Java memory model) Cache, the register write memory back to a predetermined primary sequence, the second and third points above the order is not guaranteed, that is, the order of execution may be 1-2-3 1-3-2 may be, if the latter, and the execution is completed in 3, 2 is not performed before, is switched to the thread B on this instance, when it has been executed in the thread of a third point a, we have a non-empty instance, the thread B are directly away instance, then, a matter of course and then given, and this is difficult to difficult to reproduce the tracking error it may be hidden for a long time.
After JDK1.5, officials have noticed this problem, adjust the JMM, embody the volatile keyword, so if JDK version 1.5 or later, simply define the instance you want to change the "private volatile static LazySingleton instance = null; "can guarantee to every instance are read from the main memory, written DCL can be used to complete a single embodiment mode. Of course, more or less volatile also affect performance.
