Heroes of the world! Step on the seven colors cloud to explain Java thread safety

Codeegg’s 764th tweet

What is a thread

According to the description of the operating system, the thread is the smallest unit of CPU scheduling, intuitively speaking, the thread is the code in order to execute down, the execution of the end of a line.

For example 🌰, an assembly shop at Futukang is equivalent to a CPU, and threads are the current assembly line. In order to improve productivity and efficiency, workshops generally have multiple assembly lines operating at the same time. Also in our Android development multithreading can be seen everywhere, such as the execution of time-consuming operations, network requests, file read and write, database read and write, and so on will open a separate child thread to execute.

So is your thread safe? What is the principle of thread safety? (The content of this article is a summary of personal learning, if there are mistakes, please pat and correct them.)

Thread safety

Before we look at thread safety, let’s look at Java’s memory model and understand how threads work.

Java Memory Model – JMM

What is the JMM? JMM(Java Memory Model), is based on`Computer memory model (a specification that defines the read and write behavior of multithreaded programs in a shared memory system)`A mechanism and specification that shields access differences between hardware and operating systems and ensures consistent access to memory by Java programs on various platforms. Ensure shared memoryatomic,visibility,order.

Where you can use graphs, try not to talk nonsense. Let’s take a look at a picture:

The figure above depicts a multithreaded execution scenario. Thread A and thread B respectively read and write to variables in main memory. The variable in the main memory is a shared variable, that is, this variable is only one copy, shared between multiple threads. Each thread has its own working memory. To read or write a shared variable of the main memory, the thread must first copy the variable to its own working memory and then perform all operations on the variable in its own working memory. The thread working memory needs to synchronize the results to main memory after completing operations on the variable copy.

Thread working memory is thread private memory. Threads cannot access each other’s working memory.

To make it easier to understand, use a diagram to describe the process by which a thread assigns a value to a variable.

So how does the thread working memory know when and how to synchronize data to main memory? This is where JMM comes in. The JMM specifies when and how to synchronize data between thread working memory and main memory.

Have a preliminary understanding of JMM, a brief summary of atomicity, visibility, order

Atomicity:

Operations on shared memory must either be performed to the end of the execution without interruption by any external factors, or not be performed at all.

Visibility:

When multiple threads operate the shared memory, the execution results can be synchronized to the shared memory in a timely manner, ensuring that other threads can see the results in a timely manner.

Order:

In a single-threaded environment, the execution of the program is orderly, but in a multi-threaded environment, the compiler and processor will rearrange the instructions for performance optimization, and the execution of the program will become disordered.

This brings us to the topic of this article: Thread safety.

The nature of thread safety

The problem with the first example is that variables in main memory are shared and accessible to all threads, while thread working memory is thread private and not accessible to each other. In A multi-threaded scenario, if thread A and thread B operate on the same variable in shared memory at the same time, the variable data in main memory will be corrupted. This means that this variable in main memory is not thread-safe. Let’s look at a little code example to help you understand.

public class ThreadDemo {  private int x = 0;  private void count() {    x++;  }  public void runTest() {    new Thread() {      @Override      public void run() {        for (int i = 0; i < 1_000_000; i++) {         count();        }            System.out.println("final x from 1: " + x);       }        }.start();      new Thread() {      @Override      public void run() {        for (int i = 0; i < 1_000_000; i++) {             count();        }         System.out.println("final x from 2: " + x);        }      }.start();   }  public static void main(String[] args) {    new ThreadDemo().runTest();  }}Copy the code

Copy the code

The runTest method in the example code has two threads each executing the 1_000_000 count() method. The count() method only performs the simple X ++ operation. In theory, one thread each executing the runTest method should produce an x result of 2_000_000. But the actual result is not what we thought:

final x from 1: 989840final x from 2: 1872479Copy the code

Copy the code

I ran it 10 times, and one thread output x with a value of 2_000_000 only happened 2 times.

final x from 1: 1000000final x from 2: 2000000Copy the code

Copy the code

The reason for this result is what we said above. In a multi-threaded environment, the x variable in our main memory is corrupted. We all know that completing i++ once is equivalent to executing:

int tmp = x + 1; x = tmp;Copy the code

Copy the code

Int TMP = x + 1; This line of code causes a thread switch, and when the thread cuts back again, x will be assigned repeatedly, resulting in the above run result, where neither thread can output 2_000_000.

The following diagram depicts the execution sequence of the sample code:

So how does Java solve these problems to ensure thread-safety and atomicity, visibility, and orderliness of shared memory?

Thread synchronization

Java provides a series of keywords and classes to ensure thread-safety

One: Synchronized

1. Ensure atomicity of method or code block operations

Synchronized guarantees mutually exclusive access to resources (data) within a method or code block. Namely, at the same time, by the same Monitor (Monitor) (https://www.hollischuang.com/archives/2030) monitoring code, there can be at most one thread during a visit.

To learn more about the implementation principles of Monitor and Synchronized, read these two articles: The implementation principles of Synchronized and Moniter

Without further ado, here’s a GIF describing how Monitor works:

Methods or code blocks described by Synchronized keyword can only be accessed by one thread at a time in a multi-threaded environment. Before the execution of the thread holding the current Monitor is completed, other threads that want to call relevant methods must queue up until the execution of the thread holding the current Monitor is completed. Release Monitor so that the next thread can obtain Monitor execution.

If there are multiple monitors, they are not mutually exclusive.

Synchronized can specify a custom Monitor when describing a code block. The default value is this, that is, the current class.

2. Ensure visibility of monitoring resources

Ensure data synchronization of monitored resources in a multi-threaded environment. That is, any thread will copy the data in the shared memory to its own cache for the first time after acquiring Monitor. The first time any thread releases Monitor, it copies data from the cache to shared memory.

3. Ensure the order of operations between threads

The atomicity of Synchronized ensures that the methods or code operations described by Synchronized are ordered and can only be accessed by at most one thread at a time, without triggering the JMM instruction rearrangement mechanism.

2:The Volatile keyword

Ensure visibility and order for operations on variables described by the Volatile keyword (disallow instruction reordering)

Note: 1.Volatile only applies to assignment of primitive types (byte, char, short, int, long, float, double, Boolean) and to reference assignment of objects. 2 for compound operations such as i++, Volatile does not guarantee orderliness and atomicity. 3. Volatile is lighter than Synchronized.

Three:java.util.concurrent.atomic

Java. Util. Concurrent. Atomic package provides a series of AtomicBoolean, AtomicInteger, AtomicLong class. Using these classes to declare variables ensures that operations on them are atomic and thread-safe.

Implementation principle and Synchronized using the Monitor (Monitor) ensure that block the mutually exclusive access to different resource in a multithreaded environment, Java. Util. Concurrent. The atomic package under the atomic classes based on the principle of CAS (CompareAndSwap) operation.

CAS, also known as lock-free operation, is an optimistic locking policy. The principle is that in a multi-threaded environment, threads accessing shared variables will not be locked, blocked, and queued, and threads will not be suspended. In layman’s terms, the comparison loop continues, and if there are access conflicts, retry until there are no conflicts.

Four:Lock

Lock is also an interface under the java.util.Concurrent package, which defines a series of Lock operations. The Lock interface mainly has already, ReentrantReadWriteLock ReadLock, ReentrantReadWriteLock. WriteLock implementation class. Different from Synchronized, Lock provides interfaces related to Lock acquisition and Lock release, which makes use more flexible and can also perform more complex operations, such as:

ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); Lock readLock = lock.readLock(); Lock writeLock = lock.writeLock(); private int x = 0; private void count() { writeLock.lock(); try { x++; } finally { writeLock.unlock(); }}private void print(int time) { readLock.lock(); try { for (int i = 0; i < time; i++) { System.out.print(x + " "); } System.out.println(); } finally { readLock.unlock(); }}Copy the code

The following two articles are recommended for the implementation principle and more detailed use of Lock:

The use of the Lock to Lock (https://juejin.cn/post/6844903583616335885)
The Lock Lock source code analysis (https://juejin.cn/post/6844903639773872142)

conclusion

Causes of thread-safety issues: In multiple threads concurrent environment, multiple threads access the same Shared memory resources together, one of the threads on the halfway to the resources to write (write into the already, but haven’t end), other threads on this wrote half of the resources of the read operation, or to the wrote half of the resources of the write operation, lead to this resource data error.
How can I avoid thread safety issues?

Ensure that shared resources can only be operated on by one thread at a time (atomicity, orderliness).
Refresh the results of thread operations in a timely manner to ensure that other threads can immediately obtain the latest modified data (visibility).

Recent Articles:

Animation explains TCP, do not understand please hit me
I haven’t worked overtime since I switched to Android Tools
Interesting diagrams: diagrams that programmers understand

Question of the day:

Which scenarios at work are thread-safe?

Exclusive upgrade community: I Finally Figured it out