Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to solve the java double check lock problem". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to solve the java double check lock problem.

The origin of double check lock

First, let's take a look at the non-thread-safe initialization singleton mode.

Public class UnsafeLazyInitialization {private static UnsafeLazyInitialization instance; public static UnsafeLazyInitialization getInstance () {if (instance = = null) {/ / 1: thread An executes instance = new UnsafeLazyInitialization () / / 2: thread B execution} return instance;}}

In the UnsafeLazyInitialization class, assume that when thread An executes to code 1 and thread B executes to code 2, thread A may see that the instance reference object has not yet been initialized.

For the UnsafeLazyInitialization class, we can synchronize the getInstance () method to achieve thread-safe delayed initialization. The example code is as follows:

Public static synchronized UnsafeLazyInitialization getInstance () {if (instance = = null) {/ / 1: thread An executes instance = new UnsafeLazyInitialization (); / / 2: thread B executes} return instance;}

Because the above code synchronizes the getInstance () method, this may increase the cost of the synchronizer. If getInstance () is called frequently by multiple threads, it will degrade the performance of the program, whereas if it is not called by multiple threads, the delayed initialization method of the getInstance () method will affect performance.

Prior to JVM 1.6, synchronized is a heavy lock, so it consumes a lot of performance, so people came up with a double check lock (Dobule-check Locking) scheme to improve performance. The sample code is as follows:

Public class DoubleCheckedLocking {/ / 1 、 private static Instance instance / / 2, public static Instance getInstance () {/ / 3, if (instance = = null) {/ / 4, First check synchronized (DoubleCheckedLocking.class) {/ / 5, yoke if (instance = = null) {/ / 6, second check instance = new Instance () / / 7. The root of the problem lies here} / / 8,}} return instance }}

As shown in the above code: if step 4, the first check that instance is not null, then there is no need to perform the following locking operation, which greatly reduces the performance problems caused by synchronized locks. There seems to be nothing wrong with the above code. 1. When multiple thread views are used to create a new object, only one thread can be guaranteed to create the object successfully through the synchronized keyword.

2. If the instance instance object has been created, get the object instance directly through the getInstatnce () method.

The problem of double check lock above

The above code looks perfect, but when performing step 4, instatnce! When = null, the reference object of instatnce may not have been initialized yet.

The root of the problem

When we execute the above code to step 7, instance = new Instance (); creates an object, which can be divided into three steps, as follows:

Memory = allocate () / / 1. Allocate the memory space memory ctorInstance (memory) / / 2, initialize the Singleton object instance = memory / / 3 on the memory allocation space memory, and set instance to point to the newly allocated memory address memory

Reordering may occur in the above three lines of code 2 and 3, and the order is executed after reordering occurs in steps 2 and 3 (on the JTI compiler)

Memory = allocate () / / 1. Allocate memory space memory instance = memory / / 3, set instance to point to the newly allocated memory address memory / / Note that the instance object has not been initialized yet, but the reference to instance is no longer null. CtorInstance (memory) / / 2, initialize the Singleton object on the memory allocated memory space memory

Let's take a look at the order of multithreading execution.

Line 7 above instance = new Instance (); if an instruction reorder occurs in thread A (2p3), it is possible for another thread B to determine that instance is not empty in four lines of code. Thread B then accesses the reference object of instance, but the instance object may not have been initialized by A. At this point, thread B may access an object that has not been initialized, resulting in a null pointer error.

Problem solving

1. 2 and 3 are not allowed to rearrange instructions. 2. 2 and 3 are allowed to reorder, but other threads are not allowed to see the reorder

Solution based on volatile

Based on the above code, you only need to add the volatile keyword to the instance declaration, as follows

Public class DoubleCheckedLocking {/ / 1 、 private static volatile Instance instance / / 2, public static Instance getInstance () {/ / 3, if (instance = = null) {/ / 4, First check synchronized (DoubleCheckedLocking.class) {/ / 5, yoke if (instance = = null) {/ / 6, second check instance = new Instance () / / 7. The root of the problem lies here} / / 8,}} return instance }} Thank you for your reading. The above is the content of "how to solve the problem of java double-checked lock". After the study of this article, I believe you have a deeper understanding of how to solve the problem of java double-checked lock, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.