设计模式-单例

设计模式-单例
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
1.懒汉单例模式：

    public class Singleton{
        private static Singleton instance;
        private Singleton(){
        }
        public static synchronized Singleton getInstance(){
        if(instance==null){
        instance=new Singleton();
        }
        return instance;
        }
        }

    懒汉模式的优点是只有在使用的时候才会被实例化，在一定程度上节约了资源，缺点是在第一次加载的时候需要及时进行
实例化，反应稍慢，最大的问题是每次调用getInstance 都进行同步，造成不必要的同步开销。
2.Double Check Lock (DCL) 单例模式：
    DCL 单例模式的优点是既能够在需要时候才初始化单例，又能够保证线程安全，且单例对象初始化后调用getInstance
不进行同步锁。

        public class Singleton{
        private volatile static  Singleton instance=null;
        private Singleton(){
        }
        public static Singleton getInstance(){
        if(instance==null){
        synchronized(Singleton.class){
        if(instance==null){
        instance=new Singleton();
        }
        }   
        }
        return instance;
        }
        }

    该模式中对instance进行了两次非空判断，第一层主要为了避免不必要的同步，第二层是判断在null的情况下创建实例。
    下面分析一下两层null判断的必要性：
假设线程A执行到 instance = new Singleton(); 这里看起来是一句代码，但实际上它并不是一个原子操作，它会编译
成多条汇编指令，大致做了3件事：
(1)给Singleton实例分配内存；
(2)调用Singleton的构造函数，初始化成员字段；
(3)将instance对象指向分配的内存空间（此时instance!=null）
但是，由于Java编译器允许处理器乱序执行，以及JDK1.5之前JMM中Cache、寄存器到主内存回写顺序的规定，上面2、3的
执行顺序是无法保证的。也就是，执行顺序可能为1-2-3也可能为1-3-2。如果是后者，当a线程3执行完2未执行，被切换
到B线程上，这时候A线程已经执行了3instance不为null，B线程直接取instance就会报错，这就是DCL失效问题。

    在JDK1.5之后，SUN官方已经注意到这种问题，调整了JVM，具体化了volatile关键字。因此在JDK1.5或之后的版本中，声明一个 volatile 类型的对象，可以保证该对象的每次读取都是从主内存中读取。DCL模式是使用最多的单例模式。

3.静态内部类单例模式
DCL虽然在一定程度上解决了资源消耗、多余同步、线程安全等问题，但是，它还是在某些情况下出现失效问题。这个问题被称为双重检查锁(DCL)失效，在《Java 并发编程实践》一书中最后谈到该问题，指出这种“优化”是丑陋的，不赞成使用。而建议用如下的代码替代：

    public class Singleton{
    private Singleton(){}
    public static Singleton getInstance(){
    return SingletonHolder.instance;
    }
    /**
     * 静态内部类
     */
    private static class SingletonHolder{
        private static final Singleton instance = new Singleton();
    }
    }

这种方式不仅能够保证线程安全，也能够保证单例对象的唯一性，同时也延迟了单例的实例化。