[老实李] 单例也能讲出花来
单例的好处是什么？
- 节省创建时间，提高性能：对于频繁使用的对象，可以省略创建对象所花费的时间，这对于那些重量级的对象而言，是非常可观的一笔系统开销。
- 共享资源，全局使用：由于new操作的次数减少，因而对系统内存的使用频率也会降低，这将减轻GC压力，缩短GC停顿时间。
-
单例类只有一个实例：确保系统中某个对象的唯一性以及状态的一致性
所以对于系统的关键组件和被频繁操作的对象，使用单例模式便可以有效地改善系统性能。
实现一个单例有哪些方式？
1. 饿汉式
public class SingleTon {
private SingleTon() {
}
private static SingleTon instance = new SingleTon();
public static SingleTon getInstance() {
return instance;
}
}
这种方式和名字很贴切，饥不择食，在类装载的时候就创建，不管你用不用，先创建了再说，如果一直没有被使用，便浪费了空间，典型的空间换时间，每次调用的时候，就不需要再判断，节省了运行时间。
Java Runtime就是使用这种方式，它的源代码如下：
public class Runtime {
private static Runtime currentRuntime = new Runtime();
/**
* Returns the runtime object associated with the current Java application.
* Most of the methods of class <code>Runtime</code> are instance
* methods and must be invoked with respect to the current runtime object.
*
* @return the <code>Runtime</code> object associated with the current
* Java application.
*/
public static Runtime getRuntime() {
return currentRuntime;
}
/** Don't let anyone else instantiate this class */
private Runtime() {}
//以下代码省略
}
使用场景：
「饿汉式」是最简单的实现方式，这种实现方式适合那些在初始化时就要用到单例的情况，这种方式简单粗暴，如果单例对象初始化非常快，而且占用内存非常小的时候这种方式是比较合适的，可以直接在应用启动时加载并初始化。
但是，如果单例初始化的操作耗时比较长而应用对于启动速度又有要求，或者单例的占用内存比较大，再或者单例只是在某个特定场景的情况下才会被使用，而一般情况下是不会使用时，使用「饿汉式」的单例模式就是不合适的，这时候就需要用「懒汉式」的方式去按需延迟加载单例。
2. 懒汉式
懒汉式即实现延迟加载的单例，为上述饿汉式的优化形式。而因其仍需要进一步优化，往往成为面试考点，让我们一起来看看坑爹的“懒汉式”
懒汉式的最初形式是这样的：
public class Singleton {
private static Singleton INSTANCE;
private Singleton (){}
public static Singleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
return INSTANCE;
}
}
这种写法就轻松实现了单例的懒加载，只有调用了getInstance方法才会初始化。但是这样的写法出现了新的问题--线程不安全。当多个线程调用getInstance方法时，可能会创建多个实例，因此需要对其进行同步。
如何使其线程安全呢？简单，加个synchronized关键字就行了~
public static synchronized Singleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
return INSTANCE;
}
可是...这样又出现了性能问题，简单粗暴的同步整个方法，导致同一时间内只有一个线程能够调用getInstance方法。
因为仅仅需要对初始化部分的代码进行同步，所以再次进行优化：
public static Singleton getSingleton() {
if (INSTANCE == null) { // 第一次检查
synchronized (Singleton.class) {
if (INSTANCE == null) { // 第二次检查
INSTANCE = new Singleton();
}
}
}
return INSTANCE ;
}
执行两次检测很有必要：当多线程调用时，如果多个线程同时执行完了第一次检查，其中一个进入同步代码块创建了实例，后面的线程因第二次检测不会创建新实例。
这段代码看起来很完美，但仍旧存在问题，以下内容引用自黑桃夹克大神的如何正确地写出单例模式
这段代码看起来很完美，很可惜，它是有问题。主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。
- 给 instance 分配内存
- 调用 Singleton 的构造函数来初始化成员变量
- 将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）
但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。
so,我们只需要将 instance 变量声明成volatile就可以了。
！
Tips:
- 被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。
- 使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。
- 在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。
public class Singleton {
private volatile static Singleton INSTANCE; //声明成 volatile
private Singleton (){}
public static Singleton getSingleton() {
if (INSTANCE == null) {
synchronized (Singleton.class) {
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
3. 内部类实现单例
内部类实现单例，除了effctive java中阐述的枚举单例实现，这种方法是目前最好的实现方式。
在这个实现中，用内部类来保护单例，当Singleton类被加载时，内部类不会被初始化，所以可以确保Singleton类被载入JVM时，
不会初始化单例类，当getInstance方法被调用时，才会加载SingleHolder，从而初始化instance，同时，
由于实例的建立是在类加载时完成的，故天生对多线程友好，getInstance（）方法也不需要使用synchronized修饰，
因此，这种实现能兼顾前两种写法的优点（延迟加载，非同步）。
class SingleTon3 {
private SingleTon3() {
}
public static class SingletonHolder {
private static SingleTon3 singleTon3 = new SingleTon3();
}
public static synchronized SingleTon3 getInstance() {
return SingletonHolder.singleTon3;
}
}
4.枚举实现单例
枚举实现单例
下面的类SingleTon4是我们要应用单例模式的资源，具体可以表现为网络连接，数据库连接，线程池等等。 获取资源的方式很简单，只要Single.INSTANCE.getInstance()即可获得所要实例。
下面我们来看看单例是如何被保证的：
首先，在枚举中我们明确了构造方法限制为私有，在我们访问枚举实例时会执行构造方法，同时每个枚举实例都是static final类型的，也就表明只能被实例化一次。在调用构造方法时，我们的单例被实例化。
也就是说，因为enum中的实例被保证只会被实例化一次，所以我们的INSTANCE也被保证实例化一次。
public abstract class Enum<E extends Enum<E>> implements Comparable<E>, Serializable
枚举也提供了序列化机制。
class SingleTon4 {
}
enum Single {
INSTANCE;
private SingleTon4 instance;
Single() {
instance = new SingleTon4();
}
public SingleTon4 getInstance() {
return instance;
}
}
总结：
整个优化流程是 懒加载，但是线程不安全->方法上加上一个synchronized关键字线程安全了，但是有性能问题 ->
双重校验锁（DCL）解决了性能问题，但在 JVM 的即时编译器中存在指令重排序的优化,所以仍不完美 -> private volatile static Singleton INSTANCE; 声明成 volatile ，完美了
5.容器实现单例
public class SingletonManager {
private static Map<String, Object> hashMap = new HashMap<>();
public static void put(String key, Object value) {
if (!hashMap.containsKey(key)) {
hashMap.put(key, value);
}
}
public static Object get(String key) {
return hashMap.get(key);
}
}
在程序的初始，将多种单例类型注入到一个统一的管理类中，在使用时根据 key 获取对象对应类型的对象，这种方式使得我们可以管理多种多样的类型的单例。
