一、前言

学习设计模式我们关注的是什么，如何实现么？是也不是。我认为比了解如何实现设计模式更重要的是这些设计模式的应用场景，什么场景下我们该用这种设计模式；以及这些设计模式所包含的思想，最终帮助我们把代码写“好”。

设计模式的分类

而对于单例模式的创建型模式来说，主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

二、什么是单例模式

单例模式（Singleton Pattern），是最简单的一个模式。

单例模式基本定义：程序运行时，在java虚拟机中只存在该类的一个实例对象。

单例模式指的是全局只有一个实例，并且它负责创建自己的对象。单例模式不仅有利于减少内存开支，还有减少系统性能开销、防止多个实例产生冲突等优点。

主要解决：一个全局使用的类频繁地创建与销毁。

因为单例模式保证了实例的全局唯一性，而且只被初始化一次，所以比较适合全局共享一个实例，且只需要被初始化一次的场景，例如数据库实例、全局配置、全局任务池等。

单例模式又分为饿汉方式和懒汉方式。

• 饿汉方式：指该类初始化的时候就创建实例对象，线程是安全的。
• 懒汉方式：指首次使用单例实例的时候创建，之后使用时再判断单例实例是否已创建，如果没有则创建实例。

三、单例模式的实现

3.1 饿汉模式—静态变量方式

代码示例

/**
 * @Author: 公众号：技术能量站
 * @desc: 1. 饿汉模式—静态变量的方式
 * @create: 2019-10-20-20:20
 */
public class HungrySingleton {

    //保存该类对象的实例，饿汉式的做法：在声明的同时初始化该对象
    private static final HungrySingleton instance = new HungrySingleton();

    //将构造函数私有化，不对外提供构造函数
    private HungrySingleton() {
    }

    //对外提供访问该类对象的方法
    public static HungrySingleton getInstance() {
        return instance;
    }
}

该方式在成员位置声明 Singleton 类型的静态变量，并创建 Singleton 类的对象 instance。instance 对象是随着类的加载而创建的。如果该对象足够大的话，而一直没有使用就会造成内存的浪费。

3.2 饿汉模式—枚举类

枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。
代码示例

/**
 * @author 公众号：技术能量站
 * @desc: 枚举实现单例模式
 * @date: 2021/7/20
 */
public enum EnumSingleton {

    INSTANCE;

    public static EnumSingleton getInstance() {
        return INSTANCE;
    }
}

3.3 懒汉模式—线程不安全

代码示例

/**
 * @Author: 公众号：技术能量站
 * @desc: 懒汉模式——线程不安全
 * @create: 2019-10-20-20:53
 * @detail:
 */
public class ThreadUnSafeLazySingleton {

    private static ThreadUnSafeLazySingleton instance;  // ----> 注释1

    private ThreadUnSafeLazySingleton() {
    }

    public static ThreadUnSafeLazySingleton getInstance() {
        if (instance == null) {
            //  ----> 注释2
            instance = new ThreadUnSafeLazySingleton(); // ----> 注释3
        }
        return instance;
    }
}

从上面代码我们可以看出该方式在成员位置声明 ThreadUnSafeLazySingleton 类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？

当调用 getInstance() 方法获取 ThreadUnSafeLazySingleton 类的对象的时候才创建 Singleton 类的对象，这样就实现了懒加载的效果。但是，如果是多线程环境，会出现线程安全问题。

3.4 懒汉模式—线程安全

示例代码

/**
 * @author 公众号：技术能量站
 * @desc: 懒汉模式——线程安全
 * @date: 2021/7/22
 */
public class ThreadSafeLazySingleton {

    private static ThreadSafeLazySingleton instance;

    // 私有构造方法，防止被实例化
    private ThreadSafeLazySingleton() {
    }

    // 静态get方法,加了synchronized独占锁
    public static synchronized ThreadSafeLazySingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeLazySingleton();
        }
        return instance;
    }
}

这种方式也实现了懒加载效果，同时又解决了线程安全问题。但是在 getInstance() 方法上添加了 synchronized 关键字，导致该方法的执行效果特别低。从上面代码我们可以看出，其实就是在初始化 instance 的时候才会出现线程安全问题，一旦初始化完成就不存在了。

3.5 懒汉模式—双重检测

再来讨论一下懒汉模式中加锁的问题，对于 getInstance() 方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以我们没必要让每个线程必须持有锁才能调用该方法，我们需要调整加锁的时机。由此也产生了一种新的实现模式：双重检查锁模式。
代码示例

/**
 * @Author: 公众号：技术能量站
 * @desc: 双重检测 DCL
 * @create: 2019-10-20-20:47
 */
public class DoubleCheckSingleton {

    private static DoubleCheckSingleton singleton;

    private DoubleCheckSingleton() {
    }

    public static DoubleCheckSingleton getInstance() {
        // 检查是否已经被创建——第一个 if 可以避免频繁加锁，如果没有第一个 if，它就会直接尝试获取锁资源
        if (singleton == null) {
            // 同步块
            synchronized (DoubleCheckSingleton.class) {
                // 再次检测是否被创建----双重检测

                // 第二个if是避免重复创建线程，破坏单例

                // 现假设有两个 T1 和 T2，T1 执行到同步块时，CPU 的执行权被 T2 抢夺走，T2 执行完成之后创建了一个对象实例，
                // 并且释放 Java 的类锁。这个时候 T1 又重新获得了 CPU 的执行权，并且获得了类锁。
                // 如果没有第二个 if 的判断，T1 又会重新创建一个 实例对象，这样就破坏了单例。
                if (singleton == null) {
                    // 标记3
                    singleton = new DoubleCheckSingleton();
                }
            }
        }
        return singleton;
    }
}

双重检查锁模式是一种非常好的单例实现模式，解决了单例、性能、线程安全问题，上面的双重检测锁模式看上去完美无缺，其实是存在问题；

在多线程的情况下，可能会出现空指针问题，出现问题的原因是 JVM 在实例化对象的时候会进行优化和指令重排序操作。

要解决双重检查锁模式带来空指针异常的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。
代码示例

/**
 * @Author: 公众号：技术能量站
 * @desc: 双重检测 DCL
 * @create: 2019-10-20-20:47
 */
public class DoubleCheckSingleton{

    // volatile 存在是保证内存的可见性，禁止指令重排序
    // 原因：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。
    // 但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，
    // 然后再去初始化这个Singleton实例

    // 举例： 重排序会 导致 step2 和 step3 执行的顺序颠倒
    // 创建对象的步骤：step1：在内存中分配一块空间。step2：对内存空间进行初始化。step3：把对象在内存中的位置指向 instance。
    // 现在假设有两个线程T1、T2，T1 线程执行完重排序后的 step3 ，CPU 的执行权被 T2 获得。这个时候，instance 已经不为 null 了，
    // 他指向了内存中的一块地址。T2 执行到第一个 if 的时候，发现 instance 不为 null，就直接返回，但是这个 instance 并没有被初始化，
    // 这就会导致 T2 在执行的过程中发生不可预知的错误。
    private volatile static DoubleCheckSingleton singleton;

    private DoubleCheckSingleton() {
    }

    public static DoubleCheckSingleton getInstance() {
        // 检查是否已经被创建——第一个 if 可以避免频繁加锁，如果没有第一个 if，它就会直接尝试获取锁资源
        if (singleton == null) {
            // 同步块
            synchronized (DoubleCheckSingleton.class) {
                // 再次检测是否被创建----双重检测

                // 第二个if是避免重复创建线程，破坏单例

                // 现假设有两个 T1 和 T2，T1 执行到同步块时，CPU 的执行权被 T2 抢夺走，T2 执行完成之后创建了一个对象实例，
                // 并且释放 Java 的类锁。这个时候 T1 又重新获得了 CPU 的执行权，并且获得了类锁。
                // 如果没有第二个 if 的判断，T1 又会重新创建一个 实例对象，这样就破坏了单例。
                if (singleton == null) {
                    // 标记3
                    singleton = new DoubleCheckSingleton();
                }
            }
        }
        return singleton;
    }
}

添加 volatile 关键字之后的双重检查锁模式是一种比较好的单例实现模式，能够保证在多线程的情况下线程安全也不会有性能问题。

核心点小总结

（1）为什么要double check？去掉第二次check行不行？

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

（2）singleton为什么要加上volatile关键字?

主要原因就是 singleton = new Singleton();不是一个原子操作。在JVM中，这句语句至少做了3件事

1. 给Singleton的实例分配内存空间；
2. 调用Singleton()的构造函数，初始化成员字段；
3. 将singleton指向分配的内存空间(此时singleton就不是null了)

因为存在着指令重排序的优化，第2、3步的顺序是不能保证的，最后的执行顺序可能是1-2-3，也可能是1-3-2，假如执行顺序是1-3-2，看看会出现什么问题。

虽然singleton不是null，但是指向的空间并没有初始化，还是会报错，这就是DCL失效的问题，这种问题难以跟踪难以重现可能会隐藏很久。

JDK1.5之前JMM(Java Memory Model，即Java内存模型)中的Cache、寄存器到主存的回写规定，上面第二第三的顺序无法保证。

JDK1.5之后，SUN官方调整了JVM，具体化了volatile关键字，private static volatile Singleton singleton;

只要加上volatile，就可以保证每次从主存中读取（这涉及到CPU缓存一致性问题，不在本文探讨范围内，有兴趣自行搜索），也可以防止指令重排序的发生，避免拿到未完成初始化的对象。

简单讲，volatile主要就是限制JIT编译器优化，编译器优化常用的方法有：

1. 将内存变量缓存到寄存器；
2. 调整指令顺序充分利用CPU指令流水线，常见的是重新排序读写指令。

如果没有volatile关键字，则编译器可能优化读取，使用寄存器中的缓存值，如果这个变量由别的线程更新了的话，将出现实际值和读取的值不一致。「使用了volatile后，编译器读取的时候跳过缓存，直接在内存中的实际位置读变量，写的时候通知其他缓存更新，这就是所谓的保证内存可见性，并且使用volatile还能禁止指令重排序。」

public volatile int a = 11;
......
int c = 6;
c = a;// 执行这一句的时候，在高并发情况下，a如果被修改为22，那么c会被赋值为22而不是11

//如果a不被volatile修饰，c有小概率被赋值为11，因为c取寄存器的缓存副本11还没来得及更新

3.6 懒汉模式—静态内部类

静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。
代码示例

/**
 * @Author: 公众号：技术能量站
 * @desc: 静态内部类的单例
 * @create: 2019-10-20-21:01
 */
public class InnerClassSingleton {

    // 私有化构造方法
    private InnerClassSingleton() {
    }

    // 获取单例
    public static InnerClassSingleton getInstance() {
        return SingletonFactory.INSTANCE;
    }

    /* 此处使用一个内部类来维护单例 */
    private static final class SingletonFactory {
        private static final InnerClassSingleton INSTANCE = new InnerClassSingleton();
    }
}

第一次加载 InnerClassSingleton 类时不会去初始化 INSTANCE，只有第一次调用 getInstance，虚拟机加载 SingletonFactory 并初始化 INSTANCE，这样不仅能确保线程安全，也能保证 Singleton 类的唯一性。

静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

四、存在的问题

破坏单例模式：使上面定义的单例类（Singleton）也可以通过序列化或者反射创建多个对象，枚举方式除外。所以序列化和反射技术会破坏单例。

枚举方式不会出现这两个问题。

下面以双重检测实现单例模式的实现为例：

/**
 * @Author: 公众号：技术能量站
 * @desc: 双重检测 DCL
 * @create: 2019-10-20-20:47
 */
public class DoubleCheckSingleton {

    // volatile 存在是保证内存的可见性，禁止指令重排序
    // 原因：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。
    // 但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，
    // 然后再去初始化这个Singleton实例

    // 举例： 重排序会 导致 step2 和 step3 执行的顺序颠倒
    // 创建对象的步骤：step1：在内存中分配一块空间。step2：对内存空间进行初始化。step3：把对象在内存中的位置指向 instance。
    // 现在假设有两个线程T1、T2，T1 线程执行完重排序后的 step3 ，CPU 的执行权被 T2 获得。这个时候，instance 已经不为 null 了，
    // 他指向了内存中的一块地址。T2 执行到第一个 if 的时候，发现 instance 不为 null，就直接返回，但是这个 instance 并没有被初始化，
    // 这就会导致 T2 在执行的过程中发生不可预知的错误。
    private volatile static DoubleCheckSingleton singleton;

    private DoubleCheckSingleton() {
    }

    public static DoubleCheckSingleton getInstance() {
        // 检查是否已经被创建——第一个 if 可以避免频繁加锁，如果没有第一个 if，它就会直接尝试获取锁资源
        if (singleton == null) {
            // 同步块
            synchronized (DoubleCheckSingleton.class) {
                // 再次检测是否被创建----双重检测

                // 第二个if是避免重复创建线程，破坏单例

                // 现假设有两个 T1 和 T2，T1 执行到同步块时，CPU 的执行权被 T2 抢夺走，T2 执行完成之后创建了一个对象实例，
                // 并且释放 Java 的类锁。这个时候 T1 又重新获得了 CPU 的执行权，并且获得了类锁。
                // 如果没有第二个 if 的判断，T1 又会重新创建一个 实例对象，这样就破坏了单例。
                if (singleton == null) {
                    // 标记3
                    singleton = new DoubleCheckSingleton();
                }
            }
        }
        return singleton;
    }
}

4.1 反序列化—破坏单例模式

破坏原因：是反序列化的时候通过反射newInstance 重新生成了一个类 所以和原有的类不是同一个

    /**
     * implements Serializable
     * 注意：测试序列化时 需要被序列化的类 实现序列化接口
     */
    @SneakyThrows
    private static void test_serialize() {
        // 1、序列化
        DoubleCheckSingleton checkSingleton01 = DoubleCheckSingleton.getInstance();
        FileOutputStream fileOutputStream = new FileOutputStream("single");
        ObjectOutputStream oos = new ObjectOutputStream(fileOutputStream);
        oos.writeObject(checkSingleton01);
        oos.flush();
        oos.close();

        // 2、反序列化
        // 破坏原因：反序列化的时候通过反射newInstance 重新生成了一个类 所以和原有的类不是同一个
        FileInputStream inputStream = new FileInputStream("single");
        ObjectInputStream oosInput = new ObjectInputStream(inputStream);
        DoubleCheckSingleton checkSingleton02 = (DoubleCheckSingleton)oosInput.readObject();

        // 打印输出
        System.out.println("checkSingleton01 = " + checkSingleton01);
        System.out.println("checkSingleton02 = " + checkSingleton02);
        System.out.println(checkSingleton02 == checkSingleton01);
    }

4.2 反射—破坏单例模式

通过反射获得单例类的构造函数，由于该构造函数是private的，通过setAccessible(true)指示反射的对象在使用时应该取消；

setAccessible(true) 方法可以在Java 语言访问检查,使得私有的构造函数能够被访问，这样使得单例模式失效。

代码示例

    /**
     * 测试
     * 反射 可以修改单例类/破坏单例
     * 解决办法：
     *   通过一个变量统计创建对象的次数，如果count>0 则抛出异常
     */
    @SneakyThrows
    private static void test_reflect() {
        DoubleCheckSingleton checkSingleton01 = DoubleCheckSingleton.getInstance();
        Constructor<DoubleCheckSingleton> constructor = DoubleCheckSingleton.class.getDeclaredConstructor();
        // 通过反射获得单例类的构造函数，由于该构造函数是private的，通过setAccessible(true)指示反射的对象在使用时应该取消
       
        // 取消访问检查
        constructor.setAccessible(true);
        DoubleCheckSingleton checkSingleton02 = constructor.newInstance();

        System.out.println(checkSingleton01.hashCode()); // 1625635731
        System.out.println(checkSingleton02.hashCode()); // 1580066828
    }

五、如何避免破坏单例

5.1 反序列化方式破坏单例的解决方案

解决方案就是：在 DoubleCheckSingleton 类中添加 readResolve() 方法，在反序列化时被反射调用，如果定义了这个方法，就返回这个方法的值，如果没有定义，则返回新 new 出来的对象。

代码示例

import java.io.Serializable;

/**
 * @Author: 公众号：技术能量站
 * @desc: 双重检测 DCL
 * @create: 2019-10-20-20:47
 */
public class DoubleCheckSingleton implements Serializable {

    // volatile 存在是保证内存的可见性，禁止指令重排序
    // 原因：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。
    // 但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，
    // 然后再去初始化这个Singleton实例

    // 举例： 重排序会 导致 step2 和 step3 执行的顺序颠倒
    // 创建对象的步骤：step1：在内存中分配一块空间。step2：对内存空间进行初始化。step3：把对象在内存中的位置指向 instance。
    // 现在假设有两个线程T1、T2，T1 线程执行完重排序后的 step3 ，CPU 的执行权被 T2 获得。这个时候，instance 已经不为 null 了，
    // 他指向了内存中的一块地址。T2 执行到第一个 if 的时候，发现 instance 不为 null，就直接返回，但是这个 instance 并没有被初始化，
    // 这就会导致 T2 在执行的过程中发生不可预知的错误。
    private volatile static DoubleCheckSingleton singleton;

    private DoubleCheckSingleton() {
    }

    public static DoubleCheckSingleton getInstance() {
        // 检查是否已经被创建——第一个 if 可以避免频繁加锁，如果没有第一个 if，它就会直接尝试获取锁资源
        if (singleton == null) {
            // 同步块
            synchronized (DoubleCheckSingleton.class) {
                // 再次检测是否被创建----双重检测

                // 第二个if是避免重复创建线程，破坏单例

                // 现假设有两个 T1 和 T2，T1 执行到同步块时，CPU 的执行权被 T2 抢夺走，T2 执行完成之后创建了一个对象实例，
                // 并且释放 Java 的类锁。这个时候 T1 又重新获得了 CPU 的执行权，并且获得了类锁。
                // 如果没有第二个 if 的判断，T1 又会重新创建一个 实例对象，这样就破坏了单例。
                if (singleton == null) {
                    // 标记3
                    singleton = new DoubleCheckSingleton();
                }
            }
        }
        return singleton;
    }

    /**
     * 解决序列化和反序列化对单例的破坏,
     *  当进行反序列化时，会自动调用该方法，将该方法的返回值直接返回
     * @return
     */
    private Object readResolve() {
        return singleton;
    }

}

源码解析—ObjectInputStream类

    public final Object readObject()
        throws IOException, ClassNotFoundException
    {
        ...
        // if nested read, passHandle contains handle of enclosing object
        int outerHandle = passHandle;
        try {
            Object obj = readObject0(false);//重点查看readObject0方法
        ...
    }

    private Object readObject0(boolean unshared) throws IOException {
        ...
        try {
            switch (tc) {
                ...
                case TC_OBJECT:
                    return checkResolve(readOrdinaryObject(unshared));//重点查看readOrdinaryObject方法
                ...
            }
        } finally {
            depth--;
            bin.setBlockDataMode(oldMode);
        }    
    }

    private Object readOrdinaryObject(boolean unshared) 
        throws IOException
    {
        ...
        // isInstantiable 返回true，执行 desc.newInstance()，通过反射创建新的单例类，
        obj = desc.isInstantiable() ? desc.newInstance() : null; 
        ...
        // 在Singleton类中添加 readResolve 方法后 desc.hasReadResolveMethod() 方法执行结果为true
        if (obj != null && 
            handles.lookupException(passHandle) == null && 
            desc.hasReadResolveMethod()) 
        {
            // 通过反射调用 Singleton 类中的 readResolve 方法，将返回值赋值给rep变量
            // 这样多次调用ObjectInputStream类中的readObject方法，继而就会调用我们定义的readResolve方法，所以返回的是同一个对象。
            Object rep = desc.invokeReadResolve(obj);
            ...
        }
        return obj;
    }

5.2 反射方式破解单例的解决方案

这种方式比较好理解。当通过反射方式调用构造方法进行创建创建时，直接抛异常。不运行此中操作。

public class Singleton {

    // 私有构造方法
    private Singleton() {
        /*
         * 反射破解单例模式需要添加的代码
         */
        if (instance != null) {
            throw new RuntimeException("不能创建多个对象");
        }
    }
    
    private static volatile Singleton instance;

    // 对外提供静态方法获取该对象
    public static Singleton getInstance() {

        if (instance != null) {
            return instance;
        }

        synchronized (Singleton.class) {
            if (instance != null) {
                return instance;
            }
            instance = new Singleton();
            return instance;
        }
    }
}

六、应用实践

6.1 JDK源码解析-Runtime类

Runtime 类就是使用的单例设计模式
（1）通过源代码查看使用的是哪种单例模式

public class Runtime {
    // 饿汉式初始化
    private static Runtime currentRuntime = new Runtime();

    /**
     * Returns the runtime object associated with the current Java application.
     * Most of the methods of class <code>Runtime</code> are instance
     * methods and must be invoked with respect to the current runtime object.
     *
     * @return  the <code>Runtime</code> object associated with the current
     *          Java application.
     */
    public static Runtime getRuntime() {
        return currentRuntime;
    }

    /** Don't let anyone else instantiate this class */
    private Runtime() {}
    ...
}

从上面源代码中可以看出 Runtime 类使用的是饿汉式（静态属性）方式来实现单例模式的。

（2）使用 Runtime 类中的方法

public class RuntimeDemo {
    public static void main(String[] args) throws IOException {
        // 获取Runtime类对象
        Runtime runtime = Runtime.getRuntime();

		// 调用runtime的方法
        // 返回 Java 虚拟机中的内存总量
        //System.out.println(runtime.totalMemory());
        // 返回 Java 虚拟机试图使用的最大内存量
        //System.out.println(runtime.maxMemory());

        // exec方法，创建一个新的进程执行指定的字符串命令，返回进程对象
        Process process = runtime.exec("ipconfig");
        // 获取命令执行后的结果，通过输入流获取
        InputStream inputStream = process.getInputStream();
        byte[] arr = new byte[1024 * 1024* 100];
        // 读取数组 存到arr字节数组中
        int b = inputStream.read(arr); // 返回读到的字节的个数
        // 将字节数组转换为字符串输出到控制台
        System.out.println(new String(arr, 0, b, "gbk"));
    }
}