设计模式-单例

设计模式-单例
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
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();    }    }

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