Interviewer: I remember asking last time why do we have a Java memory model

Interviewer: I think your final answer was that Java introduced a specification called the “Java Memory model” to mask the differences between hardware and operating system access to memory, which ensures that Java programs can access memory consistently across different platforms

Candidate: Yeah, right

Interviewer: Why don’t you talk about the Java memory model today?

Candidate: Well, it’s important to note before we get into this: The Java Memory model is a “specification” that the Java virtual Machine implements.

Candidate: The main content of the Java memory model, I personally think there are several pieces

Candidates: 1. The abstract structure of the Java memory model

Candidates: 2. Happen before rule

Candidates: 3. Exploring the semantics of volatile memory (which I’ll explain more about later)

Interviewer: Why don’t you start with point one? Let’s talk about the abstract structure of the Java memory model. Okay?

Candidate: HMM. The Java memory model defines the specification for Java threads to interact with in-memory data.

Candidate: “shared variables” between threads are stored in “main memory”. Each thread has its own private “local memory” where it stores copies of shared variables to read/write.

Candidate: Local memory is an abstraction of the Java memory model, not a real one.

Candidate: By the way, draw a picture. After reading the picture, you will understand.

Candidate: The Java memory model specifies that all thread operations on variables must be performed in “local memory” and that variables “cannot be read or written directly to main memory”

Candidate: The Java memory model defines eight operations to accomplish “how variables go from main memory to local memory, and from local memory to main memory.”

Candidate: respectively is the read/load/use/assign/store/write/lock/unlock operation

Candidate: Look, eight operations is a lot. One read and write to a variable covers all of these operations. Let me draw another picture to show you

Candidate: Get it? Just read and write using various operations (:

Interviewer: I see. It’s very simple. What happens before?

Candidate: HMM, ok (:

Candidate: As I understand it, happen-before is actually a set of “rules”. The Java memory model defines this set of rules to illustrate memory “visibility” between operations

Candidate: As mentioned last time with instruction reordering, instruction reordering is a problem at both the CPU and compiler levels.

Candidate: Instruction reordering can be efficient, but in concurrent programming, we want to control the results of the program while keeping “efficiency” in mind.

Candidate: To put it bluntly: this set of operations cannot be reordered in important scenarios, and “the result of the previous operation must be visible to subsequent operations.”

Interviewer: HMM…

Candidate: The Java memory model then comes up with the happen-before set of eight rules

Candidates: such as transitivity, volatile variable rules, program order rules, monitor locking rules… (See the meaning of the rules, this is not difficult)

Candidates: Just remember that there are rules for happening-before. We write code that does not reorder as long as the results of previous operations are visible to subsequent operations under these rules.

Interviewer: I see what you mean

Interviewer: And finally, volatile?

Candidate: Well, volatile is a Java keyword

Candidate: Why volatile is so often used in the Java memory model, I think it’s mainly because of its features: visibility and ordering (no reordering)

Candidate: The Java Memory model is a specification that, in large part, addresses issues of visibility and order.

Interviewer: Tell me how it works. How does volatile make it visible and ordered

Candidate: Java memory model in order to achieve the volatile order and visibility, defines the “norm” of four memory barrier, respectively is LoadLoad/LoadStore/StoreLoad/StoreStore

Candidate: Going back to volatile, which, in plain English, means “memory barriers” before and after volatile so that the compiler and CPU cannot reorder, resulting in order, and writing volatile variables visible to other threads.

Candidate: The Java memory model defines the specification, so the Java virtual machine has to implement it, right?

Interviewer: HMM…

Candidate: Having seen the Hotspot VIRTUAL machine implementation before, at the “assembly” level it is actually implemented with Lock prefix directives rather than various fence directives (mainly due to simplicity). Because most platforms support the Lock directive, and the fence directive is x86).

Candidate: The lock instruction ensures that CPU and compiler reordering is disabled (order is guaranteed), that CPU writes to the core are immediately effective and other core cache data is invalidated (visibility is guaranteed).

Interviewer: Now that you mention it, I’d like to ask what is the relationship between volatile and the MESI protocol?

Candidate: They are not directly related.

Candidate: The Java memory model focuses on high-level abstraction at the programming language level. MESI is the CPU cache consistency protocol. Different CPU architectures are different, and some cpus may not use MESI at all.

Candidate: It’s just that MESI is so famous that everyone uses him as an example. MESI may only be part of the “specific scenario” for volatile visibility/ordering (:

Interviewer: HMM…

Candidates: In order for Java programmers to mask the above low-level knowledge, get a quick start using volatile variables

Candidate: Rules for volatile variables are defined in the Happen -before rules of the Java memory model

Candidate: This rule essentially states that writes to a volatile variable are visible relative to subsequent reads to that volatile variable

Candidate: It is governed by the happen-before rule that as long as the variable declares the volatile keyword, read after write must see the written value. (Visibility, order)

Interviewer: HMM… To understand the

This paper concludes:

  • Why does The Java memory model exist: In order to shield the differences between hardware and operating system access to memory, Java proposed the specification of the “Java memory model” to ensure that the Java program access to memory on various platforms can get the same effect
  • Java Memory model abstract structure: “shared variables” between threads are stored in “main memory,” and each thread has its own private “local memory” that stores copies of shared variables to read/write by that thread. All thread operations on variables must be done in “local memory”, whereas variables “cannot be read or written directly to main memory”
  • The Happen -before rule: The Java memory model specifies that in some of the eight scenarios, the result of a previous operation must be visible to subsequent operations. These eight rules become the happen-before rules
  • Volatile: Volatile is a Java keyword that modifiers variables that are visible and ordered (they will not be reordered). Visibility is done by happening-before rules, order is done by “memory barriers” defined by the Java memory model, implemented by the actual HotSpot VIRTUAL machine, and Lock instructions at the bottom of the assembly.

Welcome to follow my wechat official account [Java3y] to talk about Java interview, on line interview series continue to update!

Online Interviewer – Mobile seriesTwo continuous updates a week!

Line – to – line interviewers – computer – end seriesTwo continuous updates a week!

Original is not easy!! Three times!!