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

This article mainly introduces "how to understand the order in the weird concurrency of Java". In the daily operation, I believe that many people have doubts about how to understand the order in the weird concurrency of Java. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand the order in Java weird concurrency". Next, please follow the editor to study!

The exposition of order and order

Why does order need to be discussed? Because Java is object-oriented programming, it only focuses on the final results, and rarely studies its specific implementation process. As described in the previous article when introducing visibility, when the operating system converts the Java language into a machine language in order to improve performance, it instructs the compiler to make certain changes to the execution order of the statements to optimize system performance. So in many cases, accessing a program variable (object instance fields, class static fields, and array elements) may be executed in a different order rather than in the order specified by the program semantics.

As we all know, the Java language runs in the JVM (Java Virtual Machine) environment that comes with Java. When the execution order of the source code (.class) in the JVM environment is inconsistent with the program execution order (runtime), or the program execution order is inconsistent with the compiler execution order, we say that reordering occurs in the process of program execution.

This modification of the compiler thinks it can guarantee the final running result! Because there is no problem in the single-core era, but with the advent of the multi-core era, in a multi-threaded environment, this optimization meets thread switching, which greatly increases the probability of accidents!

Good intentions do bad things!

In other words, orderliness means that in the code order structure, we can intuitively specify the order in which the code is executed, that is, from top to bottom. But compilers and CPU processors reorder the order in which the code is executed according to their own decisions. Optimize the execution order of instructions, improve the performance and execution speed of the program, change the execution order of statements and reorder, but the final result does not seem to change (single core).

The orderliness problem refers to the problem that in a multi-threaded environment (multi-core), after the reordering of the execution statement, this part of the reorder is not executed together, and then it is switched to another thread, resulting in a problem that the result is not as expected. This is the problem of program order caused by compiler optimization to concurrent programming.

It is shown in the diagram:

A fan summary: compilation optimization ultimately leads to ordering problems.

First, the reasons for order:

If a thread writes a value to field an and then writes a value to field b, and the value of b does not depend on the value of a, the processor is free to adjust their execution order. and the buffer can flush the value of b to main memory before a. At this point, the problem of order may arise.

Example:

1import java.time.LocalDateTime; 2 3 public static void main * 4 * @ author: mmzsblog 5 * @ description: ordering problems in concurrency 6 * @ date: 15:22:05 February 26, 2020 7 * / 8public class OrderlyDemo {9 10 static int value = 1; 11 private static boolean flag = false; 12 13 public static void main (String [] args) throws InterruptedException {14 for (int I = 0; I < 1999; iTunes +) {15 value = 1 16 flag = false; 17 Thread thread1 = new DisplayThread (); 18 Thread thread2 = new CountThread (); 19 thread1.start (); 20 thread2.start (); 21 System.out.println ("= ="); 22 Thread.sleep (6000) 23} 24} 25 26 static class DisplayThread extends Thread {27 @ Override 28 public void run () {29 System.out.println (Thread.currentThread (). GetName () + "DisplayThread begin, time:" + LocalDateTime.now ()); 30 value = 1024; 31 System.out.println (Thread.currentThread (). GetName () + "change flag, time:" + LocalDateTime.now ()); 32 flag = true 33 System.out.println (Thread.currentThread () .getName () + "DisplayThread end, time:" + LocalDateTime.now ()) 34} 35} 36 37 static class CountThread extends Thread {38 @ Override 39 public void run () {40 if (flag) {41 System.out.println (Thread.currentThread () .getName () + "value is:" + value + ", time:" + LocalDateTime.now ()) 42 System.out.println (Thread.currentThread (). GetName () + "CountThread flag is true, time:" + LocalDateTime.now ()); 43} else {44 System.out.println (Thread.currentThread (). GetName () + "value is:" + value + ", time:" + LocalDateTime.now ()) 45 System.out.println (Thread.currentThread (). GetName () + "CountThread flag is false, time:" + LocalDateTime.now ()); 46} 47} 48} 49}

Running result:

It can be seen from the print that reordering must have occurred when the DisplayThread thread was executed, resulting in first assigning a value to flag, and then switching to the CountThread thread, which led to the printing of a value value of 1 true, and then assigning a value to value; but the reason for this is that there is no connection between the two assignment statements, so the compiler may reorder instructions when compiling the code.

With the illustration, it is:

Second, how to solve the problem of order

2.1 、 volatile

The underlying layer of volatile uses a memory barrier to ensure orderliness (a technique for making states (variables) in one CPU cache visible to other CPU caches).

The volatile variable has a rule that refers to the write operation to a volatile variable, and the Happens-Before reads to the volatile variable later. And this rule is transitive, that is to say:

At this point, we use the volatile keyword to modify the variable flag, such as:

1 private static volatile boolean flag = false

At this point, the meaning of the variable is as follows:

In other words, as long as you read flag=true;, you can read value=1024;. Otherwise, you can read the initial state of flag=false; and value=1 that has not been modified.

But there may also be atomicity problems caused by thread switching, that is, reading flag=false; and value=1024; friends who read the last article on [atomicity] () may immediately understand that this is caused by thread switching.

2.2, lock

Here we directly use the Java language built-in keyword synchronized to lock parts that may be reordered so that they do not appear to be reordered macroscopically or in terms of execution results.

The code modification is also simple, as long as you modify the run method with the synchronized keyword, as follows:

1 public synchronized void run () {2 value = 1024; 3 flag = true; 4}

By the same token, since it is locked, of course, Lock can also be used, but Lock must require the user to release the lock manually. If the lock is not released actively, it may lead to deadlock. You must pay attention to this when you use it!

It is also easy to lock in this way, and the code is as follows:

1 readWriteLock.writeLock (). Lock (); 2 try {3 value = 1024; 4 flag = true; 5} finally {6 readWriteLock.writeLock (). Unlock (); 7} at this point, the study on "how to understand order in Java weird concurrency" is over, hoping to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.