`

单例模式

阅读更多

前面说提到的五种创建模式,主要解决的问题是如何创建对象,获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。

Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集群、远程EJB等)时、涉及到单例对象被销毁后重建等。对于复杂的情况,本章中会涉及到其中一些[1]

目的:

希望对象只创建一个实例,并且提供一个全局的访问点。

场景:

Kerrigan对于Zerg来说是个至关重要的灵魂人物,无数的DroneZerglingHydralisk……可以被创造、被牺牲,但是Kerrigan得存在关系到Zerg在这局游戏中的生存,而且Kerrigan是不允许被多次创造的,必须有且只有一个虫族刀锋女王的实例存在,这不是游戏规则,但这是个政治问题。

分析:

如前面一样,我们还是尝试使用代码来描述访问Kerrigan的过程,看看下面的UML图,简单得我都不怎么好意思放上来占版面。

6.1 单例模式的UML

结构是简单的,只是我们还有一些小小的要求如下:

1.最基本要求:每次从getInstance()都能返回一个且唯一的一个Kerrigan对象。

2.稍微高一点的要求:Kerrigan很忙,很多人找,所以希望这个方法能适应多线程并发访问。

3.再提高一点的要求:Zerg是讲究公务员效率的社会,希望找Kerrigan的方法性能尽可能高。

4.最后一点要求是Kerrigan自己提出的:体谅到Kerrigan太累,希望多些睡觉时间,因此Kerrigan希望实现懒加载(Lazy Load),在需要的时候才被构造。

5.原本打算说还提要处理多ClassLoader、多JVM等情况,不过还是不要把情况考虑的太复杂了,暂且先放过作者吧(-_-#)。

我们第一次写的单例模式是下面这个样子的:

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第一次尝试
  3. */
  4. public class SingletonKerriganA {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganA instance = null;
  9. public static SingletonKerriganA getInstance() {
  10. if (instance == null) { //line A
  11. instance = new SingletonKerriganA(); //line B
  12. }
  13. return instance;
  14. }
  15. }
/**
 * 实现单例访问Kerrigan的第一次尝试
 */
public class SingletonKerriganA {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganA instance = null;
 
    public static SingletonKerriganA getInstance() {
        if (instance == null) {                              //line A
            instance = new SingletonKerriganA();          //line B
        }
        return instance;
    }
}

 

这个写法我们把四点需求从上往下检测,发现第二点的时候就出了问题,假设这样的场景:两个线程并发调用SingletonKerriganA.getInstance(),假设线程一先判断完instance是否为null,既代码中的line A进入到line B的位置。刚刚判断完毕后,JVMCPU资源切换给线程二,由于线程一还没执行line B,所以instance仍然是空的,因此线程二执行了new SignletonKerriganA()操作。片刻之后,线程一被重新唤醒,它执行的仍然是new SignletonKerriganA()操作,好了,问题来了,两个Kerrigan谁是李逵谁是李鬼?

紧接着,我们做单例模式的第二次尝试:

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第二次尝试
  3. */
  4. public class SingletonKerriganB {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganB instance = null;
  9. public synchronized static SingletonKerriganB getInstance() {
  10. if (instance == null) {
  11. instance = new SingletonKerriganB();
  12. }
  13. return instance;
  14. }
  15. }
/**
 * 实现单例访问Kerrigan的第二次尝试
 */
public class SingletonKerriganB {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganB instance = null;
 
    public synchronized static SingletonKerriganB getInstance() {
        if (instance == null) {
            instance = new SingletonKerriganB();
        }
        return instance;
    }
}

 

比起第一段代码仅仅在方法中多了一个synchronized修饰符,现在可以保证不会出线程问题了。但是这里有个很大(至少耗时比例上很大)的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数之外,以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是很小的,绝大部分的耗时都用在synchronized修饰符的同步准备上,因此从性能上说很不划算。

那继续把代码改成下面的样子:

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第三次尝试
  3. */
  4. public class SingletonKerriganC {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganC instance = null;
  9. public static SingletonKerriganC getInstance() {
  10. synchronized (SingletonKerriganC.class) {
  11. if (instance == null) {
  12. instance = new SingletonKerriganC();
  13. }
  14. }
  15. return instance;
  16. }
  17. }
/**
 * 实现单例访问Kerrigan的第三次尝试
 */
public class SingletonKerriganC {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganC instance = null;
 
    public static SingletonKerriganC getInstance() {
        synchronized (SingletonKerriganC.class) {
            if (instance == null) {
                instance = new SingletonKerriganC();
            }
        }
        return instance;
    }
}

 

基本上,把synchronized移动到代码内部是没有什么意义的,每次调用getInstance()还是要进行同步。同步本身没有问题,但是我们只希望在第一次创建Kerrigan实例的时候进行同步,因此我们有了下面的写法——双重锁定检查(DCL)。

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第四次尝试
  3. */
  4. public class SingletonKerriganD {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganD instance = null;
  9. public static SingletonKerriganD getInstance() {
  10. if (instance == null) {
  11. synchronized (SingletonKerriganD.class) {
  12. if (instance == null) {
  13. instance = new SingletonKerriganD();
  14. }
  15. }
  16. }
  17. return instance;
  18. }
  19. }
/**
 * 实现单例访问Kerrigan的第四次尝试
 */
public class SingletonKerriganD {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganD instance = null;
 
    public static SingletonKerriganD getInstance() {
        if (instance == null) {
            synchronized (SingletonKerriganD.class) {
                if (instance == null) {
                    instance = new SingletonKerriganD();
                }
            }
        }
        return instance;
    }
}

 

看起来这样已经达到了我们的要求,除了第一次创建对象之外,其他的访问在第一个if中就返回了,因此不会走到同步块中。已经完美了吗?

我们来看看这个场景:假设线程一执行到instance = new SingletonKerriganD()这句,这里看起来是一句话,但实际上它并不是一个原子操作(原子操作的意思就是这条语句要么就被执行完,要么就没有被执行过,不能出现执行了一半这种情形)。事实上高级语言里面非原子操作有很多,我们只要看看这句话被编译后在JVM执行的对应汇编代码就发现,这句话被编译成8条汇编指令,大致做了3件事情:

1.Kerrigan的实例分配内存。

2.初始化Kerrigan的构造器

3.instance对象指向分配的内存空间(注意到这步instance就非null了)。

但是,由于Java编译器允许处理器乱序执行(out-of-order),以及JDK1.5之前JMMJava Memory Medel)中Cache、寄存器到主内存回写顺序的规定,上面的第二点和第三点的顺序是无法保证的,也就是说,执行顺序可能是1-2-3也可能是1-3-2,如果是后者,并且在3执行完毕、2未执行之前,被切换到线程二上,这时候instance因为已经在线程一内执行过了第三点,instance已经是非空了,所以线程二直接拿走instance,然后使用,然后顺理成章地报错,而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来,真是一茶几的杯具啊。

DCL的写法来实现单例是很多技术书、教科书(包括基于JDK1.4以前版本的书籍)上推荐的写法,实际上是不完全正确的。的确在一些语言(譬如C语言)上DCL是可行的,取决于是否能保证23步的顺序。在JDK1.5之后,官方已经注意到这种问题,因此调整了JMM、具体化了volatile关键字,因此如果JDK1.5或之后的版本,只需要将instance的定义改成“private volatile static SingletonKerriganD instance = null;”就可以保证每次都去instance都从主内存读取,就可以使用DCL的写法来完成单例模式。当然volatile或多或少也会影响到性能,最重要的是我们还要考虑JDK1.42以及之前的版本,所以本文中单例模式写法的改进还在继续。

代码倒越来越复杂了,现在先来个返璞归真,根据JLSJava Language Specification)中的规定,一个类在一个ClassLoader中只会被初始化一次,这点是JVM本身保证的,那就把初始化实例的事情扔给JVM好了,代码被改成这样:

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第五次尝试
  3. */
  4. public class SingletonKerriganE {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganE instance = new SingletonKerriganE();
  9. public static SingletonKerriganE getInstance() {
  10. return instance;
  11. }
  12. }
/**
 * 实现单例访问Kerrigan的第五次尝试
 */
public class SingletonKerriganE {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganE instance = new SingletonKerriganE();
 
    public static SingletonKerriganE getInstance() {
        return instance;
    }
}

 

好吧,如果这种写法是完美的话,那前面那么几大段话就是作者在消遣各位读者。这种写法不会出现并发问题,但是它是饿汉式的,在ClassLoader加载类后Kerrigan的实例就会第一时间被创建,饿汉式的创建方式在一些场景中将无法使用:譬如Kerrigan实例的创建是依赖参数或者配置文件的,在getInstance()之前必须调用某个方法设置参数给它,那样这种单例写法就无法使用了。

再来看看下面这种我觉得能应对较多场景的单例写法:

Java代码 复制代码 收藏代码
  1. /**
  2. * 实现单例访问Kerrigan的第六次尝试
  3. */
  4. public class SingletonKerriganF {
  5. private static class SingletonHolder {
  6. /**
  7. * 单例对象实例
  8. */
  9. static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
  10. }
  11. public static SingletonKerriganF getInstance() {
  12. return SingletonHolder.INSTANCE;
  13. }
  14. }
/**
 * 实现单例访问Kerrigan的第六次尝试
 */
public class SingletonKerriganF {
 
    private static class SingletonHolder {
        /**
         * 单例对象实例
         */
        static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
    }
 
    public static SingletonKerriganF getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

 

这种写法仍然使用JVM本身机制保证了线程安全问题;由于SingletonHolder是私有的,除了getInstance()之外没有办法访问它,因此它是懒汉式的;同时读取实例的时候不会进行同步,没有性能缺陷;也不依赖JDK版本。

其他单例模式的写法还有很多,如使用本地线程(ThreadLocal)来处理并发以及保证一个线程内一个单例的实现、GoF原始例子中使用注册方式应对单例类需要需要继承时的实现、使用指定类加载器去应对多ClassLoader环境下的实现等等。我们做开发设计工作的时,应当既要考虑到需求可能出现的扩展与变化,也应当避免“幻影需求”导致无谓的提升设计、实现复杂度,最终反而带来工期、性能和稳定性的损失。设计不足与设计过度都是危害,所以说没有最好的单例模式,只有最合适的单例模式。

到这里为止,单例模式本身就先告一段落了,最后在介绍从其他途径屏蔽构造单例对象的方法:

1.直接new单例对象

2.通过反射构造单例对象

3.通过序列化构造单例对象。

对于第一种情况,一般我们会加入一个private或者protected的构造函数,这样系统就不会自动添加那个public的构造函数了,因此只能调用里面的static方法,无法通过new创建对象。

对于第二种情况,反射时可以使用setAccessible方法来突破private的限制,我们需要做到第一点工作的同时,还需要在在 ReflectPermission("suppressAccessChecks") 权限下使用安全管理器(SecurityManager)的checkPermission方法来限制这种突破。一般来说,不会真的去做这些事情,都是通过应用服务器进行后台配置实现。

对于第三种情况,如果单例对象有必要实现Serializable接口(很少出现),则应当同时实现readResolve()方法来保证反序列化的时候得到原来的对象。

基于上述情况,将单例模式增加两个方法:

Java代码 复制代码 收藏代码
  1. /**
  2. * 能应对大多数情况的单例实现
  3. */
  4. public class SingletonKerrigan implements Serializable {
  5. private static class SingletonHolder {
  6. /**
  7. * 单例对象实例
  8. */
  9. static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
  10. }
  11. public static SingletonKerrigan getInstance() {
  12. return SingletonHolder.INSTANCE;
  13. }
  14. /**
  15. * private的构造函数用于避免外界直接使用new来实例化对象
  16. */
  17. private SingletonKerrigan() {
  18. }
  19. /**
  20. * readResolve方法应对单例对象被序列化时候
  21. */
  22. private Object readResolve() {
  23. return getInstance();
  24. }
  25. }
/**
 * 能应对大多数情况的单例实现
 */
public class SingletonKerrigan implements Serializable {
 
    private static class SingletonHolder {
        /**
         * 单例对象实例
         */
        static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
    }
 
    public static SingletonKerrigan getInstance() {
        return SingletonHolder.INSTANCE;
    }
 
    /**
     * private的构造函数用于避免外界直接使用new来实例化对象
     */
    private SingletonKerrigan() {
    }
 
    /**
     * readResolve方法应对单例对象被序列化时候
     */
    private Object readResolve() {
        return getInstance();
    }
}

 

总结:

本章通过一次次的的尝试,去了解单例模式各种实现方案的优缺点。对双锁锁定检测进行了简单的讨论,相信大家能从各种尝试的演化过程中,明白为何单例模式是最简单而又最复杂的一种构造模式。

各种构造模式之间可以互相比较,但是没有优劣好坏之分,只有确定了上下文环境,才能谈应用什么模式。学习设计模式我觉得也没有必要去强背一些代码模版,应当去理解每种模式的出现的原因和解决的问题,当你发现你的设计需要更大灵活性时,设计便会向着合适的模式演化,这时候你就真正的掌握了设计模式。

分享到:
评论
发表评论

文章已被作者锁定,不允许评论。

相关推荐

    43丨单例模式(下):如何设计实现一个集群环境下的分布式单例模式?1

    单例模式是一种设计模式,旨在确保一个类只有一个实例,并提供全局访问点。在单例模式中,类的构造函数是私有的,防止外部直接创建对象,而是通过静态方法获取该类的唯一实例。单例模式的唯一性通常是在进程范围内,...

    设计模式单例模式和工厂模式综合应用

    "设计模式单例模式和工厂模式综合应用"的主题聚焦于两种常用的设计模式:单例模式和工厂模式,并探讨它们如何协同工作来实现高效、灵活的代码结构。这个主题尤其适用于Java编程语言,因为Java的面向对象特性使得设计...

    设计模式之单例模式(结合工厂模式)

    单例模式是软件设计模式中的一种经典模式,它保证了类只有一个实例存在,并提供一个全局访问点。在Java等面向对象编程语言中,单例模式常用于管理共享资源,如数据库连接池、线程池或者配置文件等。结合工厂模式,...

    java单例模式实例

    单例模式是软件设计模式中的一种经典模式,用于确保一个类只有一个实例,并提供一个全局访问点。在Java中,有多种实现单例模式的方法,每种都有其特点和适用场景。接下来,我们将深入探讨这些实现方式。 首先,我们...

    使用C++11实现线程安全的单例模式

    在C++编程中,单例模式是一种常用的软件设计模式,它保证一个类只有一个实例,并提供一个全局访问点。线程安全的单例模式在多线程环境下尤其重要,因为不正确的实现可能导致多个线程创建多个实例,这违反了单例模式...

    设计模式——单例模式

    **设计模式——单例模式** 在软件工程中,设计模式是一种在特定场景下解决常见问题的标准方案,可以被复用并提升代码质量。单例模式是设计模式中的一种,它保证一个类只有一个实例,并提供一个全局访问点。这种模式...

    C#单例模式详解 C#单例模式详解C#单例模式详解

    单例模式是软件设计模式中的一种,它保证一个类只有一个实例,并提供一个全局访问点。在C#中,单例模式常用于管理共享资源或控制类的实例化过程,以提高性能、节约系统资源,特别是在整个应用程序生命周期内只需要一...

    7种单例模式

    单例模式是软件设计模式中的一种经典模式,其主要目的是确保一个类只有一个实例,并提供一个全局访问点。这种模式在很多场景下非常有用,比如控制共享资源、管理配置对象等。下面将详细介绍七种常见的单例模式实现...

    使用单例模式实现计数器

    其中,单例模式是一种非常经典且常用的设计模式,它确保一个类只有一个实例,并提供一个全局访问点来获取这个实例。在C#中,我们可以利用单例模式来创建一个计数器类,以确保在整个应用程序的生命周期内,计数器只...

    使用单例模式创建学生管理系统(饿汉式、懒汉式)

    单例模式是软件设计模式中的一种,它的主要目的是确保一个类只有一个实例,并提供一个全局访问点。在Java或类似的面向对象编程语言中,单例模式常用于管理共享资源,如数据库连接池、线程池或者配置文件等。在这个...

    c++单例模式线程日志类

    在C++编程中,单例模式是一种常用的软件设计模式,它保证一个类只有一个实例,并提供一个全局访问点。在这个特定的场景中,我们讨论的是一个实现了单例模式的日志类,该类专为多线程环境设计,具备日志等级控制、...

    单例模式实现mdi界面子窗体控制

    首先向关注过我这个系列...这立刻让我想到了最常用也是最简单最容易理解的一个设计模式 单例模式 何为 单例模式 ? 故名思议 即 让 类 永远都只能有一个实例。 由于 示例代码 比较简单 我也加了注释,这里就不在赘述

    几种单例模式demo

    单例模式是软件设计模式中的一种,它的主要目的是确保一个类只有一个实例,并提供一个全局访问点。这种模式在很多场景下都非常有用,比如控制资源的唯一性、管理共享配置或者创建昂贵的对象时避免频繁创建销毁。 ...

    Java 单例模式 工具类

    Java中的单例模式是一种常用的软件设计模式,它保证一个类只有一个实例,并提供全局访问点。在Java编程中,单例模式常用于控制资源的访问,比如数据库连接池、线程池或者日志对象等。本篇文章将深入探讨如何在Java中...

    单例模式详解~~单例模式详解~~

    单例模式是一种设计模式,它的主要目标是确保一个类只有一个实例,并提供一个全局访问点。在软件工程中,单例模式常用于控制资源的共享,比如数据库连接池、线程池或者日志系统等,这些资源通常需要全局唯一且高效地...

    单例模式(singleton)

    单例模式是软件设计模式中的一种,它的核心思想是确保一个类在整个系统中只有一个实例,并提供一个全局访问点。在Java或类似编程语言中,单例模式常常被用来管理资源,比如数据库连接、线程池或者配置信息,因为这些...

    Qt qml Singleton 单例模式

    在Qt的Qml环境中,单例模式是一种设计模式,它允许在整个应用程序中创建一个全局访问点,确保某个类只有一个实例存在。这样的设计模式在需要共享数据或者服务时非常有用,避免了多处创建相同对象导致的数据不一致或...

    设计模式之单例模式源码demo

    单例模式是软件设计模式中的经典模式之一,其主要目的是控制类的实例化过程,确保在应用程序的整个生命周期中,某个类只有一个实例存在。这样的设计通常适用于那些需要频繁创建和销毁,但资源消耗较大的对象,如...

    23钟设计模式之单例模式

    单例模式是一种常用的设计模式,它的核心思想是在整个应用程序中,一个类只能有一个实例存在。单例模式常用于控制资源的共享,例如数据库连接池、日志服务等。单例模式有多种实现方式,常见的包括懒汉式、饿汉式以及...

Global site tag (gtag.js) - Google Analytics