Learning the JVM from Scratch series:

Learning from the Ground up ->JVM (Preface)

Learning from the ground up ->JVM (Preface) – Why delay?

JVM (a) : The Java Memory Model (JMM) is not the Java Virtual Machine memory model (JVM) oh!

Learning from the Ground up – JVM part 2: Why does Java Need a JVM (Java Virtual Machine)?

Learning from the Ground up ->JVM (3) : Classloader (1)

Learning from the Ground up ->JVM (4) : Classloader (Middle)

Learning from the ground up ->JVM (5) : Classloader (2)

Learning from the Ground up – JVM part 6: The Relationship between threads and JVMS

Learning from the ground up ->JVM (7) : Runtime Data Area (1)

Learning from the ground up ->JVM (8) : Runtime Data area (2)

Learning from scratch ->JVM (9) : Garbage Collection (1)

Learning from the ground up ->JVM (10) : Garbage Collection (middle)

Learning from scratch ->JVM (11) : Garbage Collection (2)

preface

Before I dive into the JVM world, I want to sort out a conceptual detail for you. The Java memory model and the JVM memory model are two different things.

Many friends on the Internet blog, unconscious of the Java memory model and the JVM memory model, which makes part of don’t understand the truth of mere spectators would think that this is the case, but in fact the Java memory model and the JVM memory model, conceptually speaking are two different things, of course, can’t deny is both have great relevance, Even in a sense, the JVM is an implementation of the JMM, and the JMM is for the JVM, but that doesn’t confuse the two. (Mainly because the JMM is designed to serve multiple threads, and the JVM has the concept of serving multiple threads.)

So if we want to understand the JVM, we need to know something about the JMM. Of course, JMM itself is a very complex concept, and I will not be able to understand it in a few words in this article, but for now, we will simply take a look at the JMM and see it for the rest of our understanding of the JVM.

So, what is the Java Memory Model (JMM)?

Before we get to the JMM, we need to know why the Java Virtual Machine specification defines the JMM.

The origin of the JMM (Java Memory Model)

There’s a very important feature in Java that I’m sure all of you who have studied Java know, that we talk about all the time: multithreaded programming.

In the process of multithreaded programming, there will be multiple threads, so in the concurrent programming of multiple threads, we need to deal with two key problems:

1. How threads communicate with each other 2. How threads synchronize with each other (threads here are active entities that execute concurrently).Copy the code

Instead of going into the discussion here, let’s just focus on the first point, which is how threads communicate with each other. (Communication refers to the mechanism by which threads exchange information)

In imperative programming, there are two communication mechanisms between threads:

1. Shared memory Threads share the common state of the program and communicate implicitly with each other by writing and reading the common state in memory. 2. Messaging. In the concurrent model of messaging, there is no common state between threads, and threads must communicate explicitly by explicitly sending messages.Copy the code

In the imperative programming of Java, which we mainly focus on, the mode is shared memory, and the communication between Java threads is always implicit, and the whole communication process is completely transparent to the programmer. Java programmers writing multithreaded programs are likely to encounter all sorts of strange memory visibility problems if they don’t understand how implicit communication between threads works.

This raises the question of what controls implicit communication between Java threads in the shared memory model.

Yes, implicit communication between Java threads is controlled by the Java memory model (JMM) that we will cover in this article.

Why does Java need JMM?

So why did Java choose to create its own memory model when, in theory, we already had a proper memory model on a physical machine? Of course, since Java was the first language to attempt to provide a memory model, we can say why Java’s obsession with creating its own memory model in the first place?

Here, we must talk about a classic Java theory: “Develop once, execute everywhere.”

In the process of realization of this ability, Java, found that the difficulty of the problem is being underestimated, because there is no rigorous memory model definition, there are a lot of ambiguous, for example of different processor hardware, between different operating systems, some support cache consistency, some do not support, has its own memory sorting model, If Java does not specify its own memory model, then the so-called “development once, execution everywhere” in Java cannot be implemented at this point.

PS: Cache inconsistency, two threads to the memory read/write operations, there is no unified specification, will eventually lead to the final calculation of data in memory, and we expect data inconsistency.

In plain English, the main goal of the JMM is to define access rules for variables in the program, that is, to store and retrieve variables from memory in the virtual machine (by variables, I mean shared variables, that is, instance objects, static fields, array objects, and so on, stored in heap memory. Low-level details such as local variables, which are thread private and will not be shared. These rules are used to regulate the read and write operations of memory, so as to ensure the correctness of instruction execution.

Therefore, Java urgently needs a complete memory model that all Java developers, all compilers from different platforms, and all JVM engineers can clearly agree on.

Thus, the Java memory model JMM was born.

What did the JMM do?

As I said earlier, in Java, communication between threads is controlled by the JMM. The JMM determines when a write to a shared variable by one thread is visible to another thread.

The JMM states that shared variables between threads are stored in main memory, and each thread has a private local memory where it stores copies of shared variables to read/write. Local memory is a JMM defined concept, not a real one. Local memory covers caches, write buffers, registers, and other hardware and compiler optimizations.

All operations by a thread on a variable must be done in working memory rather than directly reading or writing to main memory.

Different threads cannot directly access variables in each other’s working memory, and the transfer of variables between threads requires data synchronization between their own working memory and main memory.

The JMM is used to synchronize data between working memory and main memory. It specifies how and when to synchronize data.

The Java memory model JMM is abstracted as follows:

conclusion

This paper mainly because I decided to write a JVM series, access to information on the Internet, often found that a lot of technology blog blogger, Java memory model and the JVM will the confusion, maybe a lot of technology bosses is to know the difference between, just at the time of writing, there is no specially to avoid the difference, And that’s why I’m so cute.

The JVM is the Java Virtual machine model, while the JMM is the Java memory model, which is completely different, and the main memory and working memory in the JMM are not hierarchically separated from the heap, stack, and method areas in the JVM, which are essentially unrelated.

However, from these two, we can learn a division of the concept of the system thought, which is also very good for us.

Therefore, I will treat this article as the first in a series of articles on the JVM.

Reference books

Cheng Xiaoming: Understanding the Java Memory Model in Depth

Refer to the blog

Juejin. Cn/post / 684490…

Blog.csdn.net/zhaomengszu…

Blog.csdn.net/fuzhongmin0…

www.jianshu.com/p/8a58d8335…