Appendix 1 Java Memory Model and shared variable visibility, java Variables

Appendix 1 Java Memory Model and shared variable visibility, java Variables

Note: This article mainly refers to the "deep understanding of Java Virtual Machine (version 2)" and "deep understanding of Java Memory Model"

1. Java Memory Model (JMM)

The main objective of the Java memory model is to defineVariableThe underlying details such as storage to memory and getting variables from memory.

Note: The above variables refer to shared variables (instance fields, static fields, array object elements), excluding thread private variables (local variables, method parameters ), because private variables do not have competition.

1.1. The memory model is a figure:

Note:

• All shared variables are stored in the primary memory.
• Each thread has its own working memory (local memory)
• The worker memory stores the master memory copy of the variables used by this thread.

Note:

• The thread must perform operations on variables in the working memory.
• Different threads cannot directly access the variable in the working memory of the other party.
• Variable transmission between different threads must pass through the main memory

Analogy: (Note: The main memory and the working memory are only virtual concepts. The analogy below is just to help you understand. In general, you are more inclined to regard the working memory as a high-speed CPU cache)

• Primary memory: corresponds to the data section of the object instance in the Java heap (Note: Other Object Information is also saved in the heap, for example. mark Word, Klass Point, and padding data for byte padding)
• Working memory: corresponding to some areas in the stack

1.2 and 8 memory barrier commands:

The following lists only six items related to the subsequent content.

• Lock: Act on the main memory and mark a variable as a State exclusively occupied by a thread.
• Unlock: Used to unlock a locked variable.

The following four items are directly related to volatile's memory visibility (store, write, read, and load)

• Store: transfers the value of the variable in the working memory to the main memory.
• Write: Put the store operation's variable value from the working memory into the main memory variable.
• Read: transmits the value of a variable from the main memory to the working memory of the thread.
• Load: Put the variable value obtained by the read operation from the main memory into the variable in the working memory.

Note:

• A variable can be locked by only one thread at a time.
• The lock operation clears the copy of the variable in the working memory of all threads. Otherwise, the lock will fail.
• The lock operation can be performed multiple times by the same thread. When the lock is performed several times, it must be unlocked several times (reentrant locks)
• Before unlock, you must first execute store-write
• Store-write must appear in pairs (working memory --> main memory)
• Read-load must appear in pairs (Master memory --> working memory)

 

2. Visibility of variables on all threads

Visibility: thread 1's modifications to shared variables can be seen by thread 2 in a timely manner

2.1 reasons why shared variables are invisible

• The updated value of the shared variable is not updated between the active memory and the active memory.
• Thread staggered execution
• Command Re-sorting combined with thread staggered execution

2.2. Measures for timely updating shared Variables

After thread 1 modifies the shared variable, it refreshes the shared variable to the primary memory. Then thread 2 reads the shared variable from the primary memory and loads the shared variable into the working memory.

Note: In most cases, the reading and writing of variables follow the steps in the "Measures" section. However, in the case of high concurrency in a short period of time, if the following two conditions occur, thread 2 cannot read the latest value modified by thread 1,

• It may be that thread 1 has no time to fl the modified shared variable to the primary memory, and thread 2 has read the original primary memory variable to its working memory.
• Although thread 1 May fl the modified value to the main memory, the variable copy in thread 2's working memory (similar to the CPU cache) has not been refreshed by the CPU (although, CPU cache refresh will be very fast), so thread 2 still reads the variable copies cached in the original working memory.
• It is possible that thread 1 has no time to fl the modified shared variables to the primary memory. At the same time, the variable copies in thread 2's working memory (similar to the CPU cache) have not been refreshed by the CPU.

NOTE: For the above three points, I have reviewed a lot of information and consulted many experts. The opinions are not uniform !!!

2.3. Command Re-sorting:The code writing sequence is different from the actual execution sequence (the compiler or processor can optimize the program to improve)

Eg.

The code writing order is as follows:

1 int a = 12; 2 int B = 13; 3 int c = a + B;View Code

The actual code execution sequence may be as follows:

1 int B = 13; 2 int a = 12; 3 int c = a + B;View Code

Summary: This article introduces the Java memory model and some concepts of shared variable visibility to prepare for the volatile below.