Singleton模式

最新推荐文章于 2024-05-24 16:06:30 发布
最新推荐文章于 2024-05-24 16:06:30 发布
阅读量519 收藏
点赞数

原文链接http://www.iteye.com/topic/575052

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

 

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等情况，不过还是不要把情况考虑的太复杂了，暂且先放过作者吧（-_-#）。

 

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

 

Java代码
  1. /**  
  2.  * 实现单例访问Kerrigan的第一次尝试  
  3.  */  
  4. public class SingletonKerriganA {   
  5.     
  6.     /**  
  7.      * 单例对象实例  
  8.      */  
  9.     private static SingletonKerriganA instance = null;   
  10.     
  11.     public static SingletonKerriganA getInstance() {   
  12.         if (instance == null) {                              //line A   
  13.             instance = new SingletonKerriganA();          //line B   
  14.         }   
  15.         return instance;   
  16.     }   
  17. }  
/** * 实现单例访问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谁是李逵谁是李鬼？

 

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

 

Java代码
  1. /**  
  2.  * 实现单例访问Kerrigan的第二次尝试  
  3.  */  
  4. public class SingletonKerriganB {   
  5.     
  6.     /**  
  7.      * 单例对象实例  
  8.      */  
  9.     private static SingletonKerriganB instance = null;   
  10.     
  11.     public synchronized static SingletonKerriganB getInstance() {   
  12.         if (instance == null) {   
  13.             instance = new SingletonKerriganB();   
  14.         }   
  15.         return instance;   
  16.     }   
  17. }  
/** * 实现单例访问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.      */  
  9.     private static SingletonKerriganC instance = null;   
  10.     
  11.     public static SingletonKerriganC getInstance() {   
  12.         synchronized (SingletonKerriganC.class) {   
  13.             if (instance == null) {   
  14.                 instance = new SingletonKerriganC();   
  15.             }   
  16.         }   
  17.         return instance;   
  18.     }   
  19. }  
/** * 实现单例访问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.      */  
  9.     private static SingletonKerriganD instance = null;   
  10.     
  11.     public static SingletonKerriganD getInstance() {   
  12.         if (instance == null) {   
  13.             synchronized (SingletonKerriganD.class) {   
  14.                 if (instance == null) {   
  15.                     instance = new SingletonKerriganD();   
  16.                 }   
  17.             }   
  18.         }   
  19.         return instance;   
  20.     }   
  21. }  
/** * 实现单例访问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好了，代码被改成这样：

 

Java代码
  1. /**  
  2.  * 实现单例访问Kerrigan的第五次尝试  
  3.  */  
  4. public class SingletonKerriganE {   
  5.     
  6.     /**  
  7.      * 单例对象实例  
  8.      */  
  9.     private static SingletonKerriganE instance = new SingletonKerriganE();   
  10.     
  11.     public static SingletonKerriganE getInstance() {   
  12.         return instance;   
  13.     }   
  14. }  
/** * 实现单例访问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.     
  6.     private static class SingletonHolder {   
  7.         /**  
  8.          * 单例对象实例  
  9.          */  
  10.         static final SingletonKerriganF INSTANCE = new SingletonKerriganF();   
  11.     }   
  12.     
  13.     public static SingletonKerriganF getInstance() {   
  14.         return SingletonHolder.INSTANCE;   
  15.     }   
  16. }  
/** * 实现单例访问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.     
  6.     private static class SingletonHolder {   
  7.         /**  
  8.          * 单例对象实例  
  9.          */  
  10.         static final SingletonKerrigan INSTANCE = new SingletonKerrigan();   
  11.     }   
  12.     
  13.     public static SingletonKerrigan getInstance() {   
  14.         return SingletonHolder.INSTANCE;   
  15.     }   
  16.     
  17.     /**  
  18.      * private的构造函数用于避免外界直接使用new来实例化对象  
  19.      */  
  20.     private SingletonKerrigan() {   
  21.     }   
  22.     
  23.     /**  
  24.      * readResolve方法应对单例对象被序列化时候  
  25.      */  
  26.     private Object readResolve() {   
  27.         return getInstance();   
  28.     }   
  29. }  
/** * 能应对大多数情况的单例实现 */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();    }}
 

 

 

 

总结：

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

 

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

记录点滴
关注
设计模式-单例模式（转）
sun_gufeng的专栏
01-21 269
单例模式（Singleton Pattern） 前面说提到的五种创建模式，主要解决的问题是如何创建对象，获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。 Singleton模式可以是很简单的，它的全部只需要一个类就可以完成（看看这章可怜的UML图）。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来，Singleton模式可以相当的复杂，比头五种模式加起...
访问接口常用限流的java方式_Spring Boot 的接口限流算法优缺点深度分析
weixin_39970668的博客
12-09 241
迎关注我的头条号：Wooola，10 年 Java 软件开发及架构设计经验，专注于 Java、Go 语言、微服务架构，致力于每天分享原创文章、快乐编码和开源技术。前言在一个高并发系统中对流量的把控是非常重要的，当巨大的流量直接请求到我们的服务器上没多久就可能造成接口不可用，不处理的话甚至会造成整个应用不可用。那么何为限流呢？顾名思义，限流就是限制流量，就像你宽带包了1个G的流量，用完了就没了。通过...
java 单例 构造函数_使用powermock在java中抑制一个单例构造函数
weixin_42315824的博客
02-24 279
我试图对一些使用Singleton类的类进行单元测试，这些类的构造函数执行一些我不能(也不应该)从单元测试环境中做的事情。我的理想场景是完全禁止构造函数，然后将我的测试类调用的其他成员方法截断。我的问题是我似乎无法取消构造函数。我对解决此问题的方法的理解如下所示：public class MySingleton extends AbstractSingletonParent {public fin...
工具类中屏蔽构造函数
java技术博客
07-31 707
工具类中屏蔽构造函数 参考网址: https://mp.weixin.qq.com/s/LG92rkjY3o2pqx3QdaXBVw 错误示例代码 public class PasswordUtils { //工具类构造函数反例 private static final Logger LOG = LoggerFactory.getLogger(PasswordUtils.class); public static final String DEFAULT_CRYPT_ALGO = "PB
C++类-屏蔽掉系统自带的 默认构造函数
LC的专栏
06-09 2825
屏蔽掉系统自带的 默认构造函数 如果用户自己没有定义构造函数，那么，C++系统会自动生成一个构造函数，只是，这个构造函数的函数体是空的，也没有参数，不执行初始化操作。 例如，定义一个C++类，类名是 student，如下： class student //以class开头 { ... }; 那么，构造函数的函数名与类名相同，所以，构造函数的函数名是student。 如果student类没有定义构造函数，那么，编译器自动给student类定义一个构造函数，这个构造函...
C#设计模式之Singleton模式
08-19
C# 设计模式之 Singleton 模式 在软件设计中，Singleton 模式是一种常用的设计模式，它确保一个类只有一个实例，并提供一个全局访问点来访问该实例。在 C# 中，Singleton 模式可以使用静态变量和锁机制来实现。 在...
Python实现Singleton模式的方式详解
09-18
在Python中，实现Singleton模式有多种方法。以下将详细讲解三种常见的实现方式：装饰器、闭包和元类。 1. 装饰器方式： 装饰器是Python语言中的一大特色，它允许我们动态地修改函数或类的行为。在实现Singleton...
C++完美实现Singleton模式
08-01
### C++中实现Singleton模式的关键知识点 #### 一、Singleton模式简介 Singleton模式是一种常用的软件设计模式，旨在确保一个类只有一个实例，并提供一个全局访问点。这种模式在系统中经常被用于控制对共享资源...
基于静态Singleton模式的使用介绍
09-05
在给定的代码示例中，`Singleton<TClass>` 是一个泛型静态类，用于实现静态单例模式。这个类有两个关键属性：`_instance` 和 `_lock`。`_instance` 存储单例实例，而 `_lock` 是一个锁定对象，用于同步多线程环境下...
单例模式的几种写法以及注意事项
二月鸟
04-22 725
1.饿汉式（静态变量） //饿汉式（静态变量） class single1{ //私有化构造器，外部不能 new private single1(){} //本部内部创建对象实例 private final static single1 a=new single1(); //提供一个共有静态方法，返回实例对象 public static single1 getA() { retur...
带你快速理解单例模式（P：C++）
AngelDg的博客
06-25 906
单例模式什么是单例模式饿汉实现方式和懒汉实现方式饿汉方式懒汉方式 什么是单例模式 单例模式是非常典型的一种设计模式 某些类, 只应该具有一个对象(实例), 就称之为单例. 一个类实例化的对象公用同一份资源(一份资源只能被申请一次) 例如一个男人只能有一个媳妇. 在很多服务器开发场景中, 经常需要让服务器加载很多的数据 (上百G) 到内存中. 此时往往要用一个单例的类来管理这些数据. 饿汉实现方式和懒汉实现方式 [洗碗的例子] 吃完饭, 立刻洗碗, 这种就是饿汉方式. 因为下一顿吃的时候可以立刻拿着碗就能
单例模式
隐竹的专栏
01-26 792
<br />单例模式所要做的其实就是禁止通过构造函数实例化类，因为如果类可以通过构造函数实例化，那么就意味着可以有多个实例化对象。<br /> <br />在java或者c++中构造函数可以声明为非公有的：private或者protected，所以可以真正达到禁止通过构造函数实例化的目的。比如<br />在java中我们可以这样来实现单例模式：<br /> <br />public class ClassicSingleton { private static ClassicSingleto
单例模式有这么多需要注意的
butcher的博客
09-03 825
什么是单例模式？ 单例模式是23种设计模式中最简单的一种，是创建型模式，对象由自己的类负责创建，并保证一个类只有一个实例！单例模式提供了一个外部获取实例的方法。单例模式有两种实现模式，一个是饿汉式，一个是懒汉式。 好处：全局只有一个实例，避免了频繁的创建类，减少了内存的开销与资源的消耗。 坏处：没有接口，不能继承，违反了单一职责原则。 实现思路：单例模式为了保证对象是自己创建的，所以需要把构造器私有，并且把声明的变量私有，对外提供一个获取实例的方法即可。 1、饿汉模式 顾名思义就是很饿，对象不管有没有用.
最简单的单例模式
weixin_33854644的博客
03-03 2591
　　如果一个类始终只能创建一个实例，则这个类被称为单例类。 　　在一些特殊的场景下，要求不允许自由创建该类的对象，而是只允许为该类创建一个对象。为了避免其他类自由创建该类的实例，我们把该类的构造器使用private修饰，从而把该类的所有构造器隐藏起来。 　　根据良好封装的原则：一单把该类的构造器隐藏起来，则需要提供一个public方法作为该类的访问点，用于创建该类的对象，且该方法必须使...
C++中的单例模式
YANG_1605的博客
12-04 262
1.什么叫单例模式？ 单例模式也称为单件模式、单子模式，可能是使用最广泛的设计模式。其意图是保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。简单理解就是让类只生成一个对象。 通过单例模式， 可以做到： （1）确保一个类只有一个实例被建立 （2）提供了一个对对象的全局访问指针 （3）在不影响单例类的客户端的情况下允许将来有多个实例 2.怎样实现单例模式...
饿汉式和懒汉式两种单例模式的优缺点
Criven的博客
05-01 3152
饿汉式 /* 保证别人使用该类的时候，只能获取一个对象（Singleton只能有一个对象） 步骤： 1.私有类的构造器 2.提供该类的静态修饰的对象 3.提供公开的静态方法，返回该类的唯一对象 */ public class Singleton { //1.私有类的构造器，目的是不让外界创建对象 private Singleton(){ } //2.提供该类的静态修饰的对象（饿汉式，对象是直接创建的）
如何对构造函数进行隐藏
最新发布
bigchen
05-24 393
设计过程中如何对类的构造函数进行私有化隐藏，仅能通过另一类的接口获取？或是某一固定接口获取？
C++实现Singleton模式解析
在软件开发中，Singleton模式是一种常用的设计模式，它的主要目的是确保一个类只有一个实例，并提供一个全局访问点。这种模式常用于需要频繁实例化然后销毁的对象，或者创建对象需要消耗大量资源的情况，以及希望...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值