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

首先介绍一下单例模式： 
    单例模式（Singleton），也叫单子模式，是一种常用的软件设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。 

实现单例模式的思路是： 
    一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法（必须是静态方法，通常使用getInstance这个名 称）；当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用；同时我们 还将该类的构造函数定义为私有方法，这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例。 

需要注意的地方： 
    单例模式在多线程的 应用场合下必须小心使用。如果当唯一实例尚未创建时，有两个线程同时调用创建方法，那么它们同时没有检测到唯一实例的存在，从而同时各自创建了一个实例， 这样就有两个实例被构造出来，从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。 

    

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

    什么是饿汉式？

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

代码示例：

public class EagerInitialization{
    private 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的实例分配内存  |  memory = allocate()

2.初始化Resource构造器  |  ctorInstance(memory)

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

    我们都希望这条语句的执行顺序是上述的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的问题阐述完了，那么这个方法既然有问题，那么该如何修改呢？可以有两个办法来实现线程安全的延迟初始化：

1. 不允许2和3重排序
2. 允许2和3重排序，但不允许其他线程“看到”这个重排序

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

    当声明对象的引用为volatile后，2和3之间的重排序在多线程环境中将会被禁止。但是，DCL的这种方法已经被广泛地遗弃了，因为促使该模式出现的驱动力（无竞争同步的执行速度很慢，以及JVM启动时很慢）已经不复存在，因为它不是一种高效的优化措施（但基于volatile的双重检查锁定的方案由一个额外的优点：除了可以对静态字段实现延迟初始化外，还可以对实例字段实现延迟初始化）。延迟初始化占位类模式能带来同样的优势，并且更容易理解，延迟初始化占位类模式代码如下：

代码示例：
 

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

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁，这个锁可以同步多个线程对同一个类的初始化。

    关于单例和DCL问题就分析到这里了，在实际开发当中由于经常要考虑到代码的效率和安全性，一般使用饿汉式和延长初始化占位类模式，而延迟占位类模式更是优势明显并且容易使用和理解，是良好的单例设计模式的实现方法。
————————————————
优点： 
    1.在单例模式中，活动的单例只有一个实例，对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化，确保所有的对象都访问一个实例 
    2.单例模式具有一定的伸缩性，类自己来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。 
    3.提供了对唯一实例的受控访问。 
    4.由于在系统内存中只存在一个对象，因此可以 节约系统资源，当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。 
    5.允许可变数目的实例。 
    6.避免对共享资源的多重占用。 
缺点： 
    1.不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。 
    2.由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。 
    3.单例类的职责过重，在一定程度上违背了“单一职责原则”。 
    4.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。 
使用注意事项： 
    1.使用时不能用反射模式创建单例，否则会实例化一个新的对象 
    2.使用懒单例模式时注意线程安全问题 
    3.饿单例模式和懒单例模式构造方法都是私有的，因而是不能被继承的，有些单例模式可以被继承（如登记式模式） 
适用场景： 
    单例模式只允许创建一个对象，因此节省内存，加快对象访问速度，因此对象需要被公用的场合适合使用，如多个模块使用同一个数据源连接对象等等。如： 
    1.需要频繁实例化然后销毁的对象。 
    2.创建对象时耗时过多或者耗资源过多，但又经常用到的对象。 
    3.有状态的工具类对象。 
    4.频繁访问数据库或文件的对象。 

以下都是单例模式的经典使用场景： 
    1.资源共享的情况下，避免由于资源操作时导致的性能或损耗等。如上述中的日志文件，应用配置。 
    2.控制资源的情况下，方便资源之间的互相通信。如线程池等。 
应用场景举例： 
    1.外部资源：每台计算机有若干个打印机，但只能有一个PrinterSpooler，以避免两个打印作业同时输出到打印机。内部资源：大多数软件都有一个（或多个）属性文件存放系统配置，这样的系统应该有一个对象管理这些属性文件 
    2. Windows的Task Manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？ 不信你自己试试看哦~ 
    3. windows的Recycle Bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。 
    4. 网站的计数器，一般也是采用单例模式实现，否则难以同步。 
    5. 应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。 
    6. Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。 
    7. 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。 
    8. 多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。 
    9. 操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。 
    10. HttpApplication 也是单位例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式，所有的HttpModule都共享一个HttpApplication实例. 
　　 
实现单利模式的原则和过程： 
    1.单例模式：确保一个类只有一个实例，自行实例化并向系统提供这个实例 
    2.单例模式分类：饿单例模式（类加载时实例化一个对象给自己的引用），懒单例模式（调用取得实例的方法如getInstance时才会实例化对象）（java中饿单例模式性能优于懒单例模式，c++中一般使用懒单例模式） 
    3.单例模式要素： 
        a.私有构造方法 
        b.私有静态引用指向自己实例 
        c.以自己实例为返回值的公有静态方法