Java 单例模式
一、单例模式的应用
单例对象（Singleton）是一种常用的设计模式。在 Java 应用中，单例对象能保证在一个 JVM中，该对象只有一个实例存在。这样的模式有几个好处：
- 1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。
- 2、省去了 new 操作符，降低了系统内存的使用频率，减轻 GC 压力。
- 3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。
单例模式的应用有
- 网站的计数器，一般也是单例模式实现，否则难以同步。
- 应用程序的日志应用，一般都使用单例模式实现，这一般是由于共享的日志。文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
- 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。
- 项目中，读取配置文件的类，一般也只有一个对象。没有必要每次使用配置文件数据，都生成一个对象去读取。
- Application 也是单例的典型应用
- Windows的Task Manager (任务管理器)就是很典型的单例模式
- Windows的Recycle Bin (回收站)也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。
二、单例模式的实现
单例的实现主要是通过以下两个步骤：
- 将该类的构造方法定义为私有方法，这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例；
- 在该类内提供一个静态方法，当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。
1、饿汉式
// 饿汉式单例
public final class Singleton implements Serializable {
// 指向自己实例的私有静态引用，主动创建
private static Singleton INSTANCE = new Singleton();
// 私有的构造方法
private Singleton(){}
// 以自己实例为返回值的静态的公有方法，静态工厂方法
public static Singleton1 getSingleton1(){
return INSTANCE ;
}
public Object readResolve() {
return INSTANCE;
}
}
问题1 : 为什么加 final?
加final为了防止有子类, 因为子类可以重写父类的方法
问题2 : 如果实现了序列化接口, 还要做什么来防止反序列化破坏单例?
首先通过反序列化操作, 也是可以创建一个对象的, 破坏了单例, 可以使用readResolve方法并返回instance对象, 当反序列化的时候就会调用自己写的readResolve方法
问题3 : 为什么设置为私有?
私有化构造器, 防止外部通过构造器来创建对象; 但不能防止反射来创建对象
设置为私有是否能防止反射创建新的实例?
不能。暴力反射，但可以在改造构造方法，就可以防止反射破坏单例
private Singleton() {
if (INSTANCE != null) {
//防止反射破坏单例
throw new RuntimeException("单例对象不能重复创建");
}
System.out.println("private Singleton1()");
}
问题4 : 这样初始化是否能保证单例对象创建时的线程安全?
因为单例对象是static的, 静态成员变量的初始化操作是在类加载阶段完成, 由JVM保证其线程安全 (这其实是利用了ClassLoader的线程安全机制。ClassLoader的loadClass方法在加载类的时候使用了synchronized关键字。)
问题5 : 为什么提供静态方法而不是直接将 INSTANCE 设置为 public?
通过向外提供公共方法, 体现了更好的封装性, 可以在方法内实现懒加载的单例; 可以提供泛型等补充 : 任何一个readObject方法，不管是显式的还是默认的，它都会返回一个新建的实例，这个新建的实例不同于该类初始化时创建的实例。
枚举类实现饿汉式
枚举的变量, 底层是通过public static final来修饰的, 类加载就创建了,所以是饿汉式
问题1：枚举单例是如何限制实例个数的？
创建枚举类的时候就已经定义好了，每个枚举常量其实就是枚举类的一个静态成员变量
问题2：枚举单例在创建时是否有并发问题？
没有，枚举单例底层是静态成员变量，它是通过类加载器的加载而创建的, 确保了线程安全
问题3：枚举单例能否被反射破坏单例？
不能
问题4：枚举单例能否被反序列化破坏单例？
枚举类默认实现了序列化接口，枚举类已经考虑到此问题，无需担心破坏单例
问题5：枚举单例属于懒汉式还是饿汉式？
饿汉式
问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做？
加构造方法就行了
public enum Singleton {
INSTANCE;
private Singleton() {
System.out.println("private Singleton2()");
}
@Override
public String toString() {
return getClass().getName() + "@" + Integer.toHexString(hashCode());
}
public static Singleton getInstance() {
return INSTANCE;
}
public static void otherMethod() {
System.out.println("otherMethod()");
}
}
小结
我们知道，类加载的方式是按需加载，且加载一次。因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用；而且，由于这个类在整个生命周期中只会被加载一次，因此只会创建一个实例，即能够充分保证单例。
- 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
- 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。
2、懒汉式
public final class Singleton {
private Singleton() { }
private static Singleton INSTANCE = null;
public static Singleton getInstance() {
if( INSTANCE != null ){
return INSTANCE;
}
INSTANCE = new Singleton();
return INSTANCE;
}
}
我们从懒汉式单例可以看到，单例实例被延迟加载，即只有在真正使用的时候才会实例化一个对象并交给自己的引用。
这种写法起到了Lazy Loading的效果，但是只能在单线程下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。
饿汉式和懒汉式的局别也显而易见
饿汉式：
- 坏处：对象加载时间过长。
- 好处：饿汉式是线程安全的
懒汉式：
- 好处：延迟对象的创建。
- 目前的写法坏处：线程不安全。--->到多线程内容时，再修改
像懒汉式这样毫无线程安全保护的类，如果我们把它放入多线程的环境下，肯定就会出现问题了，如何解决？我们首先会想到对 getSingleton方法加synchronized 关键字，如下
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
但是，synchronized关键字锁住的是这个对象，这样的用法，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。我们改成下面这个：
双重锁机制实现懒汉式
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
似乎解决了之前提到的问题，将synchronized关键字加在了内部，也就是说当调用的时候是不需要加锁的，只有在instance为null，并创建对象的时候才需要加锁，性能有一定的提升。但是，这样的情况，还是有可能有问题的，看下面的情况：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例。这样就可能出错了，我们以A、B两个线程为例：
1>A、B线程同时进入了第一个if判断
2>A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton();
3>由于JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块。
4>B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。
5>此时B线程打算使用Singleton实例，却发现它没有被初始化，于是错误发生了。
为了解决上述构造方法指令出现重排序的问题，对 INSTANCE 使用 volatile 修饰，可以禁用指令重排。
public final class Singleton {
private Singleton() { }
private static volatile Singleton INSTANCE = null;
public static Singleton getInstance() {
// 实例没创建，才会进入内部的 synchronized代码块
if (INSTANCE == null) {
synchronized (Singleton.class) { // t2
// 也许有其它线程已经创建实例，所以再判断一次
if (INSTANCE == null) { // t1
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
单例模式使用内部类来维护单例的实现，JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心上面的问题。同时该方法也只会在第一次调用的时候使用互斥机制，这样就解决了低性能问题。这样我们暂时总结一个完美的单例模式：
静态内部类实现懒汉式
静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载, 并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。
public class Singleton {
/* 私有构造方法，防止被实例化 */
private Singleton() {
}
/* 此处使用一个内部类来维护单例*/
// 问题1：属于懒汉式还是饿汉式：懒汉式，这是一个静态内部类。
// 类加载本身就是懒惰的，在没有调用getInstance方法时是没有执行LazyHolder内部类的类加载操作的。
private static class SingletonFactory {
private static Singleton instance = new Singleton();
}
/* 获取实例 */
// 问题2：在创建时是否有并发问题，这是线程安全的，类加载时，jvm保证类加载操作的线程安全
public static Singleton getInstance() {
return SingletonFactory.instance;
}
/* 如果该对象被用于序列化，可以保证对象在序列化前后保持一致 */
public Object readResolve() {
return getInstance();
}
}
其实说它完美，也不一定，如果在构造函数中抛出异常，实例将永远得不到创建，也会出错。所以说，十分完美的东西是没有的，我们只能根据实际情况，选择最适合自己应用场景的实现方法。
也有人这样实现：因为我们只需要在创建类的时候进行同步，所以只要将创建和getInstance()分开，单独为创建加synchronized关键字，也是可以的：
public class SingletonTest {
private static SingletonTest instance = null;
private SingletonTest() {
}
private static synchronized void syncInit() {
if (instance == null) {
instance = new SingletonTest();
}
}
public static SingletonTest getInstance() {
if (instance == null) {
syncInit();
}
return instance;
}
}
考虑性能的话，整个程序只需创建一次实例，所以性能也不会有什么影响。
小结
从这四种实现中，我们可以总结出，要想实现效率高的线程安全的单例，我们必须注意以下两点：
- 尽量减少同步块的作用域；
- 尽量使用细粒度的锁。
