2020-11-20

一.什么是单例模式

        单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

注意：1、单例类只能有一个实例。2、单例类必须自己创建自己的唯一实例。3、单例类必须给所有其他对象提供这一实例。

所以要求：1.构造函数是私有的。2.判断系统是否已经有这个单例，如果有则返回，如果没有则创建。3.提供一个访问它的全局访问点。

二.常见的几种写法

       单例模式的写法主要从两点考虑，一是线程安全性，这是保证单例类在多线程环境下只能有一个实例的基础；二是懒加载，也就是只有当用到这个对象时才去进行实例化。

下面针对每种写法来细说：

         第一种（懒汉，线程不安全）：

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

这种写法首先实现了懒加载，只有在访问该实例时才会进行实例化操作。但是多线程环境下可能会存在多个实例，这也就不满足单例的本质了。所以不要用这种写法。

         第二种（懒汉，线程安全）：

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

这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，遗憾的是，效率很低，99%情况下不需要同步，只有第一次创建实例时需要同步。

         第三种（饿汉，线程安全）：

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

 这种方式基于classloder机制避免了多线程的同步问题（即双亲委派机制保证了同一个类在jvm中只会被加载一次），不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用getInstance方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance显然没有达到lazy loading的效果。

Java虚拟机规范中严格规定了有且只有五种情况必须对类进行初始化：

1、使用new字节码指令创建类的实例，或者使用getstatic、putstatic读取或设置一个静态字段的值（放入常量池中的常量除外），或者调用一个静态方法的时候，对应类必须进行过初始化。

2、通过java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则要首先进行初始化。

3、当初始化一个类的时候，如果发现其父类没有进行过初始化，则首先触发父类初始化。

4、当虚拟机启动时，用户需要指定一个主类（包含main()方法的类），虚拟机会首先初始化这个类。

5、使用jdk1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、RE_invokeStatic的方法句柄，并且这个方法句柄对应的类没有进行初始化，则需要先触发其初始化。

        第四种（静态内部类）：

public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); }   private Singleton (){}   public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } }

这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，它跟第三种方式不同的是（很细微的差别）：第三种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），而这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三种方式就显得很合理。

         第五种（双重检查锁）：

public class Singleton { private volatile static Singleton singleton;   private Singleton (){}   public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }

这个是第二种方式的升级版，俗称双重检查锁（DCL），首先可以很明显看到相对懒汉式降低了锁的粒度，然后实例用了volatail关键字修饰。下面就分析一下为什么要加volatail；

首先先看一下java的内存模型：

 

volatile 可以说是 JVM 提供的最轻量级的同步机制，当一个变量定义为volatile之后，它将具备两种特性：

保证此变量对所有线程的可见性。当修改volatile变量时，会给cpu发送一个信号告诉其他cpu这个变量已修改，当其他cpu调用这个变量时，就会先检查是否有收到修改该变量的信号，有则重新从内存中读取。MESI协议。

禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

然后再来看实例化对象的那行代码，实际上可以分解成以下三个步骤：

1. 分配内存空间
2. 初始化对象
3. 将对象指向刚分配的内存空间

但是有些编译器为了性能的原因，可能会将第二步和第三步进行重排序，顺序就成了：

1. 分配内存空间
2. 将对象指向刚分配的内存空间
3. 初始化对象

现在考虑重排序后，两个线程发生了以下调用：

Time	Thread A	Thread B
T1	检查到singleton为空
T2	获取锁
T3	再次检查到singleton为空
T4	为singleton分配内存空间
T5	将uniqueSingleton指向内存空间
T6		检查到singleton不为空
T7		访问singleton（此时对象还未完成初始化）
T8	初始化singleton

在这种情况下，T7时刻线程B对uniqueSingleton的访问，访问的是一个初始化未完成的对象。使用了volatile关键字后，重排序被禁止，所有的写（write）操作都将发生在读（read）操作之前。在JDK1.5之后，双重检查锁定才能够正常达到单例效果。JDK1.5 采用新的内存模型JSR133,JSR133定义happen before原则。

 

目前来看上面几种实现方式已经适合日常开发的写法了，但是还是有两个需要考虑的问题：

1.如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。假定不是远端存取，例如一些servlet容器对每个servlet使用完全不同的类装载器，这样的话如果有两个servlet访问一个单例类，它们就都会有各自的实例。

2.如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能通过反射被序列化和复原。不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。

public class Singleton implements java.io.Serializable { private static Singleton singleton; //防止利用反射调用构造器创建对象 private Singleton() { if (singleton != null) { throw new RuntimeException("不可创建实例对象"); } } public static Singleton getInstance() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } //防止单例由不同的类装载器装入，那便有可能存在多个单例类的实例 private static Class getClass(String classname) throws ClassNotFoundException { ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); if (classLoader == null) classLoader = Singleton.class.getClassLoader(); return (classLoader.loadClass(classname)); } //如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。 //不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。 private Object readResolve() { return singleton; } }

         第六种（枚举）：

public enum Singleton { INSTANCE; public void whateverMethod() {} }

这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。

在StakcOverflow中，有一个关于What is an efficient way to implement a singleton pattern in Java?的讨论：得票率最高的就是枚举类实现方式。

那么枚举类是如何保证线程安全且只有一个实例的呢？

 

对Singleton进行反编译可以得到如下java类：

 

public final class Singleton extends Enum<Singleton> {
      public static final Singleton SINGLETON;
      public static Singleton[] values();
      public static Singleton valueOf(String s);
      static {};
}

 

由反编译后的代码可知，static类型的属性会在类被加载之后被初始化，当一个Java类第一次被真正使用到的时候静态资源被初始化、Java类的加载和初始化过程都是线程安全的（因为虚拟机在加载枚举的类的时候，会使用ClassLoader的loadClass方法，而这个方法使用同步代码块保证了线程安全）。所以，创建一个enum类型是线程安全的。

 

前面我们提到过，就是使用双重检查锁实现的单例其实是存在一定问题的，就是这种单例有可能被序列化所破坏，那么枚举是如何解决这个问题的呢

 

Java规范中规定，每一个枚举类型极其定义的枚举变量在JVM中都是唯一的，因此在枚举类型的序列化和反序列化上，Java做了特殊的规定。 

普通的Java类的反序列化过程中，会通过反射调用类的默认构造函数来初始化对象。所以，即使单例中构造函数是私有的，也会被反射给破坏掉。
枚举类在序列化的时候Java仅仅是将枚举对象的name属性输出到结果中，反序列化的时候则是通过 java.lang.Enum 的 valueOf() 方法来根据名字查找枚举对象。

 

已上就是常见的几种单例模式的实现方式，最后来看一下Spring中用的是哪种方式吧。