【设计模式】单例模式深度解析：从饿汉式到枚举实现的全方位解读

单例设计模式概念

就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法。如果我们要让类在一个虚拟机中只能产生一个对象，我们首先必须将类的构造器的访问权限设置为private，这样，就不能用new操作符在类的外部产生类的对象了，但在类内部仍可以产生该类的对象。因为在类的外部开始还无法得到类的对象，只能调用该类的某个静态方法以返回类内部创建的对象，静态方法只能访问类中的静态成员变量，所以，指向类内部产生的该类对象的变量也必须定义成静态的。

饿汉式

class Singleton {
    // 1.私有化构造器
    private Singleton() {
    }
    // 2.内部提供一个当前类的实例
    // 4.此实例也必须静态化
    private static Singleton single = new Singleton();
    // 3.提供公共的静态的方法，返回当前类的对象；在内存中自始至终都存在
    public static Singleton getInstance() {
        return single;
    }
}

案例：

public static void main(String[] args) {
        User user1 = User.getUser();
        System.out.println(user1);
        User user2 = User.getUser();
        System.out.println(user2);
}
class User{
    //1、私有化构造器
    private User() {
    }
    //2、内部提供一个当前类的实例,此实例也必须静态化
    private static User user = new User();
    //3、提供公共的静态的方法，返回当前类的对象；在内存中自始至终都存在
    public static User getUser() {
        return user;
    }
}
//结果是一样的，即同一个对象
com.gupao.singleton.User@6d6f6e28
com.gupao.singleton.User@6d6f6e28 

static变量在类加载的时候初始化，此时不会涉及到多个线程对象访问该对象的问题，虚拟机保证只会装载一次该类，肯定不会发生并发问题，无需使用synchronized 关键字

存在的问题：如果只是加载了本类，而并不需要调用getUser，则会造成资源的浪费。

总结：线程安全、非懒加载、效率高，资源浪费

懒汉式

延迟对象的创建

方式1：普通创建

public class Singleton {
    //私有构造方法
    private Singleton() {}

    //在成员位置创建该类的对象
    private static Singleton instance;

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

        if(instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

如果是多线程环境，以上代码会出现线程安全问题。

方式2：方法加锁

class Singleton {
    // 1.私有化构造器
    private Singleton() {
    }
    // 2.内部提供一个当前类的实例
    // 4.此实例也必须静态化
    private static Singleton instance;
    // 3.提供公共的静态的方法，返回当前类的对象
    public static synchronized Singleton getInstance() {//注意多线程情况
        if(instance== null) {
        instance= new Singleton();
        }
    return instance;
    }
}

以上使用同步方法会造成每次获取实例的线程都要等锁，会对系统性能造成影响，未能完全发挥系统性能，可使用同步代码块来解决

方式3：双重检查锁

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

public class Singleton { 

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

    private volatile static Singleton instance;

   //对外提供静态方法获取该对象
    public static Singleton getInstance() {
		//第一次判断，如果instance不为null，不进入抢锁阶段，直接返回实例
        if(instance == null) { // ①
            synchronized (Singleton.class) {
                //抢到锁之后再次判断是否为null
                if(instance == null) {
                    instance = new Singleton();// ②
                }
            }
        }
        return instance;
    }
}

为什么判断两次instance==null

第一次判断是在代码块前，第二次是进入代码块后，第二个判断想必都知道，多个线程都堵到代码块前等待锁的释放，进入代码块后要获取到最新的instance值，如果为空就进行创建对象。

那么为什么还要进行第一个判断，第一个判断起到优化作用，假设如果instance已经不为空了，那么没有第一个判断仍然会有线程堵在代码块前等待进一步判断，所以如果不为空，有了第一个判断就不用再去进入代码块进行判断，也就不用再去等锁了，直接返回。

为什么要加volatile？

1. 是为了防止指令重排序，给私有变量加 volatile 主要是为了防止第 ② 处执行时，也就是"instance = new Singleton()"执行时的指令重排序的，这行代码看似只是一个创建对象的过程，然而它的实际执行却分为以下 3 步：

   1. 创建内存空间。
   2. 在内存空间中初始化对象 Singleton。
   3. 将内存地址赋值给 instance 对象（执行了此步骤，instance 就不等于 null 了）。

   试想一下，如果不加 volatile，那么线程A在执行到上述代码的第 ② 处时就可能会执行指令重排序，将原本是 1、2、3 的执行顺序，重排为 1、3、2。但是特殊情况下，线程 A在执行完第 3 步之后，如果来了线程 B执行到上述代码的第 ① 处，判断 instance 对象已经不为 null，但此时线程 A还未将对象实例化完，那么线程B将会得到一个被实例化"一半"的对象，从而导致程序执行出错，这就是为什么要给私有变量添加 volatile 的原因了。

2. 优化作用，synchronized块只有执行完才会同步到主内存，那么比如说instance刚创建完成，不为空，但还没有跳出synchronized块，此时又有10000个线程调用方法，那么如果没有volatile,此使instance在主内存中仍然为空，这一万个线程仍然要通过第一次判断，进入代码块前进行等待，正是有了volatile，一旦instance改变，那么便会同步到主内存，即使没有出synchronized块，instance仍然同步到了主内存，通过不了第一个判断也就避免了新加的10000个线程进入去争取锁。

总结：线程安全、懒加载、效率高。

静态内部类（延迟初始化占位类）

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

public class Singleton {

    private Singleton() {
    }

    private static class SingletonHolder{
        private  static final Singleton Instance = new Singleton();
    }

    public static Singleton getInstance(){
        return SingletonHolder.Instance;
    }
}

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

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

总结：线程安全、懒加载、效率高。

枚举

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

public enum Singleton {

     INSTANCE;

}

提供了序列化机制，保证线程安全，绝对防止多次实例化，即使是在面对复杂的序列化或者反射攻击的时候。

枚举方式属于饿汉式方式，会浪费资源

总结：线程安全、非懒加载、效率高。

几种方式对比

方式	优点	缺点
饿汉式	线程安全、效率高	非懒加载，资源浪费
懒汉式synchronized方法	线程安全、懒加载	效率低
懒汉式双重检测	线程安全、懒加载、效率高	无
静态内部类	线程安全、懒加载、效率高	无
枚举	线程安全、效率高	非懒加载，资源浪费

Runtime类

Runtime类就是使用的单例设计模式。

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类使用的是饿汉式（静态属性）方式来实现单例模式的。

往期推荐

• 《SpringBoot》EasyExcel实现百万数据的导入导出
• 《SpringBoot》史上最全SpringBoot相关注解介绍
• Spring框架IoC核心详解
• 万字长文带你窥探Spring中所有的扩展点
• 如何实现一个通用的接口限流、防重、防抖机制
• 万字长文带你深入Redis底层数据结构
• volatile关键字最全原理剖析