Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the visibility of the Java memory model and thread safety. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

Java memory model VS JVM runtime data area

First of all, the Java memory model (JMM) and the JVM runtime data area are not the same thing. Many articles on the Java memory model describe heaps, method areas, Java virtual machine stacks, local method stacks, and program counters, which are not the contents of the Java memory model but the contents of the JVM runtime data area.

To understand the difference between the two, you need to understand the Java Virtual Machine Specification and the Java language Specification. We know that there are not only Java languages on Java virtual machines, such as JRuby, Scala,Kotlin,Groovy, etc., all run on Java virtual machines. If these languages want to run on Java virtual machines, they have to comply with the Java virtual machine specification, and the JVM runtime datazone is the content of the Java virtual machine specification. The "Java language specification" is only a specification for the Java language, which makes a detailed description of the Java memory model.

What is the Java memory Model (JMM)?

To understand the Java memory model, we must first understand what the memory model is. Between the CPU cache and the memory barrier, we learn about cache consistency and processor-optimized instruction reordering. In order to ensure that atomicity, visibility and order can be satisfied in concurrent programming. There is an important concept, that is, the memory model. It solves the memory access problems caused by CPU multi-level cache, processor optimization and instruction rearrangement, and ensures consistency, atomicity and order in concurrent scenarios. The Java memory model is a specification to solve the problems caused by the inconsistency of local memory data, the reordering of code instructions by the compiler and the out-of-order execution of the code by the processor when multi-threads communicate through shared memory. The goal is to ensure atomicity, visibility, and order in concurrent programming scenarios.

The Java memory model can be divided into a thread stack (or working memory, which is unique to each thread) and a heap (or main memory, which is not the same concept as the heap of the JVM runtime data area, which is shared by threads). The general logic diagram is as follows:

Specific content Shared Variables definition in JMM

Memory that can be shared between threads is called shared memory or heap memory

All instance fields, static fields and array elements are stored in shared memory, and these fields and arrays are shared variables

Conflict: if at least one access is a write operation, then two accesses to the same variable conflict

These shared variables that can be accessed by multiple threads are objects specified by the memory model.

Inter-thread operation

Inter-thread operation means that the operations performed by one thread can be perceived or directly affected by other threads.

The Java memory model only describes inter-thread operations, not intra-thread operations, which are executed according to intra-thread semantics.

The inter-thread operations are:

Read operation (general read, that is, non-volatile read)

Write operation (general write, that is, non-volatile write)

Volatile read

Volatile write

Lock,Unlock

The first and last operations of the thread

External operation

Definition of synchronization rules

Write to the volatile variable V, synchronized with subsequent reads of V by all other threads

Unlocking for monitor m and locking synchronization for m for all subsequent operations

Write default values for each attribute (0recently false, null) synchronized with the operations performed on it by each thread

The operation of the startup thread is synchronized with the first operation in the thread

The last operation of thread T2 and thread T1 found that T2 has ended synchronization.

If thread T1 interrupts T2, the interrupt operation of thread T1 is found to be out of sync with all other threads.

Principle of prior occurrence of happens-before

The happens-before relationship is used to describe the order between two conflicting actions. If one action happens before another action, the first operation is visible to the second operation, and JVM needs to implement the following happens-before rules:

Each action in a thread happens-before the actions that follow that action in that thread

Unlock actions in a pipe happens-before subsequent lock operations on the same pipe

Write to a volatile field happens-before each subsequent read to that volatile field

Any action of a started thread that calls the start () method happens-before on an object

If t2.join () is successfully executed in thread T1, all operations in T2 are visible to T1

If an action a happens-before action b and b happens-before action c, then a happens-before c

The processing of final in JMM

Final sets the object's field in the object's constructor, and when the thread sees the object, it will always see the correct constructed version of the object's final field. If reading occurs after the field is set in the constructor, you will see the value assigned by the final field, otherwise it will see the default value. Before reading the final member variable of the object, read the shared object.

Fields that are usually modified by static final cannot be modified. However, System.in, System.out, and System.err can be modified by static final. Legacy problems must be changed through the set method. We call these fields write protection to distinguish them from ordinary final fields.

Word Tearing byte processing

Some processors, especially early Alphas processors, do not provide the ability to write a single byte. To update the byte array on such a processor, it would be illegal to simply read the entire contents, update the corresponding bytes, and then write the whole contents back to memory. This problem is sometimes called "word tearing", and processors that are difficult to update bytes need to find other ways to solve it. Therefore, programmers need to be careful not to reassign elements in byte [], let alone in multithreading.

Visibility issu

Visibility: it mainly means that the writing of one thread to the shared variable can be read by another thread, that is, the operation of one thread on the shared variable is visible to another thread.

The visibility problem refers to the result that one thread writes to the shared variable while other threads cannot read it. According to the following working memory cache model, we can know that the visibility problem is mainly caused by two aspects. One is that the data is only written to the cache but not to the main memory. One is that when the data is read, it is only read from the cache but not from the main memory.

Solution to the visibility problem-volatile keyword

The volatile keyword ensures that a thread can modify a shared variable and be seen by other threads in a timely manner.

According to the happen before and synchronization principles in JMM:

Write to a volatile field happens-before each subsequent read to that volatile field

Write to the volatile variable V, synchronized with subsequent reads of V by all other threads

To meet these conditions, the volatile keyword has the following functions:

Disable caching, and add an ACC_VOLATILE to the access controller of the volatile variable, which is described as "cannot be cached" in the Java Virtual Machine Specification.

Do not reorder instructions related to volatile variables

The above is the Java memory model and thread safety visibility issues shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.