Netty Concurrent Programming Practice 2:volatile the correct use of __ programming

For a long time, there has been a lot of controversy about how to use the volatile correctly, even some experienced Java designers, the understanding of volatile and multithreaded programming is still mistaken. In fact, the use of volatile is very simple, as long as the understanding of the Java memory model and the basic knowledge of multithreaded programming, the correct use of volatile is not a problem. Below we combine the source code of Netty, the correct use of volatile is explained.

With the Nioeventloop code open, let's look at the ioratio that controls I/O operations and other task-run proportions, which are variables of type int, defined as follows.

We found that it was defined as volatile, for what? We first describe the volatile keyword, and then combine the Netty code for analysis.

The keyword volatile is the most lightweight synchronization mechanism provided by Java, and the Java memory model specifically defines some special access rules for volatile. Now let's look at its rules.

When a variable is volatile modified, it will have the following two characteristics.

Thread Visibility: When a thread modifies a variable that is volatile decorated, the other thread can immediately see the latest changes, regardless of whether it is locked or not, and the normal variable does not.

Prevents command reordering optimizations, and ordinary variables only ensure that the correct results are obtained in all places that rely on assignment results during the execution of the method, and that the order of the variable assignment operations is consistent with the execution order of the program code. Give a simple example to illustrate the order reordering optimization problem, as shown in Figure 21-5.

Figure 21-5 Instruction reordering and optimizations cause threads to not exit

We expect the program to stop after 3s, but it's actually going to go on and on, because the virtual machine is ordering and optimizing the code, and the following instructions are optimized.

if (!stop)

while (true)

......

The reordering code cannot discover that the stop was modified by the main thread and therefore cannot be stopped. To resolve this problem, simply add the volatile modifier before the stop. The code is modified as shown in Figure 21-6.

Run again, we found that after 3s program exit, to achieve the desired effect, using volatile to solve the following two problems.

The main thread's modification of the stop is visible in the workthread thread, meaning that the workthread thread immediately sees other threads modifying the stop variable.

Suppresses instruction reordering, preventing concurrent access logic confusion caused by reordering.

Some people think that it is wrong to use volatile instead of traditional locks to promote concurrent performance. Volatile only solves the problem of visibility, but it does not guarantee mutual exclusion, that is to say, multiple threads can still create multithreaded problems when they modify a variable concurrently. Therefore, we cannot rely on volatile to completely replace the traditional locks.

Figure 21-6 Volatile solve instruction reordering and compile optimization problems

According to experience, volatile is best suited to use a thread write, other thread read the occasion, if there are multiple threads concurrent write operations, still need to use a lock or thread-safe container or atomic variables to replace.

After talking about the principle of volatile, we continue to analyze the source code of Netty. It says Ioratio is defined as volatile, so let's see why the code defines it. See the code shown in Figure 21-7.

Figure 21-7 Application of volatile in Nioeventloop thread

Through code Analysis we found that in the Nioeventloop thread, Ioratio was not modified, it was read-only. Since there is no modification, why should it be defined as volatile? Continuing to look at the code, we found that Nioeventloop provides a common way to reset the scale of I/O execution time, as shown in Figure 21-8.

Figure 21-8 Modifying the volatile variable

First, the Nioeventloop thread does not call the method, which means that scaling the I/O execution time is an externally initiated operation, usually by a business thread calling the method and then setting the parameter again. This creates a thread-write, one-thread read. Based on the previous application summary for volatile, you can use volatile instead of the traditional synchronized keyword to promote concurrent access performance. Netty use of volatile to modify member variables, if you understand the volatile of the application scenario, read Netty volatile code is relatively easy.