Knowing this, volatile is stable during the interview
Posted Jun 16, 2020 • 4 min read
In job interviews related to Java, many interviewers like to check the interviewers' understanding of Java concurrency. Using the volatile keyword as a small entry point, you can often ask the question about the Java Memory Model(JMM). Some features of Java concurrent programming are involved. In-depth, you can also investigate the underlying implementation of the JVM and the relevant knowledge of the operating system.
This article uses a hypothetical interview process to gain a deeper understanding of the volitile keyword
The title is suspected of the title party, but if you understand the two articles involved in the article, I believe you have a deeper understanding of volatile!
[The Soul Torture Begins]
Interviewer:How about Java concurrency? Tell me about your understanding of the volatile keyword?
Interviewer:Can you tell me in detail what is memory visibility and what is reordering?
Interviewer:How does volatile ensure visibility? For visibility between multiple threads, can you talk about how the underlying principles are implemented?
Interviewer:How does the volatile keyword guarantee order?
Interviewer:volatile can guarantee visibility and order, but can it guarantee atomicity? why?
Interviewer:Have you learned about the JMM memory model? Simple talk
At this point, my eyes are always tearful. Not because of my deep love for the code, but because of the sincerity of my dishes!
It s okay, isn t it just a volatile? Don't read it, can't I study?
Q1:Could you talk about your understanding of the volatile keyword?
volatile is a lightweight synchronization mechanism provided by the JVM
- Guarantee visibility
- Ensure orderliness, prohibit instruction rearrangement
- Does not guarantee atomicity(need to use synchronized or CAS)
Boy, isn't it good? The answer is right 1 + 1, you have to get 2 + 2 difficulty
Q2:What is memory visibility and how does volatile ensure visibility between multiple threads?
The visibility of questions 2 and 3 is essentially the same question when interpreted using JMM. As for ordering and reordering, we will discuss it in question 4.
When asked about the visibility of memory, volatile related, just move out the JMM memory model. Put the picture first, then perform.
The following is my personal answer, there are deficiencies or loopholes, welcome to correct and point out!
The so-called visibility refers to when a thread modifies the value of a shared variable, the new value is immediately known to other threads
Each thread has its own independent working interval. In order to match the running speed of the CPU, they will not directly read the data from the memory, but copy the data to the CPU cache(that is, each thread's own working memory) The interaction between them is done through memory.
According to the 8 atomic operations of the JMM memory model, each thread will add a lock instruction to lock the cache of the memory area(cache line lock) before the operation of the data is returned to the main memory. According to the MESI cache consistency protocol, the bus passes When the listener finds that the data has been modified, it will immediately invalidate the inconsistent copies in the working memory of other threads.
After the current thread writes the changed data back to the main memory, the unlock instruction is executed immediately.
At this time, other threads re-read the updated data and copy it to their working memory. The bus listening mechanism will detect the data of the thread on the bus, and when it finds that a thread has made a change and is ready to store back to the main memory, it will immediately invalidate the copy of the other thread's working memory, and then get the update from the new to the main memory. After the value.
In addition to using the volatile keyword to ensure memory visibility, using synchronized or Lock locks can also ensure the memory visibility of variables. It's just that using the volatile keyword is less expensive and is a lightweight lock.
This is the principle of memory visibility.
Q3:How does the volatile keyword guarantee order?
Modifying shared variables with the volatile keyword can prohibit instruction reordering. If you use volatile to modify shared variables, volatile uses a "memory barrier" at the bottom of the JVM to prohibit specific types of processor reordering. When the volatile keyword is added, a lock prefix instruction will be added. The lock prefix instruction is actually equivalent to a memory barrier(also known as a memory fence). The memory barrier will provide three functions:
It ensures that when the instruction is reordered, it will not arrange the instruction behind it to the position before the memory barrier, nor will it arrange the previous instruction to the memory barrier; that is, when the instruction to the memory barrier is executed, it is The previous operations have been completed;
It will force the modification operation to the cache to be written to the main memory immediately;
If it is a write operation, it will cause the corresponding cache line in other CPU to be invalid.
JMM has some innate orderliness, which can be guaranteed by the Happens-Before principle.
Q4:volatile can guarantee visibility and order, but can it guarantee atomicity? why?
The volatile keyword cannot guarantee atomicity.
a. When writing a volatile variable, JMM will force the variable in the thread's local memory to be refreshed into the main memory;
b. This write operation will invalidate the cache in other threads.
For compound operations like i++, if you want to guarantee atomicity, you can only rely on the atomic operations of AtomicInteger under synchronized, Lock, and concurrent packages. AtomicInteger encapsulates the basic data types of self-increment(addition 1 operation), self-subtraction(subtraction 1 operation), addition operation(addition of a number), and subtraction operation(subtraction of a number) to ensure that these operations are atomic operations.
Q5:Have you understood the JMM memory model? Simple talk
Looking at this picture, directly operate on Barbara!