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

This article focuses on "how to write the singleton mode to ensure thread safety". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to write the singleton mode to ensure thread safety.

How to write the singleton pattern correctly

Singleton patterns are the easiest to understand and the easiest to write code in a design pattern. But there are many holes in them, so they are often tested as interview questions. This paper mainly collates several single-case writing methods and analyzes their advantages and disadvantages. Many of them are platitudes, but if you don't know how to create a thread-safe singleton or what a double check lock is, this article may help you.

1. Lazy load thread is not safe

When asked to implement a singleton pattern, many people's first reaction is to write the following code, including what we are taught in textbooks.

Public class Singleton {private static Singleton uniqueInstance; private Singleton () {} public static Singleton getInstance () {if (uniqueInstance = = null) {uniqueInstance = new Singleton ();} return uniqueInstance;}}

This code is simple and straightforward, and uses lazy loading mode, but there are fatal problems. When multiple threads call getInstance () in parallel, multiple instances are created. In other words, it does not work properly in multithreading.

two。 Lazy load thread safety

To solve the above problem, the easiest way is to set the entire getInstance () method to synchronized.

Public static synchronized Singleton getInstance () {if (uniqueInstance = = null) {uniqueInstance = new Singleton ();} return uniqueInstance;}

Although it is thread-safe and solves the problem of multiple instances, it is not efficient. Because only one thread can call the getInstance () method at any one time. But synchronization is needed only on the first call, that is, when the singleton instance object is created for the first time. This leads to the double check lock.

3. Double check locked thread safety

Double check locking mode (double checked locking pattern) is a method of locking using synchronous blocks. Programmers call it a double-checked lock because there are two checks uniqueInstance = = null, once outside the synchronization block and once inside the synchronization block. Why check again in the synchronization block? Because multiple threads may enter the if outside the synchronization block together, multiple instances will be generated without secondary verification within the synchronization block.

Public static Singleton getSingleton () {if (uniqueInstance = = null) {/ / Single Checked synchronized (Singleton.class) {if (uniqueInstance = = null) {/ / Double Checked uniqueInstance = new Singleton ();} return uniqueInstance;}

This code looks perfect, but unfortunately, there is something wrong with it. It mainly lies in the sentence uniqueInstance = new Singleton (), which is not an atomic operation. In fact, this sentence in JVM does about three things.

Allocate memory to uniqueInstance

Call the constructor of Singleton to initialize member variables

Point the uniqueInstance object to the allocated memory space (uniqueInstance will be non-null after performing this step)

But there is an optimization for instruction reordering in JVM's just-in-time compiler. In other words, the order of the second and third steps above cannot be guaranteed, and the final execution order may be 1-2-3 or 1-3-2. If it is the latter, it is preempted by thread 2 before the execution of 3 and 2, and the uniqueInstance is already non-null (but not initialized), so thread 2 will directly return uniqueInstance, then use it, and then naturally report an error.

We just need to declare the uniqueInstance variable as volatile.

Public class Singleton {private volatile static Singleton uniqueInstance; / / is declared as volatile private Singleton () {} public static Singleton getSingleton () {if (uniqueInstance = = null) {synchronized (Singleton.class) {if (uniqueInstance = = null) {uniqueInstance = new Singleton () } return uniqueInstance;}}

Some people think that the reason for using volatile is visibility, which ensures that the thread will not have a copy of uniqueInstance locally and will read it in main memory every time. But it's not right. The main reason for using volatile is another feature: it prohibits instruction reordering optimization. That is, there is a memory barrier (on the generated assembly code) behind the assignment of the volatile variable, and the read operations are not reordered before the memory barrier. For example, in the above example, the fetch operation must be performed after 1-2-3 or 1-3-2, and there is no case of performing 1-3 and then fetching the value. From the perspective of the "first-occurrence principle", writing to a volatile variable occurs first in a subsequent read to that variable (the "after" here is in chronological order).

However, it is important to note that it is problematic to use volatile double-check locks in versions prior to Java 5. The reason is that JMM (Java memory model) before Java 5 is flawed, and reordering can not be completely avoided even if variables are declared as volatile, mainly because there is still a reordering problem in the code before and after volatile variables. This volatile masking reordering problem was fixed in Java 5, so you can rest assured that volatile can be used after that.

I'm sure you won't like this complex and hidden problem approach, but of course we have a better way to implement a thread-safe singleton pattern.

4. Urgent loading static final field thread safety

This approach is simple because the singleton instance is declared as static and final variables and initialized the first time the class is loaded into memory, so creating the instance itself is thread-safe.

Initialize private static final Singleton uniqueInstance = new Singleton (); private Singleton () {} public static Singleton getInstance () {return uniqueInstance;}} when the public class Singleton {/ / class is loaded

If this way of writing is perfect, there is no need to dwell on so many questions about double locks. The disadvantage is that it is not a lazy loading mode (lazy initialization), and the singleton is initialized as soon as the class is loaded, even if the client does not call the getInstance () method. The hungry Chinese creation method will not be used in some scenarios: for example, the creation of a Singleton instance depends on parameters or configuration files, and you must call a method to set parameters to it before getInstance (), so this singleton writing method cannot be used.

5. Static inner class static nested class thread safety

I prefer to use the static inner class method, which is also recommended on "Effective Java".

Public class Singleton {private static class SingletonHolder {private static final Singleton uniqueInstance = new Singleton ();} private Singleton () {} public static final Singleton getInstance () {return SingletonHolder.uniqueInstance;}}

This way of writing still uses JVM's own mechanism to ensure thread safety; because SingletonHolder is private, there is no way to access it except getInstance (), so it is lazily loaded; at the same time, there is no synchronization when reading the instance, there are no performance defects; and it does not rely on the JDK version.

Enumerate Enum thread safety

It is too easy to write singles with enumerations! This is also its greatest advantage. The following code is a common practice for declaring an enumerated instance.

Public enum EasySingleton {INSTANCE;}

We can access the instance through EasySingleton.INSTANCE, which is much easier than calling the getInstance () method. Creating enumerations is thread-safe by default, so you don't need to worry about double checked locking, and you can prevent deserialization from causing new objects to be recreated. But it is still rare to see people write like this, perhaps because they are not familiar with it.

Summary

Generally speaking, the singleton pattern can be written in five ways: lazy loading, urgent loading, double checking and locking, static inner classes, and enumerations. All of the above are thread-safe implementations, and the first method given at the beginning of the article is not the correct way to write it.

As far as I am concerned, in general, it would be nice to use urgent loading directly. If you explicitly require lazy loading (lazy initialization), you will tend to use static inner classes, and if it comes to deserialization, you will try to use enumerations to implement singletons.

At this point, I believe you have a deeper understanding of "how to write the singleton mode to ensure thread safety". 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.