Pay attention, don’t get lost; continue to update Java related technologies and information! !
Recently, I have interviewed many high-level Java developers and asked many times about the Java memory model. After asking, many people started to answer:
Java memory model consists of several parts, heap, local method stack, virtual machine stack, method area...
Every time I don't want to interrupt them, although I know this is another friend who misunderstood my question.
In fact, the Java memory model I want to ask about is related to concurrent programming. The candidate's answer to me is called the JVM memory structure, which is completely different.
Many times, without interrupting them, some people slowly talked about GC-related knowledge. In this case, I can only bite the bullet and continue to ask some knowledge related to JVM.
However, my intention is to see how much he knows about Java concurrency.
Often, I continue to ask some of their answers about the "Java memory model" related knowledge, a friendly reminder, in fact, the Java memory model I want to ask is not the one he answered...
Sometimes, I will further remind one sentence: it is related to concurrent programming, it is related to main memory and thread working memory. . .
So, this article will briefly talk about how to answer this interview question about the Java memory model.
Why misunderstood
First of all, let's first analyze what many people ask, even if most people answer the wrong questions?
I think there are several reasons:
1. Java memory model, this term sounds too much like knowledge about memory distribution. It sounds like it has nothing to do with concurrent programming.
2. A lot of information on the Internet is wrong. If you don’t believe me, go to the Internet and search for "Java Memory Model". You will find that many people have introduced the knowledge of the JVM memory structure under the title of the memory model.
To mention here, I tried a Google search and searched for "Java Memory Model". The results displayed on the homepage are as follows:
Among the top 5 articles on the homepage, 1 is wrong and introduces the JVM memory structure.
3. There is still a situation, although it is rare, but there is also. That is, many interviewers themselves think that the memory model is to introduce the knowledge of heap, stack, and method area. As a result, sometimes interviewers do not know how they should answer.
So, what exactly is the Java memory model? How should you answer this interview question?
What is the memory model
The Java memory model is translated from the English Java Memory Model (JMM). In fact, JMM is not as real as the JVM memory structure. He is just an abstract concept.
The knowledge of Java memory model is described in JSR-133: Java Memory Model and Thread Specification. JMM is related to multithreading. It describes a set of rules or specifications. This specification defines that when one thread writes to a shared variable, it is visible to another thread.
The Java Memory Model (JMM) is a kind of memory model that conforms to the specifications of the memory model, shields the access differences of various hardware and operating systems, and ensures that Java programs can obtain consistent effects on memory access under various platforms. The mechanism and specification of The purpose is to solve the atomicity, visibility (cache coherency) and order problems that exist when multiple threads communicate through shared memory.
So, let us first talk about what is the so-called memory model specification, what are the atomicity, visibility, and orderliness mentioned here?
Atomicity
Thread is the basic unit of CPU scheduling. The CPU has the concept of time slices and will perform thread scheduling according to different scheduling algorithms. So in a multi-threaded scenario, atomicity problems will occur. Because when a thread is performing a read-modify-write operation, after performing the read-modification, the time slice is exhausted, and it will be required to give up the CPU and wait for rescheduling. In this case, read/write is not an atomic operation. That is, there is an atomic problem.
Cache coherency
In a multi-core CPU and multi-threaded scenario, each core has at least one L1 cache. If multiple threads access a shared memory in the process, and these multiple threads are executed on different cores, each core will keep a shared memory buffer in its own caehe. Since multiple cores can be parallelized, multiple threads may write to their respective caches at the same time, and the data between the respective caches may be different.
Adding a cache between the CPU and the main memory may cause cache coherency problems in multi-threaded scenarios. That is to say, in a multi-core CPU, the cache content of the same data in each core's own cache may be inconsistent .
Orderliness
In addition to the introduction of time slices, due to processor optimization and instruction rearrangement, the CPU may also perform out-of-order execution of the input code. For example, load->add->save may be optimized to load->save->add. This is the problem of order.
The consistency problems caused by multi-CPU and multi-level caches, the atomicity problems caused by the CPU time slice mechanism, and the ordering problems caused by processor optimization and instruction rearrangement are all caused by the continuous upgrade of hardware. So, is there any mechanism to solve these problems?
The simplest and most direct way is to abolish the processor and processor optimization technology, abolish the CPU cache, and let the CPU directly interact with the main memory. However, this can guarantee concurrency problems under multithreading. However, this is a bit of a choke.
Therefore, in order to ensure atomicity, visibility and order can be met in concurrent programming. There is an important concept, that is-the memory model.
In order to ensure the correctness of shared memory (visibility, orderliness, atomicity), the memory model defines the specification of read and write operations of multithreaded programs in the shared memory system. These rules are used to regulate the read and write operations to the memory to ensure the correctness of the instruction execution. It is related to the processor, to the cache, to concurrency, and to the compiler. He solved the memory access problems caused by CPU multi-level cache, processor optimization, instruction rearrangement, etc., and ensured consistency, atomicity and order in concurrent scenarios.
In response to the above problems, different operating systems have different solutions, and the Java language defines a set of memory model specifications that belong to the Java language, that is, the Java memory model, in order to shield the underlying differences.
The Java memory model stipulates that all variables are stored in the main memory. Each thread has its own working memory. The working memory of the thread stores a copy of the main memory of the variables used in the thread. All operations must be performed in the working memory, and the main memory cannot be read or written directly. Different threads cannot directly access the variables in each other's working memory. The transfer of variables between threads requires data synchronization between their own working memory and main memory.
The JMM acts on the data synchronization process between the working memory and the main memory. He stipulates how to do data synchronization and when to do data synchronization.
Implementation of Java Memory Model
Friends who know Java multithreading know that a series of keywords related to concurrent processing are provided in Java, such as volatile, synchronized, final, concurren packages, etc. In fact, these are some keywords provided to programmers after the Java memory model encapsulates the underlying implementation.
When developing multi-threaded code, we can directly use keywords such as synchronized to control concurrency, and never need to care about the underlying compiler optimization, cache consistency and other issues. Therefore, the Java memory model, in addition to defining a set of specifications, also provides a series of primitives that encapsulate the underlying implementation for direct use by developers.
This article is not going to introduce all the keywords one by one, because there are many materials on the Internet about the usage of each keyword. Readers can learn by themselves. Another important point of this article is that we mentioned earlier that concurrent programming must solve the problems of atomicity, order and consistency. Let's take a look at what methods are used to ensure in Java.
Atomicity
In Java, in order to ensure atomicity, two advanced bytecode instructions monitor and monitorexit are provided. In the article on the realization principle of synchronized, it was introduced that the keywords corresponding to these two bytecodes in Java are synchronized.
Therefore, synchronized can be used in Java to ensure that operations within methods and code blocks are atomic.
Visibility
The Java memory model is implemented by the way that relies on the main memory as the transfer medium that synchronizes the new value back to the main memory after the variable is modified, and refreshes the variable value from the main memory before the variable is read.
The volatile keyword in Java provides a function, that is, the modified variable can be synchronized to the main memory immediately after being modified, and the modified variable is refreshed from the main memory every time before being used. Therefore, volatile can be used to ensure the visibility of variables during multithreaded operations.
In addition to volatile, the two keywords synchronized and final in Java can also achieve visibility. It's just that the implementation is different, so it won't be expanded here.
Orderliness
In Java, synchronized and volatile can be used to ensure the orderliness of operations between multiple threads. The implementation method is different:
The volatile keyword prohibits instruction rearrangement. The synchronized keyword guarantees that only one thread is allowed to operate at the same time.
Well, here is a brief introduction to the keywords that can be used to solve atomicity, visibility, and order in Java concurrent programming. Readers may have discovered that it seems that the synchronized keyword is omnipotent. It can meet the above three characteristics at the same time. This is actually the reason why many people abuse synchronized.
However, synchronized affects performance. Although the compiler provides many lock optimization techniques, it is not recommended to overuse it.
How to answer the interview
I have introduced some basic knowledge related to the Java memory model. It is just the basics, not all, because any knowledge point can still be expanded. For example, how does volatile achieve visibility? How does synchronized achieve order?
However, when the interviewer asks you: Can you briefly introduce the memory model you understand?
First of all, confirm with the interviewer: The memory model you mentioned refers to JMM, which is related to concurrent programming, right?
After getting an affirmative answer, start the introduction (if not, then you may have to answer the heap, stack, method area...囧...):
The Java memory model is actually a mechanism and specification that guarantees that Java programs can access memory under various platforms with consistent effects. The purpose is to solve the atomicity, visibility (cache coherency) and order problems that exist when multiple threads communicate through shared memory.
In addition, the Java memory model also provides a series of primitives that encapsulate the underlying implementation for developers to use directly. For example, some of our commonly used keywords: synchronized, volatile, and concurrent packages.
The answer is all right here, and then the interviewer may continue to ask, and then continue to answer according to his follow-up.
So, when someone asks you about the Java memory model, don't just answer the stack, method area, or even GC without a single mouth. It looks very unprofessional!
If you find it helpful, please give me a thumbs up, comment and encourage! Thank you