In the previous article, we introduced the concept of concurrent Java foundation and thread-safe, as well as introduce JMM memory model, including its definition of various rules. We also describe the differences in the realization of the principle volatile JMM, as well as Lock locks and synchronized synchronized way. Finally, about the final semantic keywords strengthening of the JSR-133.
Introduce so much content, mainly around the JMM in terms of, so this again JMM make a summary.
Processor Memory Model
Sequential Consistency memory model is a theoretical reference model, JMM processor and memory model will usually designed as Sequential Consistency memory model reference. JMM processor and memory model will have in the design of sequential consistency model to do some relaxation, because if the exact order to achieve consistency model processor and JMM, then a lot of processor and compiler optimizations should be disabled, which execution performance will have a great impact.
The relaxation of the different types of read / write operation of the execution order of combination, the common processor memory model can be divided into the following types:
- Relax Programs written - sequential read operations, thereby generating a total store ordering memory model (referred to as TSO).
- 1 on the basis of the foregoing, the program continues to relax write - a write operation sequence, thereby generating a partial store order memory model (referred to as PSO).
- 1 and 2 on the basis of the foregoing, the program continues to relax read - write and read - read operation sequence, thereby creating a memory model relaxed memory order (referred to as RMO) and PowerPC memory model.
Note that, where the processor read / write operation is relaxed, is no data dependency exists between the two operating premise (because the processor to comply with as-if-serial semantics, the data processor does not dependent on the presence of the two memory operations do reordering).
| Memory model name |
Respective processors |
Store-Load reordering |
Store-Store reordering |
Load-Load and Load-Store reordering |
You can read earlier written to other processors |
You can read the current processor of earlier write |
| RELEASE |
sparc-RELEASE X64 |
Y |
Y |
|||
| PSO |
sparc-PSO |
Y |
Y |
Y |
||
| RMO |
ia64 |
Y |
Y |
Y |
Y |
|
| PowerPC |
PowerPC |
Y |
Y |
Y |
Y |
Y |
The following table shows the detailed features common processor memory model:
In this table, we can see all the processor memory model are allowed to write - read reordering reasons explained in the first chapter: they all use a write cache, write cache may result in write - read reordering . At the same time, we can see the processor memory model allows earlier read to write the current processor, the reason is also because the write cache: Since the write buffer is visible only to the current processor, this feature may lead to more than the current processor other processors to see written temporarily stored in their own writing in the cache.
In the table above the various memory model processor, from top to bottom, the model from strong to weak. The more the pursuit of performance of the processor, memory model design will be weaker. Because these processors want their memory model bound for the better, so that they can do as much optimization to improve performance.
Since the common processor memory model weaker than JMM, place the compiler when generating java bytecode instruction will be executed in sequence inserted memory barrier to limit the reordering processor. Meanwhile, since the strength of the various processors is not the same memory model, in order to show a consistent memory model programmers in different processor platforms, JMM different processors need to insert memory barrier number and variety Not the same. The following figure shows a schematic view of the different processors JMM memory model memory barrier to be inserted:
As shown above, the differences shield JMM processor memory model, it presents a memory model is consistent java programmer on different processors internet.
The relationship between the JMM, processor memory model and sequential consistency memory model
JMM is a language-level memory model, processor memory model is a hardware-level memory model, sequential consistency memory model is a theoretical reference model. The following is a language model memory, processor memory model and strength of contrast sequential consistency model is a schematic view of memory:
From the graph we can see: Common four kinds of processor memory model than the commonly used language in 3 weaker memory model, processor memory model and language memory model than sequential consistency memory model to be weak. With the processor memory models, the more the pursuit of the implementation of language performance will be weaker memory model design.
JMM design
JMM from the designer's point of view, in the design of JMM, need to consider two key factors:
- Programmers use of the memory model. Programmers want memory model is easy to understand, easy to program. Programmers hope is based on a strong memory model to write code.
- Achieve compiler and processor memory model. Compiler and processor memory model bound to want them as little as possible, so that they can do as much optimization to improve performance. Compilers and processors hope to achieve a weak memory model.
Because of these two factors contradict each other, so the JSR-133 expert group core objective in the design of JMM is to find a good balance: on the one hand to provide visibility of memory guarantee strong enough for the programmer; on the other hand, to compile restrictions, and processors to relax as much as possible. Let's see how JSR-133 is to achieve this goal.
To illustrate, consider the previously mentioned circular area calculated sample code:
double pi = 3.14; //A
double r = 1.0; //B
double area = pi * r * r; //C
There are three happens- before calculating the relationship between the sample code above circle area:
- A happens- before B；
- B happens- before C；
- A happens- before C；
Since A happens- before B, happens- before it will require definition: A result of the operation to be performed on the B visible, and the execution order of operations ahead A B operation. However, the semantics of the program's perspective, A and B do not change the reordering i.e. execution result of the program, but also can improve the performance of execution of the program (this allows reordering reduces constraints on the optimization of compilers and processors ). In other words, these three happens- before the above relation, although the 2 and 3 will be needed, but 1 is not necessary. Therefore, JMM happens- before the ban reordering divided into the following two categories:
- The program will change the results of the implementation of reordering.
- The program will not change the results of the implementation of reordering.
JMM reordering these two different natures, took a different strategy:
- Reordering the results will change for the program, JMM requires compilers and processors must prohibit such reordering.
- Reordering will not change the result of execution for the program, JMM compiler and a processor is not required (this allows reordering JMM).
The following is a schematic design of JMM:
As can be seen from the figure by two points:
- happens- before JMM rules provided to the programmer to meet the needs of programmers. JMM's happens- before the rule is not only easy to understand but also provides a strong enough memory to ensure the visibility of the programmers (and some memory to ensure the visibility is not necessarily real, such as the above A happens- before B).
- JMM compiler and processor have been bound as little as possible. We can see from the above analysis, JMM is in fact follow a basic principle: they do not change the results of the program (refer to the single-threaded program and correct multithreaded program synchronization), how optimizing compilers and processors will do . For example, if the compiler, after careful analysis, finds a lock can only be accessed by a single thread, the lock can be eliminated. As another example, if the compiler, after careful analysis, finds a volatile variable will only be only a single thread access, so the compiler can put this volatile variables to be treated as an ordinary variable. These optimizations will neither alter the results of the program, but also improve the performance of programs.
JMM guarantee the visibility of memory
Memory Java programs to ensure the visibility of the program according to the type can be divided into the following three categories:
- Single-threaded programs. Visibility single-threaded program memory problem does not occur. Compiler, runtime, and the processor will work together to ensure the implementation of the results of the same single-threaded program execution result of the program in sequential consistency model.
- Multi-threaded program correctly synchronized. Multithreaded program will be properly synchronized with sequential consistency (program execution result of the program execution results in the same sequence memory consistency model). This is the focus of attention JMM, JMM to provide visibility of memory guarantee for programmers by reordering restrictions compilers and processors.
- No synchronization / multi-threaded program is not properly synchronized. JMM provide them with minimum security guarantee: read the thread execution value, or value before a thread is written, either the default values (0, null, false).
The following figure shows the results of the implementation of JMM in these three programs in sequential consistency memory model of the similarities and differences:
As long as a multi-threaded program is correct synchronization, JMM ensure the implementation of the results of the program on any processor platform, consistent with the sequential consistency memory model in the implementation of the results of the program.
JSR-133 patch on the old memory model
JSR-133 patch on the old memory model before JDK5 of two main reasons:
- Enhanced volatile memory semantics. Old model allows volatile memory and a regular variable reordering. JSR-133 and restricted volatile variable reordering common variable so volatile write - read and lock release - with the same acquisition memory semantics.
- Enhance the final memory semantics. In the old memory model, read many times the value of a final variable of the same may not be the same. For this reason, JSR-133 to increase the final weight of the two collation. Now, final safety has been initialized.
Reprinted from Concurrent Programming Network - ifeve.com
More please pay attention to micro-channel public number of rivers and lakes] [Java technology
A technical station Ali Java engineers. Author Huang oblique, focused Java related technologies: SSM, SpringBoot, MySQL, distributed, middleware, cluster, Linux, network, multi-threaded, occasionally speaking point Docker, ELK, as well as dry goods and technology to share the learning experience, committed to Java full stack development! (No reply after public concern "Java" Java can receive basic, advanced, and the project architect and other free learning materials, more databases, distributed, service and other popular micro learning video technology, rich content, both theory and practice, also presented will be the original author of the study guide Java, Java programmer interview guide and other dry goods resources)
