单例模式(Singleton Pattern

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

 

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

目的:

希望对象只创建一个实例,并且提供一个全局的访问点。(可以想象一下类似BBS论坛的在线人数统计功能,或者连接池对象的创建)

 

场景:

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

 

分析:

 

 

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

 

DCL的写法来实现单例是很多技术