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

This article mainly explains "how to understand the usage scenario and principle of volatile keyword". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to understand the usage scenario and principle of volatile keyword".

1. Memory working model of Java thread

Under the current Java memory model (after JVM 1.2), threads can store variables in local memory (such as machine registers) instead of reading and writing directly in main memory. As shown in the figure:

1.1 Let's look at an example

When signal is false, the run method terminates. Whether the appeal code can achieve the effect we want.

Let's take a look at the implementation results:

Analysis:

From a horizontal point of view, thread An and thread B seem to be communicating implicitly by sharing variables. If thread A does not notify thread B in time after the update, and thread B reads out-of-date data. That is, the situation of alleviating data inconsistency occurs.

How to solve?

It can be solved through the synchronization mechanism (controlling the relative order of operations between different threads) or through the volatile keyword so that each volatile variable can be forced to be flushed to main memory, so that it is visible to each thread. Volatile is lighter and has better performance than the synchronization mechanism.

Modify the code:

We can get the results we want:

Second, the underlying principle of volatile

Volatile in terms of memory semantics:

When writing a volatile variable, JMM flushes the shared variables in the local memory corresponding to the thread to the main memory

When reading a volatile variable, the thread then reads the shared variable from main memory.

What is the underlying implementation principle?

2.1First, check the bytecode (javac\ javap)

And then compiled into assembly language (hsdis)

Java-XX:+UnlockDiagnosticVMOptions-XX:+PrintAssembly SingleInstance

Relatives really do not understand, can only through the comparison of the key word volatile and no difference.

You can find a lot of extra lock addl.

What is this?

2.2 memory barrier

Memory barrier (Memory Barrier) and memory fence (what intel calls Memory Fence) are the same concept but different names. You can prevent certain types of processors from reordering by inserting memory barrier instructions.

The underlying implementation of volatile is by inserting a memory barrier, and JMM adopts a conservative strategy. As follows:

Insert a StoreStore barrier in front of each volatile write

Insert a StoreLoad barrier after each volatile write operation

Insert a LoadLoad barrier after each volatile read operation

Insert a LoadStore barrier after each volatile read operation

The StoreStore barrier ensures that all previous ordinary writes are flushed to main memory before volatile is written.

The function of the StoreLoad barrier is to prevent reordering of volatile writes and possible volatile read / write operations that follow

The LoadLoad barrier is used to prevent the processor from reordering the upper volatile reads with the following normal reads.

The LoadStore barrier is used to prevent the processor from reordering the upper volatile reads with the following ordinary writes.

2.3 instruction reordering

Compilers and processors often reorder instructions in order to improve performance when executing programs.

The purpose of instruction reordering is to improve performance. Instruction reordering only ensures that the final execution result will not be changed under single thread, but can not guarantee the execution result under multi-thread.

From the java source code to the sequence of instructions actually executed, there are three kinds of reordering:

The above 1 belongs to compiler reordering, and 2 and 3 belong to processor reordering. All of these reordering can cause memory visibility problems in multithreaded programs.

For compilers, JMM's compiler reordering rules prohibit specific types of compiler reordering (not all compiler reordering is prohibited).

For processor reordering, JMM's processor reordering rules require the java compiler to insert specific types of memory barrier instructions when generating instruction sequences, using memory barrier instructions to prohibit specific types of processor reordering (not all processor reordering is prohibited).

JMM is a language-level memory model that ensures consistent memory visibility for programmers by prohibiting specific types of compiler reordering and processor reordering on different compilers and different processor platforms.

2.4 closely related happens-before rules for programmers

Starting with JDK5, java uses the new JSR- 133 memory model (unless otherwise noted in this article, it is for the JSR- 133 memory model). JSR-133 uses the concept of happens-before to illustrate memory visibility between operations. In JMM, if the result of one operation needs to be visible to another operation, then there must be a happens-before relationship between the two operations. The two operations mentioned here can be either within one thread or between different threads.

Program order rules:

Each operation in a thread, happens- before any subsequent operations in that thread.

Monitor lock rules:

Unlock a monitor lock, and happens- before then adds the lock to the monitor lock.

Volatile variable rule: write to a volatile domain, happens- before any subsequent reads to that volatile domain.

Transitivity:

If A happens- before B, and B happens- before C, then A happens- before C.

As shown in the figure above, a happens-before rule usually corresponds to multiple compiler and processor reordering rules. For java programmers, happens-before rules are easy to understand and prevent java programmers from learning complex reordering rules and their implementation in order to understand the memory visibility guarantees provided by JMM.

2.5 Let's look at an example-- a single case of double detection.

Is there something wrong with this singleton code?

Analysis:

Instance = new TestInstance (); can be decomposed into 3 lines of pseudo code

Suppose thread An executes to step 3 and the compiler rearranges instructions to Step a-c-b, just after thread An executes Step c, and then thread B executes to step 1. Let's see what happens?

Thread B determines that instance==null is false and returns instance; directly while instance only executes Step C. instance= memory / / sets instance to point to the address just assigned, and the object in the memory address has not yet been initialized.

To solve this problem, modify the code to:

Private volatile static SingleInstance instance = null

Can volatile guarantee atomicity?

Take a look at the following description: "the volatile variable is immediately visible to all threads, and all writes to the volatile variable are immediately reflected in other threads. In other words, the volatile variable is consistent across threads, so operations based on volatile variables are safe in concurrency."

The argument part of this sentence is not wrong, but it does not conclude that operations based on volatile variables are safe in concurrency.

There is no consistency problem of volatile variable in the working memory of each thread, but the operation in Java is not atomic, and volatile can not guarantee atomicity, so the operation of volatile variable is also unsafe under concurrency. We can explain why through a simple demonstration. Please see the following example.

Output result:

Why is this happening? let's analyze it again:

And look at the bytecode of this code:

We simply summarize id++ into three operations:

1. Read the value of the variable id;-- volatale ensures that this is consistent with the main memory

two。 Add 1 to the value of the variable id

3. The calculated value is then assigned to a reference to the variable id.

Among them, 2 and 3 cannot be thread-safe.

To ensure atomicity, please synchronize mechanism can be used. The following is an atomic data structure AtomicInteger.

At this point, I believe you have a deeper understanding of "how to understand the use of the volatile keyword and its principle". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.