[老实李] 单例也能讲出花来

单例的好处是什么？

1. 节省创建时间，提高性能：对于频繁使用的对象，可以省略创建对象所花费的时间，这对于那些重量级的对象而言，是非常可观的一笔系统开销。
2. 共享资源，全局使用：由于new操作的次数减少，因而对系统内存的使用频率也会降低，这将减轻GC压力，缩短GC停顿时间。
3. 单例类只有一个实例：确保系统中某个对象的唯一性以及状态的一致性
   所以对于系统的关键组件和被频繁操作的对象，使用单例模式便可以有效地改善系统性能。

实现一个单例有哪些方式？

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 件事情。

1. 给 instance 分配内存
2. 调用 Singleton 的构造函数来初始化成员变量
3. 将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。
so,我们只需要将 instance 变量声明成 volatile 就可以了。
！
Tips:

1. 被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。
2. 使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。
3. 在 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 获取对象对应类型的对象，这种方式使得我们可以管理多种多样的类型的单例。