【JavaEE】多线程案例-单例模式

1. 前言

单例模式是我们面试中最常考到的设计模式。什么是设计模式呢？

设计模式是在计算机科学中，对面向对象设计中反复出现的问题的解决方案的描述。它是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

设计模式的目的在于可重用代码、让代码更容易被他人理解、提高代码的可靠性。它们通常描述了一组相互紧密作用的类与对象，提供了讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。此外，设计模式还为软件重构提供了目标。

设计模式可以根据目的分为以下三类：

1. 创建型模式：主要用于创建对象，这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。
2. 结构型模式：主要用于处理类和对象的组合。
3. 行为型模式：主要用于描述类或对象如何交互和怎样分配职责。

此外，根据范围，即模式主要是处理类之间的关系还是处理对象之间的关系，可分为类模式和对象模式两种。

2. 什么是单例模式

单例模式保证一个类在程序中只存咋一个实例，而不会创建出多个实例。就像一个人只能有一个伴侣，而不能有多个伴侣一样。

3. 如何实现单例模式

虽然我们可以自己人为的控制该类只存在一个实例，但是我们人是最不能相信的生物，所以就需要使用计算机来对我们进行约束。当我们想要创建多个实例的时候，就需要编译器做出相应的反应：抛异常或者直接结束进程等。

在Java中实现单例模式可以有两种方式：

1. 饿汉模式
2. 懒汉模式

3.1 饿汉模式

要想保证某个类只存在一个实例，其中一个很好的方法就是我们在定义这个类的时候就创建一个实例，并且这个实例是唯一的，当出了这个类的时候就不允许再创建该类的实例了。

class Singleton {//定义类的时候就创建一个唯一的实例private static Singleton instance = new Singleton();public static Singleton getInstance() {return instance;}
}

因为出了这个类之后不能再创建该类的实例，并且我们需要获得在该类定义时创建的实例，所以可以使用一个静态的 getInstance 方法来获得这个唯一的实例。

虽然我们创建出了这个唯一的实例，但是应该怎样保证出了这个类之后不能再创建实例了呢？

我们都知道，每次创建一个实例的时候，都会调用该类的构造方法（如果你没有实现构造方法，编译器会为你默认创建一个无参数的构造方法），所以我们可以从这个构造方法入手：将构造方法改为私有的构造方法，只有在这个类中创建实例的时候才会创建成功，出了这个类之后，如果再创建第二个实例的时候，因为构造方法是私有的，所以就会创建失败。

class Singleton {private static Singleton instance = new Singleton();public static Singleton getInstance() {return instance;}private Singleton() {}
}

当我们想要创建多个实例的时候，看看会发生什么情况：

当我们在写代码的时候，就会标红报错。然后我们再运行。

所以通过上面的饿汉模式实现单例模式是可以成功的，那么我们再来看看懒汉模式如何实现单例模式。

3.2 懒汉模式

前面的为什么要叫做饿汉模式呢？因为饿汉模式定义类的时候，及创建了一个静态的实例，我们都知道静态的成员变量在类加载的时候就会被创建。这样就会导致不管我们用还是没用到这个实例，这个实例都会被创建，会造成内存和时间的浪费。而我们懒汉模式则很好的解决了这个问题，当定义类的时候，我们先不创建这个实例，而是先定义有这个实例，将这个实例赋值为null，当调用 getInstance 方法的时候，判断这个实例是否为 null，如果是 null 则创建实例，为这个实例申请空间和初始化，如果不为空则直接返回。

class Singleton2 {private static Singleton2 instance = null;public static Singleton2 getInstance() {if(instance == null) {instance = new Singleton2();}return instance;}private Singleton2() {}
}

但是这样就结束了吗？当然不是，既然是多线程的案例，那么我们肯定要考虑到线程的安全问题，那么接下来我们来看看如何解决单例模式中遇到的线程安全问题。

4. 解决单例模式中遇到的线程安全问题

饿汉模式和懒汉模式是否都会在造成线程不安全问题吗？不是的，因为饿汉模式中只有对变量的判断而没有修改操作，但是懒汉模式中当判断 instance 是否为 null 之后，还会对 instance 做出修改，如果线程中存在判断和修改操作的时候，往往会出现线程不安全问题，所以只有懒汉模式会发生线程不安全的问题。

4.1 加锁

为了解决在判断和修改的过程中出现线程不安全的问题，需要在这个过程中进行加锁。

class Singleton2 {private static Singleton2 instance = null;public static Singleton2 getInstance() {synchronized (Singleton2.class) {if(instance == null) {instance = new Singleton2();}}return instance;}private Singleton2() {}
}

虽然我们在这个过程中进行了加锁，但是这个加锁过程并不是每次调用 getInstance 方法的时候都需要进行加锁，如果加锁频繁的话，那么我们这段代码就与高效率无缘了，只有当第一次调用 getInstance 方法的时候才需要加锁，那么我们又该如何优化这个频繁加锁问题呢？

4.2 加上一个判断解决频繁加锁问题

class Singleton2 {private static Singleton2 instance = null;public static Singleton2 getInstance() {if(instance == null) {synchronized (Singleton2.class) {if(instance == null) {instance = new Singleton2();}}}return instance;}private Singleton2() {}
}

当再加上一个判断的时候，可能会有人问了，我为了创建一个实例使用了两个相同的判断，那么这个判断不显得多余吗？不多于，这两个判断完全不多余。

• 第一个判断是判断是否需要加锁，避免频繁加锁
• 第二个判断是为了判断是否需要创建实例

当实例已经不为 null 的时候，那么因为第一个判断，就不会进行加锁，而是直接返回 instance。

4.2 解决因指令重排序造成的线程不安全问题

只有上面的两个优化是不够的，我们都知道造成线程不安全的问题还有指令重排序的问题。可以将创建实例的过程细分为三个步骤：

1. 向内存申请空间
2. 调用构造方法对该内存进行初始化
3. 将该内存赋值给 instance

如果在创建实例的过程中发生了指令重排序，线程 t1 执行的本应该的顺序为1、2、3，但是却重排序成了1、3、2，那么当线程 t2 和线程 t1 并发执行的时候，就会将没有初始化的引用给返回，从而会出现比较严重的后果。

所以为了解决指令重排序而发生的线程不安全问题，我们需要使用 volatile 来保证内存的可见性，防止出现指令重排序的发生。

class Singleton2 {private volatile static Singleton2 instance = null;public static Singleton2 getInstance() {if(instance == null) {synchronized (Singleton2.class) {if(instance == null) {instance = new Singleton2();}}}return instance;}private Singleton2() {}
}

有了这三个优化，才真正保证了单例模式的安全进行。