必知必会的单例模式

在开发过程中，有些对象我们至始至终只需要一个实例，比如配置文件、工具类、线程池、缓存、日志对象等，如果创造多个实例，就会导致许多问题，比如占用过多资源，不一致的结果等。

基于以上的问题，单例模式应运而生了，下面来看看单例的实现方式吧。

v1.0（非线程安全懒汉版）

package com.v1;
public class Singleton {
    // 私有构造方法
    private Singleton() {
    }
    // 单例对象
    private static Singleton instance = null;
    // 公共的静态工厂方法
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

要使一个类只能构建一个实例对象，理所当然的能想到不能随便的创建对象即new操作，所以构造方法是私有的。
instance是Singleton类的静态成员，也是类中的单例对象。它的初始值可以写成Null，也可以写成new Singleton()。至于其中的区别，后面的内容会做解释。

getInstance是获取单例对象的方法。如果单例初始值是null，还未构建，则构建单例对象并返回。这个写法属于单例模式当中的懒汉模式。懒汉嘛，很懒，用到时才去构建。

如果单例对象一开始就被new Singleton()主动构建，则不再需要判空操作，这种写法属于饿汉模式。饿汉呢，很饥渴，主动去构建对象。

那么这段单例模式的代码有没问题呢？答案是肯定的，而且问题还是大大的，因为上述的代码不能保证线程安全性。
那为什么说上述的代码不是线程安全的呢？
假设现在有两个线程（线程A和B）同时去访问Singleton类，而Singleton类才刚被初始化，instance对象还是null。A、B线程同时执行到“if (instance == null) {”时，因为instance对象是空，所以两个线程同时通过了if条件判断，进入到下一步new对象的操作。然后AB线程各自new出一个对象来，违背了单例的初衷。
为了解决线程安全问题，于是对代码稍作修改，如下：

v2.0（有隐藏问题的线程安全懒汉版）

package com.v2;
public class Singleton {
    // 私有构造方法
    private Singleton() {
    }
    // 单例对象
    private static Singleton instance = null;
    // 公共的静态工厂方法
    public static Singleton getInstance() {
        // 双重校验机制
        if (instance == null) {
            // 同步锁
            synchronized (Singleton.class) { 
                // 双重校验机制
                if (instance == null) { 
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

为了防止new Singleton被执行多次，因此在new操作之前加上Synchronized 同步锁，保持线程间的同步。
进入Synchronized 临界区以后，还要再做一次判空。因为当两个线程同时访问的时候，线程A构建完对象，线程B也已经通过了最初的判空验证，不做第二次判空的话，线程B还是会再次构建instance对象，像这样两次判空的机制就是双重校验机制。

v2.0版的代码表面上看着没问题，但是还是有隐藏的问题。
假设下这样的情形，当线程A在执行第一个“if (instance == null) {”判空时，而线程B正在执行new Singleton()构建对象操作。这种情况表面看似没什么问题，要么Instance还没被线程A构建，线程B执行 if（instance == null）的时候得到false；要么Instance已经被线程A构建完成，线程B执行 if（instance == null）的时候得到true。

真的是这样执行的吗？再一次提出质疑，答案是否定的。
这里涉及到了JVM编译器的指令重排序。
比如java中简单的一句 instance = new Singleton，会被编译器编译成如下三个步骤：

1. memory =allocate(); //第一步：分配对象的内存空间
2. ctorInstance(memory); //第二步：初始化对象
3. instance =memory; //第三步：设置instance指向刚分配的内存地址

但是这些指令顺序并非一成不变，有可能会经过JVM和CPU的优化，指令重排成下面的顺序：

1. memory =allocate(); //第一步：分配对象的内存空间
2. instance =memory; //第三步：设置instance指向刚分配的内存地址
3. ctorInstance(memory); //第二步：初始化对象

当线程A执行完第一步和第三步时，instance对象还未完成初始化，但已经不再指向null。此时如果线程B抢占到CPU资源，执行 if（instance == null）的结果会是false，从而返回一个没有初始化完成的instance对象。

针对以上的问题，我们再对代码稍作优化。

v3.0（线程安全懒汉版）

package com.v3;
public class Singleton {
    // 私有构造方法
    private Singleton() {
    }
    // 单例对象
    private static volatile Singleton instance = null;
    // 公共的静态工厂方法
    public static Singleton getInstance() {
        // 双重校验机制
        if (instance == null) {
            // 同步锁
            synchronized (Singleton.class) { 
                // 双重校验机制
                if (instance == null) { 
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

我们在instance对象前面增加一个修饰符volatile。
volatile修饰符是啥意思？volatile阻止了变量访问前后的指令重排序，保证了指令执行顺序。
经过volatile的修饰，当线程A执行instance = new Singleton的时候，JVM执行顺序是什么样？始终保证是下面的顺序：

1. memory =allocate(); //第一步：分配对象的内存空间
2. ctorInstance(memory); //第二步：初始化对象
3. instance =memory; //第三步：设置instance指向刚分配的内存地址

如此在线程B看来，instance对象的引用要么指向null，要么指向一个初始化完毕的Instance，而不会出现某个中间态，保证了安全。

好了，经过volatile修饰的变量，防止指令重排序引发的初始化问题，再加上双重校验锁机制，进一步确保在并发情形下对象不会重复初始化。下面再看看其他形式的单例模式实现。

v4.0（静态内部类版）

package com.v4;

public class Singleton {
    // 静态内部类
    private static class LazyHolder {
        // 私有静态常量初始化
        private static final Singleton INSTANCE = new Singleton();
    }
    // 私有构造方法
    private Singleton() {
    }
    // 公共静态工厂方法
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE;
    }
}

从外部无法访问静态内部类LazyHolder，只有当调用Singleton.getInstance方法的时候，才能得到单例对象INSTANCE。

INSTANCE对象初始化的时机并不是在单例类Singleton被加载的时候，而是在调用getInstance方法，使得静态内部类LazyHolder被加载的时候。因此这种实现方式是利用classloader的加载机制来实现懒加载，并保证构建单例的线程安全。

静态内部类的实现方式虽然好，但是存在着以上几种单例模式共同的问题：无法防止反射来重复构建对象。

我们来看下怎么使用反射来打破单例模式的束缚。

        //获得构造器
        Constructor con = Singleton.class.getDeclaredConstructor();
        //设置为可访问
        con.setAccessible(true);
        //构造两个不同的对象
        Singleton singleton1 = (Singleton)con.newInstance();
        Singleton singleton2 = (Singleton)con.newInstance();
        //验证是否是不同对象
        System.out.println(singleton1.equals(singleton2));

这段代码，简单的说就是利用java的反射机制构造对象，再判断是否是两个相同的对象。运行结果可想而知，是false。

那么怎样可以阻止反射机制构造对象呢？可以使用枚举的方式实现单例。

v5.0（枚举版）

public enum SingletonEnum {
    INSTANCE;
}

使用枚举实现的单例，再使用反射的方式去构造对象的时候，运行会报异常，因为JVM会阻止反射获取枚举类的私有构造方法。

所以使用枚举实现的单例模式不仅可以防止反射构造对象，还可以保证线程安全性，而且代码也很简洁。

需要注意的是枚举并非使用懒加载的方式，它的对象是在枚举类被加载的时候进行初始化的。

好了，几种单例的实现方式讲完了，做个简要的总结：

1. 使用双重校验锁实现的单例，其初始化对象需volatile修饰，以保证防止指令重排序。

2. 静态内部类方式和饿汉懒汉方式都无法避免利用反射构造不同的对象，利用枚举实现单例，既安全又简洁。