java多线程之单例模式和其DCL问题

    首先在说明单例设计模式中的DCL问题之前我们首先看看实现单例设计模式的两种方式：饿汉式和懒汉式。

    什么是饿汉式？

    饿汉式就是不管你是否用的上，一开始就先初始化对象（也叫做提前初始化）

代码示例：

public class EagerInitialization{    private static Resource resource = new Resource();    public static Resource getResource(){        return resource;    }}

    什么是懒汉式？

    懒汉式就是当你真正需要使用时才创建对象。

    于是，关于懒汉式的问题也就随之产生了～～～

    我们先看一下有问题的代码：

代码示例：

public class LazyInitialization{    private static Resource resource;    public static Resource getResource(){        if (resource == null)            resource = new Resource();//不安全！        return resource;    }}

    我们都知道上面的这个代码在单线程中运行是没有问题的，但是在平时的开发中常常会使用多线程，此时这个方法就会出现问题，假设有两个线程A、B，当A线程满足判断还未来得及执行到resource = new Resource()时，线程执行资格被B拿走，此时线程B进入getResource(),而此时它也满足resource的值为null,于是导致最后产生两个实例。

针对上面的问题，于是有了相应的解决方案，即线程安全的延迟初始化，可以解决懒汉式出现的上述问题：

代码示例：

public class LazyInitialization{    private static Resource resource;    public synchronized static Resource getResource(){        if (resource == null)            resource = new Resource();        return resource;    }}

    上面代码通过使用synchronized关键字将getResource变成同步函数来保证方法的原子性，从而保证了线程安全而防止最后多个线程产生多个实例的现象。

    我们都知道，在上述例子当中，每次在调用getResource()时都需要进行同步，而且在大多数时这种同步是没有必要的，并且大量无用的同步会对性能造成极大的影响。为什么呢？因为在第一次调用getResource()方法时就已经创建了resource实例了，之后resource就不再为空，然而之后再调用getResource时都需要进行同步，从而对性能造成了很大的影响。基于这些问题，一个新的方法也就产生了，这也是我们需要着重讨论的一个方法——双重检查加锁(Double Check Lock)DCL，首先我们看看DCL的真面目

示例代码：

public class DoubleCheckedLocking{    private static Resource resource;    public static Resource getResource(){        if (resource == null) {            synchronized (DoubleCheckedLocking.class) {                if (resource == null)                    resource = new Resource();            }        }        return resource;    }}

    你可能会疑惑，这样做不是挺好么，这样就可以解决刚刚说的那些问题了么，当resource被实例化后再调用getResource()方法不就不会再进行同步，这样不就节约了资源，提升了性能么？

    说的对，DCL确实存在着这些优点，但是与此同时，这个方法也会带来相应的问题，因为这个方法是含有缺陷的：

首先我们看到，DCL方法包含了层判断语句，第一层判断语句用于判断resource对象是否为空，也就是是否被实例化，如果为空时就进入同步代码块进一步判断，问题就出在了resource的实例化语句resource = new Resource()上，因为这个语句实际上不是原子性的。这句话可以大致分解为如下步骤：

1.给Resource的实例分配内存

2.初始化Resource构造器

3.将resource实例指向分配的内存空间，此时resource实例就不再为空

    我们都希望这条语句的执行顺序是上述的1——>2——>3，但是，由于Java编译器允许处理器乱序执行，以及JDK1.5之前JMM（Java Memory Medel，即Java内存模型）中Cache、寄存器到主内存回写顺序的规定，上面的第二点和第三点的顺序是无法保证的，也就是说，执行顺序可能是1——>2——>3也可能是1——>3——>2.如果有两个线程A和B，如果A线程执行完1后先执行3然后执行2，并且在3执行完毕、2未执行之前，被切换到线程B上，这时候resource因为已经在线程A内执行过了第三点，resource已经是非空了，所以线程B直接拿走resource，然后使用，然后顺理成章地报错，而且这种难以跟踪难以重现的错误很可能会隐藏很久。
    好了，关于DCL的问题阐述完了，那么这个方法既然有问题，那么该如何修改呢？在JMM的后续版本（Java 5.0及以上）中，如果把resource声明为volatile类型，因为volatile可以防止指令的重排序，那么这样就可以启用DCL，并且这种方式对性能的影响很小，因为volatile变量读取操作的性能通常只是略高于非volatile变量读取操作的性能。改进后的DCL方法如下代码所示

代码示例：

public class DoubleCheckedLocking{    private static volatile Resource resource;    public static Resource getResource{        if (resource == null) {            synchronized (DoubleCheckedLocking.class) {                if (resource == null)                    resource = new Resource();            }        }        return resource;    }}

    但是，DCL的这种方法已经被广泛地遗弃了，因为促使该模式出现的驱动力（无竞争同步的执行速度很慢，以及JVM启动时很慢）已经不复存在，因为它不是一种高效的优化措施。延迟初始化占位类模式能带来同样的优势，并且更容易理解，延迟初始化占位类模式代码如下：

代码示例：

public class ResourceFactory{    private static class ResourceHolder {        public static Resource resource = new Resource();    }    public static Resource getResource(){        return ResourceHolder.resource;    }}

    关于单例和DCL问题就分析到这里了，在实际开发当中由于经常要考虑到代码的效率和安全性，一般使用饿汉式和延长初始化占位类模式，而延迟占位类模式更是优势明显并且容易使用和理解，是良好的单例设计模式的实现方法。
参考资料：
《java并发编程实战》
关于volatile的问题可以参考：
http://blog.csdn.net/wxwzy738/article/details/43238089
关于DCL的其他问题可以参考：
http://blog.csdn.net/ns_code/article/details/17359719