A singleton mode, there is no need to be so complicated, right?

Laomao’s design pattern column has been secretly published. Not willing to be a crud boy? Still can’t remember the design pattern you’ve read several times? Then don’t forget it, keep up with the old cat, and understand the essence of design patterns through interesting workplace stories. What are you waiting for? Hurry up and get in the car

Comparing system software to a river and lake, design principles are the martial arts mentality of OO programmers, and design patterns are moves. It's not enough to have mental skills alone, you need to combine them with moves. Only when mental skills and moves complement each other can we deal with powerful enemies (such as the "cheating system"), be flexible and invincible.

story

The business process and code process that were previously sorted out by Mao Mao have been basically sorted out [system sorting method & code sorting method]. From the code side, we also found out the reason why the system was bloated [violating design principles]. Mao Mao gradually got on the right track, and he decided to start with some simple business scenarios and start optimizing the system code. So what kind of business code will have the least impact after being changed? Mao Mao looked at it and decided to start with the thread pool that was created randomly. He planned to use the singleton mode to reconstruct it.

In the system that Mao Mao takes over, the creation of thread pool is usually based on the need to directly implement multi-threading functions in specific classes. Therefore, traces of creating thread pools will be found in many service service classes.

Write in front

In order to solve the above kitten problem, we plan to use the singleton mode to create a shared thread pool executor, and combine it with the factory mode for classification management according to business types.

Next, let’s start with the singleton mode.

summary

Single case pattern definition

Singleton is a design pattern that aims to ensure that there is only one instance of a specific class in the system and provides a global access point for external access. This mode appears to control the number of instances of a certain class in the system, save system resources and facilitate access. Through the singleton mode, you can effectively manage object instances in the system, avoid creating the same type of objects multiple times, and improve system performance and resource utilization. There are many ways to implement the singleton pattern, including lazy man style, hungry man style, double check lock, etc. In software development, the singleton pattern is often used in scenarios that require a unique instance, such as configuration information, logging, thread pools, etc. Through the singleton mode, the system architecture can be simplified, the degree of coupling can be reduced, and the maintainability and scalability of the code can be improved.

Simple diagram of singleton mode

Hungry Chinese Singleton Mode

What is a hungry Chinese singleton? In order to facilitate memory, the old cat understands this. The image of a hungry man is that of eager to eat when there is food. So the image of the Hungry-style singleton pattern is that when the class is created, you can’t wait to create a singleton object. This singleton pattern is absolutely thread-safe, because this pattern has already created the singleton object before a thread is generated. example.

Look at the example as follows:

/**
 * 公众号：程序员老猫
 * 饿汉单例模式 
 */
public class HungrySingleton {

private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();

//构造函数私有化，保证不被new方式多次创建新对象
private HungrySingleton() {
}

public static HungrySingleton getInstance(){
return HUNGRY_SINGLETON;
}
}

Let’s take a look at the advantages and disadvantages of the above cases:

• Advantages: Thread safety, initialization is completed when the class is loaded, and object acquisition is faster.
• Disadvantages: Since the creation of the object is completed when the class is loaded, sometimes the object already exists without calling it, which will cause a waste of memory.

The current development of hardware and servers is faster than the development of software. In addition, microservices and cluster deployment have greatly reduced the threshold and cost of horizontal expansion. Therefore, Laomao feels that the current memory is actually worthless, so It is not true that the above-mentioned singleton model has serious shortcomings. I personally think that there is no problem in using this model in the actual development process.

In fact, in the spring framework we use daily, the IOC container itself is a Hungry-style singleton mode. When spring starts, the object is loaded into the memory. We will not expand it here. We will sort out the spring source later. Let’s expand on it when it comes to code.

Lazy Singleton Pattern

We said that the disadvantage of the above-mentioned hungry singleton mode is the waste of memory, because it creates objects when the class is loaded. So to solve this kind of memory waste, we have the "lazy mode". Lao Mao understands this type of singleton pattern in this way. The definition of lazy person gives people the intuitive feeling of laziness and procrastination. In terms of the corresponding model, the method of creating an object in this scheme is to first determine whether the object has been instantiated (judgment empty) before the program uses the object. If it has been instantiated, it will directly return the object of this type. Otherwise, the instantiation will be performed first. operate.

Look at the example as follows:

/**
 * 公众号：程序员老猫
 * 懒汉式单例模式
 */
public class LazySingleton {
private LazySingleton() {
}

private static LazySingleton lazySingleton = null;
public static LazySingleton getInstance() {
if (lazySingleton == null) {
lazySingleton =new LazySingleton();
}
return lazySingleton;
}
}

The memory problem seems to have been solved when creating objects in the singleton mode above, but is this creation method really thread-safe? Let’s write a simple test demo next:

public class Main {
public static void main(String[] args) {
Thread thread1 = new Thread(()->{
LazySingleton lazySingleton = LazySingleton.getInstance();
System.out.println(lazySingleton.toString());
});
Thread thread2 = new Thread(()->{
LazySingleton lazySingleton = LazySingleton.getInstance();
System.out.println(lazySingleton.toString());
});
thread1.start();
thread2.start();
System.out.println("end");
}
}

The execution output results are as follows:

end
LazySingleton@3fde6a42
LazySingleton@2648fc3a

From the above output, we can easily find that the objects obtained in the two threads are different. Of course, this has a certain probability. So in this multi-threaded request scenario, thread safety issues arise.

聊到共享变量访问线程安全性的问题，我们往往就想到了锁，所以，咱们在原有的代码块上加上锁对其优化试试，我们首先想到的是给方法代码块加上锁。

加锁后代码如下：

public class LazySingleton {

private LazySingleton() {
}

private static LazySingleton lazySingleton = null;
public synchronized static LazySingleton getInstance() {
if (lazySingleton == null) {
lazySingleton =new LazySingleton();
}
return lazySingleton;
}
}

经过上述同样的测试类运行之后，我们发现问题似乎解决了，每次运行之后得到的结果，两个线程对象的输出都是一致的。

我们用线程debug的方式看一下具体的运行情况，如下图：

线程输出

我们可以发现，当一个线程进行初始化实例时，另一个线程就会从Running状态自动变成了Monitor状态。试想一下，如果有大量的线程同时访问的时候，在这样一个锁的争夺过程中就会有很多的线程被挂起为Monitor状态。CPU压力随着线程数的增加而持续增加，显然这种实现对性能还是很有影响的。

那还有优化的空间么？当然有，那就是大家经常听到的“DCL”即“Double Check Lock” 实现如下：

/**
 * 公众号：程序员老猫
 * 懒汉式单例模式(DCL)
 * Double Check Lock
 */
public class LazySingleton {

private LazySingleton() {
}
//使用volatile防止指令重排
private volatile static LazySingleton lazySingleton = null;
public static LazySingleton getInstance() {
if (lazySingleton == null) {
synchronized (LazySingleton.class) {
if(lazySingleton == null){
lazySingleton =new LazySingleton();
}
}
}
return lazySingleton;
}
}

通过DEBUG，我们来看一下下图：

双重校验锁

这里引申一个常见的问题，大家在面试的时候估计也会碰到。问题：为什么要double check？去掉第二次check行不行？

回答：当2个线程同时执行getInstance方法时，都会执行第一个if判断，由于锁机制的存在，会有一个线程先进入同步语句，而另一个线程等待，当第一个线程执行了new Singleton()之后，就会退出synchronized的保护区域，这时如果没有第二重if判断，那么第二个线程也会创建一个实例，这就破坏了单例。

问题：这里为什么要加上volatile修饰关键字？回答：这里加上该关键字主要是为了防止”指令重排”。关于“指令重排”具体产生的原因我们这里不做细究，有兴趣的小伙伴可以自己去研究一下，我们这里只是去分析一下，“指令重排”所带来的影响。

lazySingleton =new LazySingleton();

这样一个看似简单的动作，其实从JVM层来看并不是一个原子性的行为，这里其实发生了三件事：

• 给LazySingleton分配内存空间。
• 调用LazySingleton的构造函数，初始化成员字段。
• 将LazySingleton指向分配的内存空间(注意此时的LazySingleton就不是null了)

在此期间存在着指令重排序的优化，第2、3步的顺序是不能保证的，最后的执行顺序可能是1-2-3，也可能是1-3-2，假如执行顺序是1-3-2，我们看看会出现什么问题。看一下下图：

指令重排执行

从上图中我们看到虽然LazySingleton不是null，但是指向的空间并没有初始化，最终被业务使用的时候还是会报错，这就是DCL失效的问题，这种问题难以跟踪难以重现可能会隐藏很久。

JDK1.5之前JMM(Java Memory Model，即Java内存模型)中的Cache、寄存器到主存的回写规定，上面第二第三的顺序无法保证。JDK1.5之后，SUN官方调整了JVM，具体化了volatile关键字，private volatile static LazySingleton lazySingleton;只要加上volatile，就可以保证每次从主存中读取（这涉及到CPU缓存一致性问题，感兴趣的小伙伴可以研究研究），也可以防止指令重排序的发生，避免拿到未完成初始化的对象。

上面这种方式可以有效降低锁的竞争，锁不会将整个方法全部锁定，而是锁定了某个代码块。其实完全做完调试之后我们还是会发现锁争夺的问题并没有完全解决，用到了锁肯定会对整个代码的执行效率带来一定的影响。所以是否存在保证线程的安全，并且能够不浪费内存完美的解决方案呢？一起看下下面的解决方案。

内部静态类单例模式

这种方式其实是利用了静态对象创建的特性来解决上述内存浪费以及线程不安全的问题。在这里我们要弄清楚，被static修饰的属性，类加载的时候，基本属性就已经加载完毕，但是静态方法却不会加载的时候自动执行，而是等到被调用之后才会执行。并且被STATIC修饰的变量JVM只为静态分配一次内存。(这里老猫不展开去聊static相关知识点，有兴趣的小伙伴也可以自行去了解一下更多JAVA中static关键字修饰之后的类、属性、方法的加载机制以及存储机制)

所以综合这一特性，我们就有了下面这样的写法：

public class LazyInnerClassSingleton {
private LazyInnerClassSingleton () {
}

public static final LazyInnerClassSingleton getInstance() {
return LazyHolder.LAZY;
}

private static class LazyHolder {
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}

上面这种写法，其实也属于“懒汉式单例模式”，并且这种模式相对于“无脑加锁”以及“DCL”以及“饿汉式单例模式”来说无疑是最优的一种实现方式。

但是深度去追究的话，其实这种方式也会有问题，这种写法并不能防止反序列化和反射生成多个实例。我们简单看一下反射的破坏的测试类：

public class DestructionSingletonTest {
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Class enumSingletonClass = LazyInnerClassSingleton.class;
//枚举默认有个String 和 int 类型的构造器
Constructor constructor = enumSingletonClass.getDeclaredConstructor();
constructor.setAccessible(true);
//利用反射调用构造方法两次直接创建两个对象，直接破坏单例模式
LazyInnerClassSingleton singleton1 = (LazyInnerClassSingleton) constructor.newInstance();
LazyInnerClassSingleton singleton2 = (LazyInnerClassSingleton) constructor.newInstance();
}
}

这里序列化反序列化单例模式破坏老猫偷个懒，因为下面会有写到，有兴趣的小伙伴继续看下文，老猫觉得这种破坏场景在真实的业务使用场景比较极端，如果不涉及底层框架变动，光从业务角度来看，上面这些单例模式的实现已经管够了。当然如果硬是要防止上面的反射创建单例两次问题也能解决,如下：

public class LazyInnerClassSingleton {
private LazyInnerClassSingleton () {
if(LazyHolder.LAZY != null) {
throw new RuntimeException("不允许创建多个实例");
}
}

public static final LazyInnerClassSingleton getInstance() {
return LazyHolder.LAZY;
}

private static class LazyHolder {
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}

写到这里，可能大家都很疑惑了，咋还没提及用单例模式优化线程池创建。下面这不来了么，老猫个人觉得上面的这种方式进行创建单例还是比较好的，所以就用这种方式重构一下线程池的创建，具体代码如下：

public class InnerClassLazyThreadPoolHelper {
public static void execute(Runnable runnable) {
ThreadPoolExecutor threadPoolExecutor = ThreadPoolHelperHolder.THREAD_POOL_EXECUTOR;
threadPoolExecutor.execute(runnable);
}
/**
 * 静态内部类创建实例(单例).
 * 优点：被调用时才会创建一次实例
 */
public static class ThreadPoolHelperHolder {
private static final int CPU = Runtime.getRuntime().availableProcessors();
private static final int CORE_POOL_SIZE = CPU + 1;
private static final int MAXIMUM_POOL_SIZE = CPU * 2 + 1;
private static final long KEEP_ALIVE_TIME = 1L;
private static final TimeUnit TIME_UNIT = TimeUnit.SECONDS;
private static final int MAX_QUEUE_NUM = 1024;

private ThreadPoolHelperHolder() {
}

private static final ThreadPoolExecutor THREAD_POOL_EXECUTOR = new ThreadPoolExecutor(
CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE_TIME, TIME_UNIT,
new LinkedBlockingQueue(MAX_QUEUE_NUM),
new ThreadPoolExecutor.AbortPolicy());
}
}

The above is the detailed content of A singleton mode, there is no need to be so complicated, right?. For more information, please follow other related articles on the PHP Chinese website!