Personal creation convention: I declare that all articles created are their own original, if there is any reference to any article, will be marked out, if there are omissions, welcome everyone critique. If you find online plagiarism of this article, welcome to report, and actively submit an issue to the Github warehouse, thank you for your support ~
This article refers to a large number of articles, documents and papers, but it is really complicated. My level is limited, and my understanding may not be in place. If you have any objections, please leave a comment. This series will continue to be updated, and you are welcome to comment on your questions and errors and omissions
If you like the single-part version, please visit: The most hardcore Java New Memory Model parsing and Experimental single-part version (constantly updated in QA) If you like this split version, here is the table of contents:
- 1. What is the Java memory model
- Analysis and experiment of the new memory model in Java – 2. Atomic access and word splitting
- Core Understanding of the Memory barrier (CPU+ compiler)
- The most core Java new memory model analysis and experiment – 4. Java new memory access method and experiment
- Net most core Java new memory model analysis and experiment – 5. JVM underlying memory barrier source analysis
JMM related documents:
- Java Language Specification Chapter 17
- The JSR-133 Cookbook for Compiler Writers – Doug Lea’s
- Using JDK 9 Memory Order Modes – Doug Lea’s
Memory barriers, CPU and memory model related:
- Weak vs. Strong Memory Models
- Memory Barriers: a Hardware View for Software Hackers
- A Detailed Analysis of Contemporary ARM and x86 Architectures
- Memory Model = Instruction Reordering + Store Atomicity
- Out-of-Order Execution
X86 cpus
- x86 wiki
- Intel® 64 and IA-32 Architectures Software Developer Manuals
- Formal Specification of the x86 Instruction Set Architecture
ARM CPU
- ARM wiki
- aarch64 Cortex-A710 Specification
Various understandings of consistency:
- Coherence and Consistency
Aleskey’s JMM:
- Aleksey Shipilev – Don’t misunderstand the Java Memory Model (Part 1)
- Aleksey Shipilev – Don’t misunderstand the Java Memory Model (part 2)
Many Java developments use Java’s concurrency synchronization mechanisms, such as volatile, synchronized, and Lock. Also there are a lot of people read the JSR chapter 17 Threads and Locks (address: docs.oracle.com/javase/spec…). , including synchronization, Wait/Notify, Sleep & Yield, and memory models. But I also believe that most people like me, the first time reading, feeling is watching the fun, after reading only know that he is such a regulation, but why such regulation, not so regulation, do not have a very clear understanding. At the same time, combined with the Hotspot implementation and the interpretation of Hotspot source code, we even found that due to the static code compilation optimization of Javac and the JIT compilation optimization of C1 and C2, the final code performance was not quite consistent with our understanding of the code from the specification. In addition, such inconsistencies lead to misunderstandings when we learn the Java Memory Model (JMM) and understand the design of the Java Memory Model if we try to use actual code. I myself am constantly trying to understand the Java memory model, rereading THE JLS and various gods’ analyses. This series will sort through some of my personal insights from reading these specifications and analyzing them, as well as some experiments with JCStress, to help you understand the Java memory model and API abstraction post-Java 9. Still emphasize, however, the design of the memory model, the starting point is to let you don’t have to care about the underlying and abstracting some design, involves a lot of things, my level is limited, might not reach the designated position, understand I will try to put the arguments of the each out as well as the reference, please do not completely believe that all the views here, If you have any objections, please refute them with specific examples and leave a comment.
3. Atomic access
Atomic access: The operation of writing and reading a field is itself atomic indivisible. One of the things that you probably don’t pay much attention to is that, according to JLS Chapter 17, the following two operations are not atomic access:
For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic.
In short, a non-volatile long or double may write updates to two separate 32-bit bits, so it is non-atomic. Volatile long or double reads and writes are atomic.
To illustrate our atomicity here, I’ll cite an example from JCStress:
We ran the code here using a Java 8 32bit JVM (32-bit machines are no longer supported after Java 9), and the result was:
As you can see, it’s not just -1 and 0 that we specify in our code, but also some intermediate results.
4. I won the word tearing.
Word tearing means that when you update one field, one element in an array, it will affect the value of another field, another element in the array. For example, the processor does not provide the ability to write a single byte. If the smallest dimension is int, updating the byte array on such a processor would be problematic if it simply reads the entire INT of the byte, updates the corresponding byte, and then writes the entire int back. There is no word splitting in Java, fields and array elements are independent, and updating one field or element cannot affect reading or updating of any other field or element.
To illustrate what word splitting is, an unfortunate example is thread-unsafe BitSet. The abstraction of a BitSet is a set of bits (0,1). The underlying implementation is an array of long bits. A long holds 64 bits. Update it back. The interface level is updated bit by bit, but the bottom level is updated in the dimension of long (because it is the bottom long array). Obviously, if there is no synchronization lock, the concurrent access will cause concurrent security problems and cause word splitting problems:
The result is:
This is an unfortunate example of what word splitting is. Java guarantees no word splitting. In the BitSet example above, we tried to update a Boolean array so that the result would only be true:
This is only going to be true true
Next, we will enter a more painful chapters, memory barriers, but you don’t need to worry too much, also from my personal experience, memory barriers are hard to understand because the Internet is basically not from Java have shielding the low-level details for you to tell you, direct understanding will be hard to convince myself, so I would guess something then misunderstanding, So this article is not going to give you Doug Lea’s abstraction of Java’s four memory barriers (LoadLoad, StoreStore, LoadStore, and StoreLoad), which are still in use today. The design of these four memory barriers has been somewhat outdated for modern CPUS, and now more acquire, release and fence are used. I hope that through some articles about the underlying details of the author, we can extract things that are easy to understand for your reference, so as to better and easier understand the memory barriers.
Wechat search “my programming meow” public account, add the author’s wechat, a daily brush, easy to improve skills, won a variety of offers:
I will often post some good news videos of various frames of official community and add personal translation subtitles to the following address (including the above official account), welcome to pay attention:
- Zhihu: www.zhihu.com/people/zhxh…
- B station: space.bilibili.com/31359187
I will often post some good news videos of various frames of official community and add personal translation subtitles to the following address (including the above official account), welcome to pay attention: