Java 单例模式的写法及优缺点getInstance

总结下Java单例模式的几种写法：

推荐：

public class Test{
    private static final String TAG = "Test";

    private volatile static Test instance = null;

    public static Test getInstance() {
          if (instance == null) {
               instance = new Test();
           }
        return instance;
    }
  }

1.饿汉式

public class Singleton
{

    private static Singleton instance = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() {
        return instance;
    }

}

优点：实现简单，不存在多线程问题，直接声明一个私有对象，然后对外提供一个获取对象的方法。
缺点：class 类在被加载的时候创建Singleton实例，如果对象创建后一直没有使用，则会浪费很大的内存空间，此方法不适合创建大对象。

2.懒汉式(线程不安全)

public class Singleton
{

    private static Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {

        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

}

优点：节省内存空间，在使用的时候才会创建；
缺点：线程不安全，在多线程下，可能会创建多个实例(一定要重视这个问题，有时候如果在单例对象的构造方法中做了某些重要操作，创建多个实例可能会造成可怕后果，如：打开Android的Sqlite数据库连接)。

3.懒汉式(线程安全)

public class Singleton
{

    private static Singleton instance = null;

    private Singleton() {}

    public synchronized static Singleton getInstance() {

        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

}

优点：支持多线程，且以懒汉式的方式加载，不浪费内存空间。

缺点：将 synchronized 块加在方法上，会影响并发量，每次调用getInstance()方法都会线程同步，效率十分低下。最重要的是，当创建好实例对象之后，就不必继续进行同步了。

4.懒汉式（double check）(线程安全，推荐)

public 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;
    }

}

优点：支持多线程，并发量高，且以懒汉式加载，不浪费内存空间。

缺点：一时找不出缺点，非要说缺点的话，就是实现比较麻烦。

在这里使用volatile会或多或少的影响性能，但考虑到程序的正确性，牺牲这点性能还是值得的。 DCL优点是资源利用率高，第一次执行getInstance时单例对象才被实例化，效率高。缺点是第一次加载时反应稍慢一些，在高并发环境下也有一定的缺陷，虽然发生的概率很小。DCL虽然在一定程度解决了资源的消耗和多余的同步，线程安全等问题，但是他还是在某些情况会出现失效的问题，**也就是DCL失效，在《Java并发编程实践》一书建议用静态内部类单例模式来替代DCL。**其实就是指令重排序的问题，所以使用volatile可以防止指令重排序

DCL失效的原因
LazyLoad，这种技巧很常用，就是指一个类包含某个成员变量，在类初始化的时候并不立即为该变量初始化一个实例，而是等到真正要使用到该变量的时候才初始化之。

class Foo {
  private Resource res = null;
  public Resource getResource() {
    if (res == null)
      res = new Resource();
    return res;
  }
}

在单线程环境下，一切都相安无事，但如果把上面的代码放到多线程环境下运行，那么就可能会出现问题。假设有2条线程，同时执行到了if(res == null)，那么很有可能res被初始化2次，为了避免这样的Race Condition，得用synchronized关键字把上面的方法同步起来。代码如下：

Class Foo {
  private Resource res = null;
  public synchronized Resource getResource() {
    if (res == null)
      res = new Resource();
    return res;
  }
}

synchronized过的方法在速度上要比未同步的方法慢上100倍，同时你也发现，只有第一次调用该方法的时候才需要同步，而一旦res初始化完成，同步完全没必要。所以你很快就把代码重构成了下面的样子：

Class Foo {
private Resource res = null;
private Date d = new Data();
  public Resource getResource() {
    if (res == null){                    //(1)
      synchronized(Foo.class){
        if(res == null){
          res = new Resource();         //(2)
		}
	  }
    }
    return res;
  }
}

Double-Checked Locking看起来是非常完美的。但是很遗憾，根据Java的语言规范，上面的代码是不可靠的。

出现上述问题, 最重要的2个原因如下:
1, 编译器优化了程序指令, 以加快cpu处理速度.
2, 多核cpu动态调整指令顺序, 以加快并行运算能力.
问题出现的顺序:
1, 线程A, 发现对象未实例化, 准备开始实例化
2, 由于编译器优化了程序指令, 允许对象在构造函数未调用完前, 将共享变量的引用指向部分构造的对象, 虽然对象未完全实例化, 但已经不为null了.
3, 线程B, 发现部分构造的对象已不是null, 则直接返回了该对象.

一个线程A运行到"这里"时,A的工作区中,肯定已经产生一个Foo对象,而且这时这个对象已经完成了Data d.现在线程A调用时间到,执行权被切换到另一个线程B来执行,会有什么问题呢?如果res不为null,线程B获得了一个res,但可能res.getD()却还没有初始化.
对于"这里"这条语句,线程A还没有离开同步块.因为没有"离开同步块"这个条件,线程A的工作区没有强制与主存储器同步,这时工作区中有两个字段res,d。虽然在线程A的工作区res和d都是完整的,但有JSL没有强制不允许先把res映射到主存储区,如果哪个jvm实现按它的优化方案先把工作存储器中的res同步到主存储器了,这时正好线程B获取了,而d却没有同步过去,那么线程B就获取了res的引用却找不能res.getD()。

5.静态内部类单例模式

public class Singleton { 
    private Singleton(){
    }
    public static Singleton getInstance(){  
        return SingletonHolder.instance;  
    }  
    private static class SingletonHolder {  
        private static final Singleton instance = new Singleton();  
    }  
} 

第一次加载Singleton类时并不会初始化单例，只有第一次调用getInstance方法时虚拟机加载SingletonHolder 并初始化单例 ，这样不仅能确保线程安全也能保证Singleton类实例的唯一性，所以推荐使用静态内部类单例模式。

总结
上述讲的其他几种单例模式实现中，有一种情况下他们会重新创建对象，那就是反序列化，将一个单例实例对象写到磁盘再读回来，从而获得了一个实例。反序列化操作提供了readResolve方法，这个方法可以让开发人员控制对象的反序列化。在上述的几个方法示例中如果要杜绝单例对象被反序列化是重新生成对象，就必须加入如下方法：

private Object readResolve() throws ObjectStreamException{
    return singleton;
}

推荐使用静态内部类实现，如果本身没有序列化的要求，按照之前实例代码的写法即可，如果需要支持序列化，则需要添加readResolve方法，如下

public class Singleton implements Serializable { 
    private Singleton(){
    }
      public static Singleton getInstance(){  
        return SingletonHolder.instance;  
    }  
    private static class SingletonHolder {  
        private static final Singleton instance = new Singleton();  
    }  
 
    private Object readResolve() throws ObjectStreamException {
        return SingletonHolder.instance;
    }
}