真的理解单例模式吗？
单例模式是设计模式中最常用也最简单的一种模式，相信很多程序员小伙伴在求职面试过程中都被面试官问到过单例模式。虽然它的定义和类结构非常简单，但是要实现一个完全没有问题的单例模式却没有那么简单；即使能写出一个合格有效的单例模式，要把其中的逻辑原理讲述清楚令面试官满意也不容易。
单例模式的实现方式有很多种，不同的实现方式能适应不同的应用场景。单线程中的单例比较简单，单例模式的复杂性主要是在多线程并发环境下要充分考虑对象访问的性能、线程安全等问题。如何实现高性能、线程安全、防攻击的单例模式？对于线程安全的单例实现方式，它们分别是怎样保证线程安全的？DCL的单例实现中synchronized和volatile关键字分别有什么作用？带着这些问题我再深入学习一下单例模式。
定义及特点
单例模式确保一个类只有一个实例，并提供一个全局访问方法。其类结构图如下：
单例模式是对象创建型模式，要实现一个单例类需满足以下几个要素：
（1） 一个私有的构造方法
（2） 一个指向自己实例的私有的静态引用
（3） 一个返回自己实例的公有的静态方法
所以一个单例类应该类似下面的伪代码：
public class Singleton {
private Singleton() {} //私有的构造方法
private static Singleton singleton; //指向自己实例的私有静态引用
public static Singleton getInstance() { //返回自己实例的公有静态方法
…… //创建本单例类的唯一实例，并赋值给私有静态引用
return singleton;
}
}
其实，按照定义的方式写出的单例模式并不能保证单例对象的唯一，可以通过以下方法破坏一个单例类的实例唯一性：
- 使用反射，虽然构造器为非公开，但是在反射面前就不起作用了。
- 如果单例的类实现了cloneable，那么还是可以拷贝出多个实例的。
- Java中的对象序列化也有可能导致创建多个实例。
- 使用多个类加载器加载单例类，也会导致创建多个实例并存的问题。
所以，如果要考虑单例类的防攻击，在实现时还需要做到防止反序列化、防止反射、防止克隆。
//readResolve method to preserve Singleton property
private Object readResolve() throws ObjectStreamException {
return INSTANCE;
}
//防止反射调用后创建新的Singleton实例
private static boolean flag = false;
private Singleton() {
synchronized(Singleton.class) {
if (!flag) {
flag = true;
} else {
throw new RuntimeException("单例模式被侵犯！");
}
}
}
//防止克隆产生新的实例
@Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException("Cannot clone instance of this class");
}
因为单例类对象的生命周期是从实例被创建到应用程序结束，所以一个高质量的单例类还需要满足以下特点：
√ 懒加载 —— 在需要时才创建单例类的实例
√ 线程安全 —— 应保证在多线程环境下访问单例类不会创建多个实例
√ 高性能 —— 获取单例对象的过程中应减少同步的消耗
适用场景
由于单例类保证一个类只有一个实例，并且由此表现出了一些其他优点，使得单例模式是在开发中比较常用的一种设计模式。根据单例类的优点，单例模式通常适用于以下场景的类创建：
● 需要频繁实例化然后销毁的对象
● 创建对象时耗时过多或者耗资源过多，但又经常用到的对象
● 有状态的工具类对象
● 频繁访问数据库或文件的对象
● 需要保证数据一致性的配置文件类或工具类对象
实现方式
根据单例模式的思想以及单例类能解决的问题，单例模式的实现方式有多种，不同的实现方式可能在单例对象的实例化时机、线程安全性和访问性能方面有所不同。下面分别整理各种实现方式及其优缺点。
饿汉式单例
public class Singleton {
private static Singleton instance=new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}
这种单例实现方法之所以被称为饿汉式是因为它利用JVM机制在单例类被加载时实例化。其实例化时机比较早，所以没有实现懒加载（Lazy Loading），即使这个实例在应用的生命周期内没有被使用到，也会因为已经被加载而占用一定的内存空间；另外这种实现方式也无法给单例的实例化过程传入必须的参数。饿汉式的实现方式比较简单，在单例类被加载到内存时就完成了实例化，避免了线程同步的问题；另外因为实例没有被使用而造成的内存浪费问题可以忽略，饿汉式单例的实现方式是被推荐使用的。
饿汉式单例的实例化过程还有一种写法，不过本质上也是利用JVM的类加载机制，只是语法的应用而已，如下：
private static Singleton instance = null;
static {
instance = new Singleton();
}
懒汉式单例
懒汉式单例的实现目的就是为了达到单例类的懒加载，即在单例类第一次被使用到的时候实例化该单例类，对应到单例类实现的基本要素就是在返回单例类实例的公有静态方法中去实例化单例对象。懒汉式单例的最直接最简单的实现如下：
public class Singleton {
private static Singleton instance=null;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
上述实现方式在实际项目中并不可取，因为它存在线程安全问题，当有多个线程去调用getInstance()方法获取Singleton的实例时，有可能得到的不是同一个对象，即有可能每个线程访问getInstance()方法时各自创建一个Singleton实例。要解决这种实现方式的线程安全问题，可以考虑加锁进行同步。
public class Singleton {
private static Singleton instance=null;
private Singleton() {};
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
上面的改进是在getInstance()方法上加锁进行同步，这样虽然解决了线程安全的问题，但又带来了访问效率低下的问题。每个线程在访问getInstance()方法获得类实例的时候，都要进行同步操作，而其实这个方法只需执行一次实例化代码就够了，只要单例对象还存在就可以直接return给访问者。对懒汉式单例进一步优化得到了既能保证线程安全又能有较高的访问效率的双重检查锁(Double Checked Locking)实现。
双重检测的单例
public class Singleton {
private static volatile Singleton instance=null;
private Singleton() {}
public static Singleton getInstance(){
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
双重检查锁的实现方式是比较健壮的懒汉式单例实现，有两个问题需要理解：
1、双重检查有什么意义
双重检查就是在getInstance()方法中有两次检查 instance == null，一次是在同步块外，一次是在同步块内。为什么在同步块内还要再检查一次？因为可能会有多个线程一起进入同步块外的 if，如果在同步块内不进行二次检查的话就会生成多个实例了。
假设有两个线程 A、B 同时调用 getInstance() 方法，他们会同时发现 instance == null ，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 A），另外一个线程则会处于等待状态（假设是线程 B）；线程 A 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。
2、静态引用instance前的volatile关键字有何作用
主要在于instance = new Singleton();这句并非是一个原子操作，在JVM中这句话大概做了下面 3 件事情：
① 分配一块内存空间M
② 调用 Singleton 的构造函数在内存M上创建对象
③ 将M的地址赋值给 instance 变量（执行完这步 instance 就为非 null 了）
但是在JVM的即时编译器中存在指令重排序的优化，也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 ①-②-③ 也可能是 ①-③-②。如果是后者，则在 ③ 执行完毕、② 未执行之前，线程二执行到同步快外的检查，这时 instance 已经是非 null 了，所以线程二会直接返回 instance，但却没有完成初始化。
volatile 修饰符具有禁止指令重排序优化的特性，也就是说在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 ①-②-③ 或者 ①-③-② 之后，不存在执行到 ①-③ 然后取到值的情况。从「先行发生原则（happens-before）」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。
静态内部类实现单例
public class Singleton{
private Singleton() {}
private static class SingletonHolder{
private static Singleton instance=new Singleton();
}
public static Singleton getInstance(){
return SingletonHolder.instance;
}
}
通过在类中创建一个静态内部类来实现单例模式也是利用了JVM的类加载机制保证只创建一份实例，同时与饿汉式单例一样具有线程安全性，而且客户在获取这个单例类实例的时候不会进行同步，没有性能缺陷，也不依赖 JDK 版本。静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时调getInstance()方法，才会装载SingletonHolder类实例化Singleton，这样就实现了单例类的懒加载。
由于使用静态内部类实现单例避免了线程不安全的问题，并且有较高的访问效率以及实现了延迟加载，这种方式是值得推荐的单例实现方式，当然这种方式与饿汉式单例一样不能传入参数。
枚举实现单例
public enum Singleton {
INSTANCE;
private Singleton() {}
public void method() {
}
}
从Java1.5版本起，创建单例可以使用简洁的枚举类型，我们直接通过Singleton.INSTANCE来访问实例。对于枚举类型，编译器会自动帮我们创建一个final类型的类继承自Enum类，并且该类中的几个属性被定义成static final，在static代码块中初始化那些属性，枚举类型通过Java类加载机制和初始化过程保证线程安全；而且通过jvm规范保证序列化，枚举还能防止反序列化或者反射攻击导致创建新的实例。《Effective Java》中更是说明单元素的枚举类型已经成为实现Singleton的最佳方法。
Kotlin单例实现
用Kotlin语言实现单例模式很简单，使用object关键字代替class关键字定义的类就是一个单例类。
object Singleton {
fun sayHello() {
Log.d("TAG", "Hello Kotlin")
}
init {
Log.d("TAG", "initialize the Kotlin class")
}
}
将Kotlin实现的单例类的字节码转成Java代码，如下图：
可见，上面的Kotlin单例类对应的Java代码其实是Java版本的饿汉式单例。单例对象在静态代码块中创建，单例类的静态引用被定义成public static final，因为在Java代码中访问这个单例对象时会调用它。如下分别是Kotlin和Java代码访问这个单例的方法：
//Kotlin 调用
Singleton.sayHello()
//Java 调用
Singleton.INSTANCE.sayHello();
用object关键字声明的单例类无法给单例的实例化过程传入参数，可借助Kotlin的伴生对象companion object来实现带参数的单例，因为伴生对象中的方法和属性被绑定到类上，通过类名直接访问，它将在类被加载的时候初始化。
如下用伴生对象带参数实现双重检测的单例类：
class Singleton private constructor(context: Context) {
companion object {
@Volatile
private var instance: Singleton? = null
fun getInstance(context: Context): Singleton {
if (instance != null) {
return instance as Singleton
}
return synchronized(this) {
if (instance != null) {
instance as Singleton
} else {
val created = Singleton(context)
instance = created
created
}
}
}
}
}
利用companion object还可以实现其他类型的单例模式的Kotlin版本。
单例模式小结
单例模式是类结构和模式思想最简单的一种设计模式，也是实际项目在被使用最多的一种模式，Android SDK的许多类以及许多第三方开源库都提供了很多有单例行为的类。单例模式的实现方式有多种，但在实际使用时需要认真考量单例类的线程安全性、访问效率和懒加载属性，所有的限制和设计都要保证Singleton类仅仅被实例化一次。
Thanks To:
如何正确地写出单例模式
Java设计模式—单例设计模式(Singleton Pattern)完全解析
单例模式讨论篇：单例模式与垃圾回收
Java中枚举的线程安全性及序列化问题
Kotlin下的5种单例模式