彻底搞懂设计模式之—单例模式

单例简介

单例模式（Singleton Pattern），是一种创建型设计模式。它的定义为：保证一个类仅有一个实例，并提供一个访问它的全局访问点。它适用于以下场景：

• 需要频繁的进行创建和销毁的对象；
• 创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
• 工具类对象；
• 频繁访问数据库或文件的对象。

一般情况下我们会以为单例模式是GoF设计模式中最简单的，但实际上想要真正的写好一个适合自己系统的单例模式，还是需要一番考量的。比较经典的单例模式UML图如下：

从UML图来看，单例模式是最简单的设计模式。需要注意的点

• 私有的成员变量

• 私有的无参构造器

• 公有的获取单例的静态方法。

一般情况下单例模式分为懒汉式和饿汉式两种类型，但在这两种类型中又有很多种写法，并且除了常见的这两种类型还有一些我们平常想不到的类型。接下来将跟大家一起深入浅出这个单例大家族。

单例的9种写法及优缺点

饿汉式（均可用）

饿汉式单例顾名思义，就是汉子比较饿，得先给他吃的才能干活。也就是在应用启动的时候，就已经实例化好了。具体有下面的两种实现方式：

静态代码块实现

public class HungrySingleton {
    private HungrySingleton(){
    }
    private final static HungrySingleton hungrySingleton;
    static{
        hungrySingleton = new HungrySingleton();
    }
    public static HungrySingleton getInstances(){
        return hungrySingleton;
    }
}

静态常量实现

public class HungrySingleton{
    private HungrySingleton(){
    }
    private final static HungrySingleton hungrySingleton = new HungrySingleton();
    public static HungrySingleton getInstance(){
        return hungrySingleton;
    }
}

优点：类加载的时候就已经完成了初始化，调用方不用等待即可使用。在内存中也不存在线程安全问题。

缺点：因为没有lazy-loading的效果，如果该单例在应用当中从未被使用过，那就会造成内存的浪费现象。

懒汉式

懒汉式单例，顾名思义，这个汉子因为吃饱了比较懒，你只有在叫他的时候他才干活。应用在初始化完毕之后，懒汉式单例并不会初始化到内存中，只有第一次使用才会进行初始化。

经典饿汉式（不可用）

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

优点：写法简单，适合单线程。

缺点：在并发情况下拿到的实例就不一定是同一个了，这样也就失去了单例的效果。

因为在第1个线程执行if (lazySingleton==null)的时候，第二个或者第N个线程也有可能同样执行到了这一句，造成多个线程拿到多种实例的问题（可以在IDEA中通过多线程debug的方式明显的看出来）。那是不是在执行该语句的时候加锁就能解决呢？也就是下面的这种写法：

经典加锁懒汉式（可用，不推荐）

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

通过使用同步锁synchronized为getInstance()方法加锁，但是因为getInstance()是静态方法，那么synchronized就相当于锁住了整个LazySingleton类，所有的其他线程在使用getInstance()方法的时候必须等待第1个使用getInstance()方法的线程释放锁。它等效于下面的这种写法：

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

如果将加锁的语句写在了if (lazySingleton==null)这个判断里面，由于第1个线程在执行加锁之前，第2个或者第N个线程也进入到了getInstance()方法的if (lazySingleton==null)判断中，导致加锁失去意义，这点需要注意。

由于使用synchronized有加锁和解锁的开销，比较消耗资源。而且是对单例类的加锁，范围较大，对性能会造成一定影响。那如何去取得性能和多线程实例之间的平衡呢？接下来就是double-check模式的懒汉式单例登场了：

双重检查懒汉式（可用，推荐）

在synchronized同步锁的外部我们加一个实例是否为空的判断，就可以有一定的概率降低锁的使用频率。写法如下：

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

注意：上面的写法有个坑，在执行到lazySingleton = new LazyDoubleCheckSingleton()这一行的时候，JVM的操作具体有以下几个步骤：

① 为即将产生的对象分配内存，并产生特定的内存地址

② 初始化对象

③ 将初始化的对象lazySingleton指向第①步中的内存地址

由于JVM为了提高性能，存在指令重排序的功能，第②和第③个步骤可能会进行调换。也就是说当第1个线程在执行创建对象的时候，如果第2个线程也进入到了if (lazySingleton==null)这一行，那么lazySingleton会被认为不为空的，就会直接返回lazySingleton。但实际上这个实例还并没有创建好，第2个线程在使用这个实例的时候会产生问题。那如何解决这个问题呢？有两种思路：

​ 第1种就是禁止这种重排序；

​ 第2种就是将重排序的过程对线程的访问隔离开来(参见静态内部类懒汉式)。

首先看一下第1种写法，使用volatile修饰这个静态变量，禁止重排：

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

优点：能够实现懒汉式所要求的延迟加载功能，也是线程安全的，同时能够降低锁定整个类带来的性能开销。

静态内部类懒汉式(可用，推荐)

通过静态内部类的方法将重排序的过程对线程的访问隔离开来：

public class LazyStaticInnerClassSingleton {
    private LazyStaticInnerClassSingleton(){}
    private static class InnerClass{
        private static LazyStaticInnerClassSingleton singleton = new LazyStaticInnerClassSingleton();
    }
    public static LazyStaticInnerClassSingleton getInstance(){
        return InnerClass.singleton;
    }
}

上面的写法原理跟上面提到的**经典加锁饿汉式（可用，不推荐）**类似，使用静态内部类InnerClass也具有lazy-loading的效果，因为JVM初始化LazyStaticInnerClassSingleton的时候InnerClass并没有被装载，当第1个线程调用InnerClass的时候才会进行装载，而在装载的时候会对InnerClass进行加锁，其余的线程均需等待。当InnerClass中的静态变量singleton实例化完毕，锁才会释放，这样也就保证了线程的安全性。

容器单例（根据实际情况）

我们在实际应用当中，还会碰到一种集中式的单例：容器单例。当应用进行初始化的时候，将多种需要单例化的实例都放到一个容器当中。示例代码如下：

public class ContainerSingleton {
    private ContainerSingleton(){

    }
    private static Map<String,Object> singletonMap = new HashMap<String,Object>();
    public static void putInstance(String key,Object instance){
        if(StringUtils.isNotBlank(key) && instance != null){
            if(!singletonMap.containsKey(key)){
                singletonMap.put(key,instance);
            }
        }
    }
    public static Object getInstance(String key){
        return singletonMap.get(key);
    }
}

由于HashMap不是线程安全的，上面的容器单例不适合于多线程。可以使用HashTable代替，但由于HashTable每次存取都会使用同步锁，会有性能损耗。替代方案是使用ConcurrentHashMap。

在容器单例中有一种变种”单例“，它不是多线程安全的，但对每个独立的线程来说是安全的。比如线程A每次都能获取到单例1，线程B每次都会获取到单例2。不会出现线程A获取到单例2或者线程B获取到单例1的情况。实现方案就是使用ThreadLocal：

public class ThreadLocalInstance {
    private static final ThreadLocal<ThreadLocalInstance> threadLocalInstanceThreadLocal
            = new ThreadLocal<ThreadLocalInstance>(){
        @Override
        protected ThreadLocalInstance initialValue() {
            return new ThreadLocalInstance();
        }
    };
    private ThreadLocalInstance(){

    }
    public static ThreadLocalInstance getInstance(){
        return threadLocalInstanceThreadLocal.get();
    }

}

ThreadLocal对每个线程进行了锁定，隔离了多个线程对数据之间的访问冲突，线程之间获取的数据不会相互干扰，比加锁的方式要好一些。它不能够保证全局唯一，但能保证线程唯一。比如在org.apache.ibatis.executor.ErrorContext中，就使用了ThreadLocal。因为每个线程都保留了各自的错误上下文，所以在单个线程中产生错误的时候，不会出现在其他线程当中。如果都同步锁synchronized因为要排队，其实就是以时间换空间的方式。而Threadlocal其实就是以空间换时间的方式了。

我们常说的Spring容器跟这个又不太一样，容器中的Bean跟容器（ApplicationContext）密切相关，因为Spring容器的构造方法不是私有的，如果实例化了多个容器，那么Bean也会有多种实例。跟Bean的作用域是Singleton还是Prototype没有关系。如下面的例子：

//  第一个Spring Bean容器
ApplicationContext context_1 = new FileSystemXmlApplicationContext("classpath:/ApplicationContext.xml");
UserBean1 userBean_1 = context_1.getBean("userBean1", UserBean1.class);
//  第二个Spring Bean容器
ApplicationContext context_2 = new FileSystemXmlApplicationContext("classpath:/ApplicationContext.xml");
UserBean1 userBean_2 = context_2.getBean("userBean1", UserBean1.class);
//  这里绝对不会相等，因为创建了多个实例
System.out.println(userBean_1 == userBean_2);

结果为：false。

对单例的破坏

上面讨论的几种饿汉式和懒汉式中可用的单例看似没有问题，但在以下两种情况中还是会存在拿到多个实例问题，因为它们均会破坏单例。

序列化与反序列化

这里使用上面的饿汉式单例作为演示，序列化需要实现Serializable接口，代码示例如下：

HungrySingleton instance = HungrySingleton.getInstance();
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton_file"));
oos.writeObject(instance);

File file = new File("singleton_file");
ObjectInputStream ois = new ObjectInputStream(new FileInputStream(file));
HungrySingleton serilizeInstance = (HungrySingleton)ois.readObject();

System.out.println(instance == serilizeInstance);

输出结果为：false。问题出在ois.readObject()方法中。原因在于该方法调用的方法java.io.ObjectInputStream.readOrdinaryObject中，返值之前会调用java.io.ObjectStreamClass.isInstantiable方法进行判断是否通过反射产生一个新的对象，其判断依据就是实例是否实现了序列化。在这里HungrySingleTon肯定实现了序列化接口，导致产生新的实例。如果我们不做处理，就会返回新产生的实例。当产生新的实例之后，会在下面有个判断，原来的实例中是否有readResolve()这个方法，如果有，则返回原来的实例。感兴趣的读者可以跟着源码走一遍。

那么解决方法就是在HungrySingleton类中添加这个readResolve()方法：

public class HungrySingleton implements Serializable {
    private HungrySingleton(){
    }
    private final static HungrySingleton hungrySingleton = new HungrySingleton();
    public static HungrySingleton getInstance(){
        return hungrySingleton;
    }

    /**添加该方法可以防止反序列化造成的单例失效问题*/
    private Object readResolve(){
        return hungrySingleton;
    }
}

通过上面的分析我们知道，序列化和反序列化的过程中还是会生成一个新的实例，但不会被用上。我们最终拿到的还是原来的实例。所以，对于单例模式，最好不要使用序列化和反序列化，容易造成资源的浪费。

反射

其实通过上面的序列化与反序列化对单例的破坏分析过程就能看出来，万能的反射可以通过无参构造器获得一个新的实例来破坏单例。我们也可以自己写一段代码验证：

HungrySingleton instance = HungrySingleton.getInstance();
Class classObject =HungrySingleton.class;
Constructor constructor = classObject.getDeclaredConstructor();
//私有构造器的权限给放开
constructor.setAccessible(true);
HungrySingleton newHungryInstance = (HungrySingleton)constructor.newInstance();
System.out.println(instance==newHungryInstance);

结果不用猜想了：false。那如何解决呢？在使用构造器反射出一个新的HungrySingleton的时候，加一个是否为空的判断不就行了？

private HungrySingleton(){
    if (hungrySingleton!=null){
        throw new RuntimeException("私有构造器禁止反射！");
    }
}

测试结果达到了我们想要的结果，禁止了反射。那么，序列化和反序列化也将不会成功。这个方法适用于饿汉式单例，那对于懒汉式单例是否会生效呢？答案是不一定。如下例：

if (lazySingleton!=null){
    throw new RuntimeException("私有构造器禁止反射！");
}

Class clazz = LazySingleton.class;
Constructor lazyConstructor = clazz.getDeclaredConstructor();
lazyConstructor.setAccessible(true);
LazySingleton reflectLazySingleton = (LazySingleton)lazyConstructor.newInstance();

LazySingleton lazySingleton = LazySingleton.getInstance();
System.out.println(lazySingleton==reflectLazySingleton);

输出结果：fasle。为什么呢？因为反射先于懒汉调用，这个时候单例还没有实例化呢。当然，如果将上面的顺序反过来那就能禁止了，但这种先后顺序我们控制不了。如果我们在懒汉式单例中定义一个私有成员变量flag，然后根据flag进行判断是否禁止反射呢？答案是不行。因为反射也可以通过setAccessible拿到私有化的成员变量。那么如何彻底解决这个问题呢？答案是：枚举单例。

枚举单例（可用，推荐）

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

枚举是我们常用的一种类型，但很少人会想到使用它作为单例。其实枚举作为单例不但能够解决序列化与反序列化的问题，还能解决反射的问题，同时枚举也是线程安全的。因为在jdk源码中，枚举根本没有无参私有构造器，而且会有个判断：如果是枚举类，则不创建新的实例。加上jdk对枚举的序列化和反射都进行了特殊的处理，从而保证单例的唯一性。通过jad反编译查看：

public final class EnumSingleton extends Enum
{

    public static EnumSingleton[] values()
    {
        return (EnumSingleton[])$VALUES.clone();
    }

    public static EnumSingleton valueOf(String name)
    {
        return (EnumSingleton)Enum.valueOf(com/lc/test/designpattern/singleton/EnumSingleton, name);
    }

    private EnumSingleton(String s, int i)
    {
        super(s, i);
    }

    public static EnumSingleton getInstance()
    {
        return INSTANCE;
    }

    public static final EnumSingleton INSTANCE;
    private static final EnumSingleton $VALUES[];

    static 
    {
        INSTANCE = new EnumSingleton("INSTANCE", 0);
        $VALUES = (new EnumSingleton[] {
            INSTANCE
        });
    }
}

可以看出，枚举是通过静态代码块形成的饿汉式单例，那这样就失去了延迟加载的特性，如何解决呢？我们可以结合类的加载特点使用类似静态内部类的方式来实现：

• 升级版版

public class  LazyEnumSingleton {

	private LazyEnumSingleton(){};

	/**
	 * 内部类形式的枚举，可起到懒加载的类似效果
	 */
	private enum LazyEnumHolder{
		
		INSTANCE;

		private LazyEnumSingleton instance;

		LazyEnumHolder() {
			this.instance = new LazyEnumSingleton();
		}

		private LazyEnumSingleton getSingleton(){
			return this.instance;
		}
	}

	/**
	 * 提供单例的静态方法
	 */
	public static LazyEnumSingleton getInstance(){
		return LazyEnumHolder.INSTANCE.getSingleton();
	}
	
}

上面的这种写法是将枚举作为静态内部类的形式使用，但是又能避免单例模式的破坏，保证了延迟性、安全性、高效性，推荐~。

枚举单例的优点：final类型，不会被继承。真正的实现了多线程安全，防止了序列化反序列化和反射对单例的破坏。确保了内存中该类只存在一个对象，节省了系统资源。枚举单例，写起来还是比较优雅的。

缺点嘛，就是实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new，可能会给其他开发人员造成困扰，特别是看不到源码的时候。不过这个不是啥大问题，使用文档说明一下即可。

总结

通过对以上种种单例的分析过程，我们对单例有了一个比较全面的认识。在实际当中，需要根据系统的实际情况来选择到底使用哪一种。当然，本文也只是一家之言，如有错误和纰漏之处，还请大家批评指正，也欢迎大家补充和说明。