适用场景：
无状态的工具类，很多工具类我们只需要一个实例，节省内存。但是大家的写法非常多，正确的写法却很少看见，希望看完这篇文章能够帮你梳理清楚。
饿汉式：不管你用的用不上，一开始就建立这个单例对象(就像一个饥饿的人)
懒汉式：是在你真正用到的时候才去建这个单例对象(就像一个懒惰的人)
1.饿汉式（静态常量）【可用】
/**
* 描述： 饿汉式（静态常量）（可用）
*/
public class Singleton1 {
private final static Singleton1 INSTANCE = new Singleton1();
private Singleton1() {
}
public static Singleton1 getInstance() {
return INSTANCE;
}
}
优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。
2.饿汉式（静态代码块）【可用】
/**
* 描述： 饿汉式（静态代码块）（可用）
*/
public class Singleton2 {
private final static Singleton2 INSTANCE;
static {
INSTANCE = new Singleton2();
}
private Singleton2() {
}
public static Singleton2 getInstance() {
return INSTANCE;
}
}
这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
3.懒汉式(线程不安全)【不可用】
/**
* 描述： 懒汉式（线程不安全）
*/
public class Singleton3 {
private static Singleton3 instance;
private Singleton3() {
}
public static Singleton3 getInstance() {
if (instance == null) {
instance = new Singleton3();
}
return instance;
}
}
这种写法起到了Lazy Loading的效果，但是只能在单线程下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会多次创建实例。所以在多线程环境下不可使用这种方式。
4.懒汉式(线程安全，同步方法)【不推荐用】
/**
* 描述： 懒汉式（线程安全）（不推荐）
*/
public class Singleton4 {
private static Singleton4 instance;
private Singleton4() {
}
public synchronized static Singleton4 getInstance() {
if (instance == null) {
instance = new Singleton4();
}
return instance;
}
}
解决上面第三种实现方式的线程不安全问题，做个线程同步就可以了，于是就对getInstance()方法进行了线程同步。
缺点：效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。方法进行同步效率太低要改进。
5.懒汉式(线程安全，同步代码块)【不可用】
/**
* 描述： 懒汉式（线程不安全）（不推荐）
*/
public class Singleton5 {
private static Singleton5 instance;
private Singleton5() {
}
public static Singleton5 getInstance() {
if (instance == null) {
synchronized (Singleton5.class) {
instance = new Singleton5();
}
}
return instance;
}
}
由于第四种实现方式同步效率太低，所以摒弃同步方法，改为同步产生实例化的的代码块。但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。
6.双重检查【推荐用】
/**
* 描述： 双重检查（推荐面试使用）
*/
public class Singleton6 {
private volatile static Singleton6 instance;
private Singleton6() {
}
public static Singleton6 getInstance() {
if (instance == null) {
synchronized (Singleton6.class) {
if (instance == null) {
instance = new Singleton6();
}
}
}
return instance;
}
}
Double-Check概念对于多线程开发者来说不会陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。这里的synchronized不能采用synchronized（this），因为getInstance是一个静态方法，在它内部不能使用未静态的或者未实例的类对象。
优点：线程安全；延迟加载；效率较高。
6.1 为什么要double-check
6.1.1 需要第二重的原因
考虑这样一种情况，就是有两个线程同时到达，即同时调用getInstance()方法，此时由于instance == null，所以很明显，两个线程都可以通过第一重的singleton== null，进入第一重if语句后，由于存在锁机制，所以会有一个线程进入lock语句并进入第二重 singleton == null，而另外的一个线程则会在lock语句的外面等待。
而当第一个线程执行完new Singleton（）语句后，便会退出锁定区域，此时，第二个线程便可以进入lock语句块，此时，如果没有第二重singleton == null的话，那么第二个线程还是可以调new Singleton（）语句，这样第二个线程也会创建一个Singleton实例，这样也还是违背了单例模式的初衷的，所以这里必须要使用双重检查锁定。
6.1.2 需要第一重的原因
细心的朋友一定会发现，如果去掉第一重singleton == null，程序还是可以在多线程下安全运行的。
考虑在没有第一重 singleton == null 的情况：当有两个线程同时到达，此时，由于 lock 机制的存在，假设第一个线程会进入lock语句块，并且可以顺利执行new Singleton（），当第一个线程退出lock语句块时，singleton这个静态变量已不为 null 了，所以当第二个线程进入lock时，会被第二重singleton == null挡在外面，而无法执行new Singleton（），以在没有第一重singleton == null的情况下，也是可以实现单例模式的。
那么为什么需要第一重singleton == null呢？
这里就涉及一个性能问题了，因为对于单例模式的话，new Singleton（）只需要执行一次就 OK 了，
而如果没有第一重singleton == null的话，每一次有线程进入getInstance（）时，均会执行锁定操作来实现线程同步，这是非常耗费性能的，而如果我加上第一重singleton == null的话，那么就只有在第一次执行锁定以实现线程同步，而以后的话，便只要直接返回 Singleton 实例就OK了，而根本无需再进入lock语句块了，这样就可以解决由线程同步带来的性能问题了。
6.1.3 为什么要用volatile
主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话做了下面 3 件事情：
1.给instance分配内存
2.调用Singleton的构造函数来初始化成员变量
3.将instance对象指向分配的内存空间（执行完这步instance就为非null了）
但是在JVM的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，已经线程一被调度器暂停，此时线程二刚刚进来第一重检查，看到的 instance 已经是非 null 了（但却没有初始化，里面的值可能是null/false/0，总之不是构造函数中指定的值），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错或者是看到了非预期的值（因为此时属性的值是默认值而不是所需要的值）。
不过，如果线程一已经从把synchronized 同步块的代码都执行完了，那么此时instance一定是正确构造后的实例了，这是由synchronized的heppens-before保证的。
7.静态内部类【推荐用】
/**
* 描述： 静态内部类方式，可用
*/
public class Singleton7 {
private Singleton7() {
}
private static class SingletonInstance {
private static final Singleton7 INSTANCE = new Singleton7();
}
public static Singleton7 getInstance() {
return SingletonInstance.INSTANCE;
}
}
这种方式跟饿汉式方式采用的机制类似，但又有不同。两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方在饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用，而静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
优点：避免了线程不安全，延迟加载，效率高。
8.枚举【推荐用】
/**
* 描述： 枚举单例
*/
public enum Singleton8 {
INSTANCE;
public void whatever() {
}
}
借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，还是懒加载，而且还能防止反序列化重新创建新的对象。
9.结论
枚举最好。《Effective Java》中明确表达过的观点：“使用枚举实现单例的方法虽然还没有广泛采用，但是单元素的枚举类型已经成为实现Singleton的最佳方法。”
10.为什么推荐枚举
10.1 写法简单
枚举比任何其他的写法都简单，很优雅。
10.2 线程安全有保障
我们定义的一个枚举，在第一次被真正用到的时候，会被虚拟机加载并初始化，而这个初始化过程是线程安全的。而我们知道，解决单例的并发问题，主要解决的就是初始化过程中的线程安全问题。
所以，由于枚举的以上特性，枚举实现的单例是天生线程安全的。
10.3 避免反序列化破坏单例
普通的Java类的反序列化过程中，会通过反射调用类的默认构造函数来初始化对象。所以，即使单例中构造函数是私有的，也会被反射给破坏掉。由于反序列化后的对象是重新new出来的，所以这就破坏了单例。但是，枚举的反序列化并不是通过反射实现的。所以，也就不会发生由于反序列化导致的单例破坏问题。