探索设计模式--单例模式-CSDN博客

本文链接：https://blog.csdn.net/iteye_21228/article/details/82004098

转自：http://www.iteye.com/topic/575052

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

目的：

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

场景：

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代码  
       
/** 
 * 实现单例访问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代码  
       
/** 
 * 实现单例访问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代码  
       
/** 
 * 实现单例访问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代码  
       
/** 
 * 实现单例访问Kerrigan的第四次尝试 
 */  
public class SingletonKerriganD {  
   
    /** 
     * 单例对象实例 
     */  
    private static SingletonKerriganD instance = null;  
   
    public 