1. 单例模式概述
啥是设计模式?
设计模式好比象棋中的 “棋谱”. 红方当头炮, 黑方马来跳. 针对红方的一些走法, 黑方应招的时候有
一些固定的套路. 按照套路来走局势就不会吃亏.
软件开发中也有很多常见的 “问题场景”. 针对这些问题场景, 大佬们总结出了一些固定的套路. 按照
这个套路来实现代码, 也不会吃亏.
单例模式能保证某个类在程序中只存在唯一一份实例, 而不会创建出多个实例.
这一点在很多场景上都需要. 比如 JDBC 中的 DataSource 实例就只需要一个.
单例模式具体的实现方式, 分成 “饿汉” 和 “懒汉” 两种.
饿汉模式：在类加载阶段就把实例创建出来
懒汉模式：通过getInstance方法来获取到实例，首次调用该方法的时候，才真正创建实例。
2.单例模式实现
2.1 饿汉模式
在类加载阶段就把实例创建出来
static class Singleton { //把构造方法设为private，防止在类外面调用构造方法，也就禁止了调用者在其他地方创建实例的机会 private Singleton() { } private static Singleton instance=new Singleton(); public static Singleton getInstance() { return instance; } }
如果多个线程调用getInstance，是否出现问题呢？
此处认为是线程安全的，因为是多个线程读（只有return instance），不涉及修改。
2.2 懒汉模式-单线程版
类加载的时候不创建实例. 第一次使用的时候才创建实例
static class Singleton { private Singleton() {} private static Singleton instance=null; public static Singleton getInstance() { if(instance==null) { instance=new Singleton(); } return instance; } }
2.3 懒汉模式-多线程版
在上述2.2的代码示例中，如果实例已经创建完毕，后续再调用getInstance，此时不涉及修改操作，是线程安全的。
但是如果实例尚未创建，此时就可能会涉及到修改（分为两步 LOAD和SAVE），如果确实存在多个线程同时修改，就会涉及到线程安全问题。
如何解决这里的问题呢？
加锁
注意！！！
这是一种典型的错误写法，此处线程不安全主要是因为if操作和=操作不是原子的，我们加锁的目的是让代码具有原子性，就应该使用synchronized把这两个操作包裹上。
注意！！！
如果这样加锁，确实解决了线程安全问题，但是也引入了新问题，getInstance是首次调用的时候才涉及线程安全问题，在后续调用时就不涉及了（后续不存在修改操作了），所以如果我们按照刚才这个加锁方法，不仅仅时首次调用，包括后续的调用也会涉及到加锁操作
后续本来没有线程安全问题，不需要加锁，如果加锁便是多此一举，
加锁操作本身是一个开销比较大的操作，在不该加锁的地方加锁了，可能会让这个代码的速度降低很多倍。
2.4 懒汉模式-多线程版(改进)
为了解决2.3中提出的问题，以下代码在加锁的基础上, 做出了进一步改动:
使用双重 if 判定, 降低锁竞争的频率.
给 instance 加上了 volatile.
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; } }
理解双重 if 判定
加锁 / 解锁是一件开销比较高的事情. 而懒汉模式的线程不安全只是发生在首次创建实例的时候.
因此后续使用的时候, 不必再进行加锁了. 外层的 if 就是判定下看当前是否已经把 instance 实例创建出来了，如果已经创建出来了实例，就不必再加锁了，节省了开销。而里层的if判断是否要创建实例。
看起来两个if之隔了一行代码，但中间隔得是加锁操作，就很有可能隔得是“沧海桑田”（加锁有可能产生竞争，竞争就会导致阻塞，阻塞什么时候截止就不确定了）
理解volatile
同时为了避免 “内存可见性” 导致读取的 instance 出现偏差（后续批次的线程通过第一层if的时候，也需要判定instance的值，但是这个判定不一定是从内存读的数据，也可能是从寄存器读的数据）, 于是补充上 volatile .
下边我们通过一个一个例子来更好的理解：
当多线程首次调用 getInstance, 大家可能都发现 instance 为 null, 于是又继续往下执行来竞争锁,
其中竞争成功的线程, 再完成创建实例的操作.
当这个实例创建完了之后, 其他竞争到锁的线程就被里层 if 挡住了. 也就不会继续创建其他实例.
1.有三个线程, 开始执行 getInstance , 通过外层的 if (instance == null) 知道了实例还没有创建的消息. 于是开始竞争同一把锁
2.其中线程1 率先获取到锁, 此时线程1 通过里层的 if (instance == null) 进一步确认实例是否已经创建. 如果没创建, 就把这个实例创建出来.
3.当线程1 释放锁之后, 线程2 和 线程3 也拿到锁, 也通过里层的 if (instance == null) 来确认实例是否已经创建, 发现实例已经创建出来了, 就不再创建了.
4.后续的线程, 不必加锁, 直接就通过外层 if (instance == null) 就知道实例已经创建了, 从而不再尝试获取锁了. 降低了开销.
