设计模式单例模式之一步一步深入填坑

最新推荐文章于 2024-06-28 13:33:28 发布

21世纪大懒虫

最新推荐文章于 2024-06-28 13:33:28 发布

阅读量539

点赞数

分类专栏： java_Tools 文章标签：设计模式单例模式单例模式那些坑

本文链接：https://blog.csdn.net/p0p0p0p01/article/details/50830997

版权

java_Tools 专栏收录该内容

32 篇文章 0 订阅

订阅专栏

单例之Singleton设计模式可能是被讨论和使用的最广泛的一个设计模式了，这可能是在面试中问的最多的一个设计模式了。

这个设计模式的主要目的是想在整个系统中只能出现一个类的实例。这样做当然是有原因的，比如一个全局配置信息，或者一个Factory，或者一个最主要的控制类等等。

你希望这个类在整个下中只能出现一个实例。当然，作为负责人，你也可以张贴告示“XX类只能有一个全局实例，如果某人使用两次以上，就要被罚款1000元！”你也有这个权利这么做。但是如果你设计的这个类库是要提供给其他客户使用，恐怕你的上述规定就没用了，因为你没法控制别人怎么使用。所以，我们希望来探讨一下如果通过技术手段来达成这一目的。

本人以java语言为例来说明。

首先是V1.0版本的：

public class Singleton{

   private statc final Singleton singleton = null;
   private Singleton{}
   public static Singleton getInstance(){
      if(singleton == null){
             singleton  =  new Singleton();
       }
       return singleton ;

  }
}

在上面的例子中，我想说明下Singleton的几个特点：

1、private Singleton{} 私有的构造方法，表明这个类是不可能形成实例了。主要是因为怕形成多个实例。

2、既然这个类是不可可能形成实例了，那么，就要需要一个静态的方法形成实例：

3、静态的方法：public static Singleton getInstance(){} 注意这个方法是在new 自己，因为其可以访问私有的构造方法，所以他是可以保证实例被创建出来的。

4、在public static Singleton getInstance(){} 中，先判断是否已生成实例，如果有则直接返回，没有就创建实例。所形成的类的实例保存在自己类的私有成员中。

好了，现在我们要调用这个getInstance来创建实例了，如果你觉得上面这些事情学成了，那我就给你当头一棒喝，事情远远没有那么简单。

分析一下：

上面这个版本有严重的问题，因为是全局的实例，所以，在【多线程的情况下，所有全局共享的东西都会变得很危险】，这个也一样，在多线程的情况下，如果多个线程在调用getInstance()的时候，那么，可能会有多个线程同时通过if(singleton == null)的条件检查，于是，多个实例就会被创建出来，并且可能造成内存泄露。

恩，熟悉多线程的你会说，我们需要‘线程互斥同步’，没错，我们需要这个玩意，于是V1.1版本出来了：

V1.1:

public class Singleton{

   private statc final Singleton singleton = null;
   private Singleton{}
   public static Singleton getInstance(){
      if(singleton == null){
	synchronized(Singleton.class){
	 singleton  =  new Singleton();
	}
       }
       return singleton ;

  }

恩，使用了java的synchronized方法，看起来不错了额，应该没什么问题了吧？错！错！错！

还有有问题？为什么？前面已经说过，如果有多个线程同时通过if(singleton == null)的条件检查（因为他们并行运行），虽然我们的synchronized方法会帮助我们同步所有的线程，让我们并行的线程变成串行的一个一个去new，那不还是一样new了多个吗？同样会出现多个实例。

恩，确实如此。看来还得把那个判断if(singleton == null)条件也同步起来，于是V1.2出来了

V1.2:

<span style="font-size:18px;">public class Singleton{

   private statc final Singleton singleton = null;
   private Singleton{}
   public static Singleton getInstance(){
    synchronized(Singleton.class){
        if(singleton == null){
         singleton  =  new Singleton();
         }
       }
       return singleton ;
  }</span>

不错不错，看似很不错了。在多线程情况下应该没有什么问题了，不是吗？的却是这样的，V1.2的Singleton在多线程下的确没有问题了，因为我们同步了所有的线程。只不过嘛。。。。。。什么？？？？还不行？？？是的，时还有点小问题，我们本来只是想要让new的这个操作并行就可以，现在，只要进入getInstance（）的线程都得同步啊，注意，创建对象的动作只有一次，后面的动作全是读取那个成语变量，这些读取的动作不需要线程同步啊。这样的做法非常极端啊，为了一个初始化的创建侗族，居然让我们达到了所有的读操作的同步，严重影响了后续的性能啊！

还得改？？恩！看来，在线程同步前还得加一个(singleton== null)的条件判断，如果对象已将创建了，那么就不需要我们进行线程的同步了，OK！下面的V1.3

V1.3

<span style="font-size:18px;">public class Singleton{

   private statc final Singleton singleton = null;
   private Singleton{}
   public static Singleton getInstance(){
	if(singleton == null){
		synchronized(Singleton.class){
	    		if(singleton == null){
	 		singleton  =  new Singleton();
	     }
          }
	}	
       return singleton ;
  }
}</span>

是不是感觉代码变得有些啰嗦和复杂了，不过，这可能是最不错的一个版本了，这个版本又叫做‘ 双重检查’ Dubble-Check。

！！！！！！！！单例模式的判断做双重检查！！！！！！！！！

下面是说明：

第一个条件是说，如果实例创建了，呢么就不需要同步了，直接返回就好了。不然，我们就开始线程同步。

第二个条件是说，如果被同步的线程中，有一个创建了实例，那么别的线程就不用创建了。

相当不错吧，干的很漂亮！请为我们的V1.3鼓掌。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Singleton的其它问题

怎么？还有问题？当然还有，请记住下面这条规则---‘无论你写的代码有多好，其职能在特定的范围内工作，超出这个范围就要出bug了’ 。哈哈

我们可以在java的环境下举出一个反例来说明什么情况下出现bug。

1、ClassLoader 。不知道你对ClassLoader 熟悉不熟悉？ ‘类装载器’ ？这是Java动态性的核心。

顾名思义，ClassLoader 是来把类Class装载进JVM虚拟机的。

JVM规范定义了两种类型的类装载器：启动类装载器（bootstrap）和用户自定义类装载器(user-defined class loader)。

在一个JVM中可能存在多个ClassLoader 的实例，每个ClassLoader 拥有自己的NameSpace，一个ClassLoader 只能拥有一个class对象类型的实例，但是不同的ClassLoader 可能拥有相同的Class实例对象，这时可能产生致命的问题。

如ClassLoaderA ，装载了类A和类型实例A1，而ClassLoaderB ，也装载了类A的对象实例A2。

逻辑上将，A1=A2，但是由于A1和A2来自于不同的ClassLoader ，他们实际上市是完全不同的，如果A中定义了一个静态变量c，则c在不同的ClassLoader 的值是不同的。

于是，如果咱们的V1.3版本如果面对着多个ClassLoader 会怎么样额？呵呵，多个实例会被多个ClassLoader 创建出来，当然，这个有点牵强，不过他确实存在。

难道我们还要整出一个V1.4不可吗?可是，我们怎么可能在我们的Singleton类中操作ClassLoader啊？是的，你根本不可能，你能做的只有是---保证多个ClassLoader不会装载同一个Singleton。

2、序列化

如果我们么的这个Singleton类是一个关于我们程序配置的类。

我们需要他有序列化的功能，那么，当反序列化的时候，我们就无法控制别人不多次反序列化。不过，我们可以利用一下Serializable接口的readResolve（）方法，比如：

public class Singleton implements Serializable   
{   
    ......   
    ......   
    protected Object readResolve()   
    {   
        return getInstance();   
    }   
}

3、多个虚拟机

如果我们的程序运行在多个虚拟机中，什么？多个虚拟机？这是一种什么样的情况啊？恩，这种情况是有点极端，不过还是可能出现，比如RMI之流的对象，要在这种环江下避免多实例，看来只能通过良好的实际或非技术手段来解决了。

4、volatile变量。关于volatile这个关键字所声明的变量可以被你看作是一种 ‘程度较轻的同步synchronized’。

与synchronized块相比，volatile变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅仅是synchronized的一部分。

当然，向前面说的一样，我们需要的Singleton只是在创建的时候线程同步，而后面的读取不需要同步。

所以volatile变量并不能帮我们既能解决问题，又有好的性能。而且，这种变量只能在JDK 1.5+后才能使用。

5、关于继承

是的，继承与Singleton后的子类也有可能造成多实例的问题。

不过，因为我们早把Singleton的构造函数声明为私有的了，所以也就杜绝了继承这种事情。

6、关于代码重用。

也许我们的系统中有很多类需要用到这个莫斯，如果我们在每一个类中都有这样的代码，那么就显得有点傻了。那么，我们是否可以使用一种方法，把这个模式抽象出去？这个在Java下比较复杂一些，聪明的你知道怎么做吗？