preface

After a year of self-learning JAVA Abba Abba, she finally got an interview. The interviewer asked her to talk about her understanding of CAS.

Go back and wait for notice.

If you are completely unfamiliar with CAS, you are advised to read relevant blogs first to understand the basic principles, and then how to answer the questions during the interview

Interviewer: Do you know anything about CAS? Can you talk about it?

Abba Abba: Know something about it. CAS stands for Compare And Swap.

Abba ABba: The idea of CAS is relatively simple. It mainly involves three values: the current memory value V, the expected memory value (the old memory value)O, and the memory value U to be updated. The memory value V is changed to the updated memory value U and returns true if and only if the expected memory value O is equal to the current memory value V, otherwise returns false.

Interviewer: Anything else? Do you know the usage scenarios of CAS?

Abba Abba: Uh… It should be almost done. CAS seems to have been used in the package

Interviewer: Ok, what are the disadvantages of CAS?

Abba Abba: Err…. Good.. There seems to be an ABA problem, which seems to be solved with an atom stampedreference

Interviewer: Are there any other disadvantages?

Abba Abba: Uh… I can’t remember clearly….

Interviewer: ok, that you go back to wait for notice 😈

Abba Abba: Ok

To receive an offer on the spot

Interviewer: Does CAS know about it? Tell me about

Abba Abba: CAS stands for Compare and Swap.

Abba ABba: The idea of CAS is relatively simple. It mainly involves three values: the current memory value V, the expected memory value (the old memory value)O, and the memory value U to be updated. If and only if the expected memory value O is equal to the current memory value V, the memory value V is changed to the updated memory value U, returning true, otherwise returning false.

Abba Abba: CAS is mainly used as an optimistic locking solution in scenarios that require locking. It is generally used in simple operations that require locking but do not want to introduce locking.

Abba Abba: There are three main problems with CAS: ABA problem, spin cost, CAS can only be univariate

Interviewer: Can you elaborate on these three questions?

Abba abba: ABA problem refers to A thread t1 for CAS procedures, other threads t2 variable A to B, then to A, this time t1 found A does not change, so the switching operation, because before the exchange of operation for variable is actually A has change, finally only change back to A again, this is not A, A, Switching operations at this point can be problematic in some business scenarios, and there are two solutions to the ABA problem.

Abba Abba: Solution 1: Add a version number to a variable when operating on it. Each operation on a variable increases the version number by 1, which is commonly seen in optimistic locks in databases.

Scheme 2: Java provides a corresponding atom reference class AtomicStampedReference, which avoids the ABA problem by stamping the version of the object mark by wrapping a tuple of [E,Integer].

Abba Abba: Spin cost CAS spin can be expensive for the CPU if it is unsuccessful for a long time

Abba Abba: Solution: 1. Break the for loop at the code level and set the appropriate number of loops. Use the JVM to support the processor-provided pause instruction, which can delay pipeline execution and avoid consuming too many CPU resources.

For a shared variable, you can use CAS to ensure atomic operations, but for multiple shared variables, you cannot use CAS to ensure atomicity. Since JDK1.5, the AtomicReference class has been provided to ensure atomicity before referencing objects, allowing multiple variables to be placed in an object for CAS operations.

Abba Abba: Java.util.concurrent (JUC) added in JDK1.5 is built on CAS. CAS is an optimistic lock that is suitable for read/write scenarios.

The interviewer saw a ba a ba answer like flow, decided to embarrass her

Interviewer: Do you know JMM? Tell me about JMM.

Abba Abba: Yes, the JMM is the JAVA Memory Model. The purpose of the JMM is to mask differences in Memory access between hardware and operating systems so that JAVA programs access Memory consistently across platforms.

Abba Abba: Not only that, but the JMM also specifies that all variables are stored in main memory, and that each thread has its own workspace. The thread must first read variables from main memory into its own working memory and then operate on them, and finally write back to main memory.

JAVA defines eight operations that are atomic: Lock, unlock, Read, Load, Use, assign, Store, and write

Interviewer: Good, good. Is the JMM real, the same as the JVM memory model?

Abba Abba: It is not real, the JMM is just a model, the real implementation may be different from the model. JMM and JVM are not the same, they are not the same level of division, basically have no relationship.

The heap and method areas are shared by threads, while the virtual machine stack, local method stack, and program counters are thread private

The program counter is the only one of these areas where OOM will not occur

Interviewer: Not bad. Why don’t you tell me about Volatile

Abba abba: Volatile is arguably the lightest synchronization mechanism provided by the JAVA Virtual Machine. When a variable is Volatile, it has two properties. The first is that it is visible to all threads. However, there are thread-safety issues when multiple threads operate on volatile variables concurrently. This is because volatile variables are not consistent across thread working memory, but because each use is flushed, inconsistencies are invisible to the execution engine.

Abba Abba: The second property of Volatile variables is that they prohibit instruction reordering optimization. Normal variables only ensure that the correct result is obtained at all dependent assignments during the execution of the method. There is no guarantee that the order of assignment is the same as the order of writing in the code. For example, the following singleton pattern for DCL.

public class Instance { private String str = ""; private volatile static Instance ins = null; /** * private Instance(){STR = "hi"; } @return */ public static Instance getInstance(){if (ins == null){synchronized (instance.class){if (instance.class){synchronized (instance.class){if (instance.class) (ins == null){ ins = new Instance(); } } } return ins; }}Copy the code

Abba abba: If the INS variable is not volatile, then the JVM may run out of order when thread A initialses ins = new Instance() after it has acquired the inster.class lock. If (ins == null) is true, the instance. class lock must be acquired and wait for initialization. However, if thread A does not complete the initialization of INS, such as allocating space, object construction is not complete, but has returned the reference, then thread B will get an incomplete instantiation of the object, and an exception will occur. With volatile, references to instances that have not been initialized are not published, preventing exceptions.

Interviewer: Good. You’ve got a solid grasp of this area. You can start tomorrow.

Abba Abba: Ok 😈

/ Thanks for your support

That is all the content of this sharing. I hope it will help you

Don’t forget to share, like and bookmark your favorite things

Welcome to the public number programmer bus, from byte, shrimp, zhaoyin three brothers, share programming experience, technical dry goods and career planning, help you to avoid detours into the factory.