探索设计模式之六——单例模式

IcyFenix

浏览: 358962 次
性别:
来自: 珠海

最近访客更多访客>>

animagi

xckouy

hresh

君淋天下

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (32)

社区版块

存档分类

设计模式 Spring 应用服务器多线程 JVM

6.单例模式（Singleton Pattern）

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

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

目的：

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

场景：

Kerrigan对于Zerg来说是个至关重要的灵魂人物，无数的Drone、Zergling、Hydralisk……可以被创造、被牺牲，但是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等情况，不过还是不要把情况考虑的太复杂了，暂且先放过作者吧（-_-#）。

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

/**
 * 实现单例访问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的位置。刚刚判断完毕后，JVM将CPU资源切换给线程二，由于线程一还没执行line B，所以instance仍然是空的，因此线程二执行了new SignletonKerriganA()操作。片刻之后，线程一被重新唤醒，它执行的仍然是new SignletonKerriganA()操作，好了，问题来了，两个Kerrigan谁是李逵谁是李鬼？

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

/**
 * 实现单例访问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修饰符的同步准备上，因此从性能上说很不划算。

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

/**
 * 实现单例访问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）。

/**
 * 实现单例访问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之前JMM（Java Memory Medel）中Cache、寄存器到主内存回写顺序的规定，上面的第二点和第三点的顺序是无法保证的，也就是说，执行顺序可能是1-2-3也可能是1-3-2，如果是后者，并且在3执行完毕、2未执行之前，被切换到线程二上，这时候instance因为已经在线程一内执行过了第三点，instance已经是非空了，所以线程二直接拿走instance，然后使用，然后顺理成章地报错，而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来，真是一茶几的杯具啊。

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

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

/**
 * 实现单例访问Kerrigan的第五次尝试
 */
public class SingletonKerriganE {
 
    /**
     * 单例对象实例
     */
    private static SingletonKerriganE instance = new SingletonKerriganE();
 
    public static SingletonKerriganE getInstance() {
        return instance;
    }
}

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

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

/**
 * 实现单例访问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()方法来保证反序列化的时候得到原来的对象。

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

/**
 * 能应对大多数情况的单例实现
 */
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();
    }
}

总结：

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

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

[1] 本章内容参考过：JavaWorld中《When is a singleton not a singleton?》以及ZelluX的BlogJava博客《Singleton模式与双检测锁定(DCL) 》。

查看图片附件

分享到：

一个面试官对面试问题的分析 | 探索设计模式之五——原型模式

2010-01-19 19:24
浏览 6357
评论(22)
论坛回复 / 浏览 (19 / 64383)
分类:企业架构
查看更多

22 楼 Misaya 2014-01-23

21 楼 macemers 2011-08-29

为啥饿汉式的的singleton不可以使用，不是很明白，麻烦楼主详细说说

20 楼 macemers 2011-08-29

lianxianghui 写道

Effective java 2 建议java1.5以上使用单元素的枚举实现Singleton.

请12楼说说是effetive java2的那一条。。找不到

19 楼 xiangdefei 2010-12-10

上次看外国一个编程论坛上说java不支持双重检测。

18 楼 sunxiaofeng1011 2010-12-10

，只需要将instance的定义改成“private volatile static SingletonKerriganD instance = null;”就可以保证每次都去instance都从主内存读取，就可以使用DCL的写法来完成单例模式。，，，如何解决上面提到的1—3—2问题，可否详细说明

17 楼 iSay 2010-11-08

饿汉式的创建方式在一些场景中将无法使用：譬如Kerrigan实例的创建是依赖参数或者配置文件的，在getInstance()之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。
 
<pre name="code" class="java">/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {

/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();

private SingletonKerriganE(){
//init config 可以在这里进行配置文件的初始化吗？
}

public static SingletonKerriganE getInstance() {
return instance;
}
}</pre>
 
这样看看行否各位XDJM？

16 楼 qingyue0530 2010-10-28

受益匪浅。

15 楼 duanbo 2010-04-02

学习了. 分析的很透彻. 一会写个测试程序实践下.

14 楼 jashawn 2010-01-30

你第六次尝试的范例我在某个项目中使用过，在单例中使用double check 我没有深入了解，虽然偶尔也写double check，至于为什么double check也会有漏洞并不清楚，今天看了一下楼主的帖子受益匪浅。
不过坦率地讲，现在的应用引入依赖注入容器之后单例看起来已经不是问题了。

13 楼 Mybeautiful 2010-01-29

单例模式因为其相对简单，尤其是从面向过程的角度看，它非常受欢迎，所以我们看到处看到滥用单例的例子。

12 楼 lianxianghui 2010-01-25

Effective java 2 建议java1.5以上使用单元素的枚举实现Singleton.

11 楼 robertliudeqiang 2010-01-22

IcyFenix 写道

robertliudeqiang 写道

呵呵，楼主总结的比较全，如果能加上单例模式在不同classloader上的分析，甚至是多个jvm的分析就好了。

另外，最近一期“程序员”杂志刊登了一篇采访 GoF（设计模式作者）的文章，他们计划对<设计模式>进行修订，其中还特别提到要剔除“单例模式”，认为单例模式很容易在系统中产生“代码的臭味”，期待新版的设计模式早点出来。

你好，你和另外一位网友都提到不同类加载器对singleton模式的影响，刚刚看到你blog中的一篇文章：http://robblog.iteye.com/blog/576351，我接着你文章的例子补充一下。

    多个classloader可以加载同一个类，加载器1加载了ClassA，创建出来的ObjectA去instanceOf加载器2加载的同一个ClassA，结果是false的，用==或者equals比较2个加载器中实例化出来的对象自然肯定也是false。这是你blog文中的例子描述的内容。

    接着我继续引申文中的例子，在tomcat中存在的多个加载器，从上至下的顺序大致是：boot/ext加载器加载jdk以及jdk的/lib/ext包，common/share加载器加载common/lib、share/lib中的包，webapp加载器加载应用程序的lib、classes目录中的包，这是很多人都了解过的知识，那是否有人察觉到下面这种很常见的场景可能会产生的问题：

    场景：很多程序都spring来管理，一般的做法是将spring.jar放到common/lib中，将自己的类放到应用程序的/lib或者/lib/classes中。根据java的默认加载类、创建对象的规则（就是不特别指定类加载器的情况，譬如使用new创建对象，或者使用一个参数的Class.forName()重载来创建对象），当遇到新的类需要加载时，使用的是加载当前类的类加载器去加载（很多classloader的实现又优先委派给自己的父classloader去加载了，除了osgi中，其他大多都是这种场景，这个与当前话题无关先放下），现在就出现一个问题了，spring.jar因为是放在common/lib中的，它的类加载器自然是common加载器，那为何spring还能管理到我们应用程序呢？放在应用程序的/lib目录下的东西应当对spring的类加载器是不可见的才对呀？

    提出上面这种场景，是因为这里遇到的问题和单例模式下处理多个类加载器中的主流方式是一样的，都是使用Thread.currentThread().getContextClassLoader()中的加载器去加载类，因为各种应用服务器一般会分配请求处理线程的时候，将这个加载器设置为应用程序加载器（譬如tomcat中的webapp加载器），从而使得上级加载器中加载的代码也能有途径访到我们应用和程序中的代码。

    以后有机会再重新整理这篇文章的时候，我把这些补充进去。希望能对你有所帮助。

挺好，先收藏。

10 楼 mwmw 2010-01-22

每个月都会有人用差不多的帖子来讲解一下Singleton...

9 楼 IcyFenix 2010-01-21

robertliudeqiang 写道

8 楼 IcyFenix 2010-01-21

crud0906 写道

--------------
饿汉式的创建方式在一些场景中将无法使用：譬如Kerrigan实例的创建是依赖参数或者配置文件的，在getInstance()之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。
---------------
貌似你的第六种尝试也没解决这一问题

还有想请教下楼主，内部类在什么时候被加载？

你提的2个问题，看看下面就清楚了

/**
 * 实现单例访问Kerrigan的第六次尝试
 */
public class SingletonKerriganF {

	private static String arg = null;

	private static class SingletonHolder {
		/**
		 * 单例对象实例
		 */
		static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
	}

	public static SingletonKerriganF getInstance() {
		return SingletonHolder.INSTANCE;
	}

	public SingletonKerriganF() {
		System.out.println("Kerrigan get arg:" + getArg());
		System.out.println("Kerrigan created!");
	}

	public static String getArg() {
		return arg;
	}

	public static void setArg(String arg) {
		SingletonKerriganF.arg = arg;
	}

	public static void main(String[] args) {
		System.out.println("SingletonKerriganF was loaded,but SingletonKerriganF$SingletonHolder don't");
		SingletonKerriganF.setArg("this maybe some config files etc....");
		SingletonKerriganF.getInstance();
	}

}

输出：
SingletonKerriganF was loaded,but SingletonKerriganF$SingletonHolder don't
Kerrigan get arg:this maybe some config files etc....
Kerrigan created!

7 楼 piao_bo_yi 2010-01-21

感觉单例模式的难处不在于其构造，而在于其场景的确定。构造的方式只要记住就可以了。没什么难的。

6 楼 crud0906 2010-01-21

5 楼 robertliudeqiang 2010-01-21

4 楼 anranran 2010-01-21

非常好,希望讲下classloader下的情况

3 楼 li445970924 2010-01-21

受益匪浅

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论