设计模式--单例模式

单例设计模式(Singleton Pattern)
1.     意图

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

我们是不是可以通过一个全局变量来实现单例模式的要求呢？我们只要仔细地想想看，全局变量确实可以提供一个全局访问点，但是它不能防止别人实例化多个对象。通过外部程序来控制的对象的产生的个数，势必会系统的增加管理成本，增大模块之间的耦合度。所以，最好的解决办法就是让类自己负责保存它的唯一实例，并且让这个类保证不会产生第二个实例，同时提供一个让外部对象访问该实例的方法。自己的事情自己办，而不是由别人代办，这非常符合面向对象的封装原则。

2.实例
按照以上的思路，我们可以这样来设计单例类：

 

view plaincopy to clipboardprint?
class Singleton {  
    // 私有的静态对象  
    private static Singleton instance = null;  
    //私有的构造方法  
    private Singleton (){  
    }  
    // 公开的静态工厂方法,返回此类的唯一实例  
   public static Singleton getInstance(){  
        if(instance == null){  
            instance = new Singleton();  
        }  
        return instance;  
    }  
} 
class Singleton {
    // 私有的静态对象
    private static Singleton instance = null;
    //私有的构造方法
    private Singleton (){
    }
    // 公开的静态工厂方法,返回此类的唯一实例
   public static Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}
 

Singleton类含有一个instance的私有静态变量,用来保存该类唯一的实例对象，它对于外部对象是不可见的，只能通过getInstance方法才能获得。

Singleton类的构造器是private私有的，外部对象无法通过它的构造器生成实例，也就是说外部程序试图通过new操作符来创建实例是行不通的，因此，getInstance方法成为获得Singleton类实例的唯一途径。

getInstance方法的设计非常简单，它首先检测instance变量是否已经初始化，如果没有被初始化，就创建一个实例保存到instance变量，最后返回这个实例；如果这个实例已经被初始化，那么就直接返回这个实例。

getInstance方法的设计非常简单，它首先检测instance变量是否已经初始化，如果没有被初始化，就创建一个实例保存到instance变量，最后返回这个实例；如果这个实例已经被初始化，那么就直接返回这个实例。

单例模式主要有3个特点，：

1、单例类确保自己只有一个实例。

2、单例类必须自己创建自己的实例。

3、单例类必须为其他对象提供唯一的实例。

3．安全的单例模式：双重检查锁定机制
我们虽然实现了单例模式，但是目前的解决办法并不安全，依然存在着一定的缺陷：

view plaincopy to clipboardprint?
class Singleton {  
    private static Singleton instance = null;  
    private Singleton (){  
}  
public static Singleton getInstance(){  
        if(instance == null){  
            instance = new Singleton();  
        }  
        return instance;  
    }  
} 
class Singleton {
    private static Singleton instance = null;
    private Singleton (){
}
public static Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}
 

这段代码意图通过检查if (instance == null)这个条件，来保证只创建一个Singleton实例。事实上，它运行在单线程环境中，得到的结果是正确的，没有问题，但是运行在多线程的环境中，它就会出现错误，可能有多个Singleton实例被创建出来。

我们分析一下，在多线程环境中，可能会出现这样的情形：线程A 和线程B几乎同时到达if (instance == null)语句，假设线程A 比线程B 早一点点，那么：

（1）A 会首先进入if (instance == null)块的内部，并开始执行new Singleton () 语句。此时，instance变量仍然是null，直到线程A 的new Singleton () 语句返回，并给instance变量赋值为止。

（2） 但是，此时的线程B 并不会在if (instance == null)语句的外面等待，因为此时(instance == null)是成立的，它会马上进入if (instance == null)语句块的内部。这样，线程B 会不可避免地执行instance=new Singleton()语句，从而创建出第二个实例来。

（3）线程A 的instance=new Singleton()语句执行完毕后，instance变量得到了真实的对象引用，(instance == null)不再为真。所以，后来的线程就不会再进入if (instance == null) 语句块的内部了。

（4）线程B 的instance=new Singleton()语句也执行完毕后，instance变量的值被覆盖。但是第一个instance对象被线程A 引用的事实已经无法改变了。这时候的线程A和B各自拥有一个独立的Singleton对象。

为了实现线程安全，我们对代码进行了一定的改造：

view plaincopy to clipboardprint?
Java代码：  
class Singleton{  
private static Singleton instance = null;  
private Singleton() {  
}  
public static Singleton getInstance(){  
    //位置1，第1次检查instance  
if (instance == null)  
{  
//位置2，某一时刻可能有n个线程到达  
synchronized (this)   
{  
//位置3，任何时间只能有1个线程到达  
if (instance == null) //位置4，第2次检查instance  
{  
instance = new Singleton();  
}      
       }      
    }      
    return instance;      
}      
}  
Java代码：
class Singleton{
private static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance(){
 //位置1，第1次检查instance
if (instance == null)
{
//位置2，某一时刻可能有n个线程到达
synchronized (this)
{
//位置3，任何时间只能有1个线程到达
if (instance == null) //位置4，第2次检查instance
{
instance = new Singleton();
}   
       }   
    }   
    return instance;   
}   
}
 

 

我们通过引入了Java的synchronized，各个线程到达临界区时，就会按照线性方式逐个执行。

我们再来分析一下：

（1）在多线程环境中，线程A 和B同时或几乎同时到达位置1。

（2）假设线程A 会首先到达位置2，并进入synchronized(this) 到达位置3。这时，由于synchronized(this) 的同步化限制，线程B 无法到达位置3，而只能在位置2 等候。

（3）线程A 执行instance = new Singleton()语句，instance变量得到赋值，此时，线程B 还只能继续在位置2 等候。

（4）线程A 退出synchronized(this) 块，并返回instance对象。

（5）线程B 进入synchronized(this)块，到达位置3，进而到达位置4。由于instance变量已经不是null 了，因此线程B 退出synchronized(this)，并返回instance，这时候的instance只有一个。

我们通过两次检查instance是否被实例化来解决线程安全问题，这种处理方式称为双重检查锁定机制（Double-checked locking）。还有另外一种解决线程安全的方法，就是把getInstance方法整体作为同步区，比如声明为public static synchronized Singleton getInstance()，这种方式由于锁定的区域过大，特殊情况下会造成系统性能的下降，成为系统的性能瓶颈。

双重检查锁定机制不仅解决了线程安全问题，而且把性能也处理得很不错，看起来非常完美。不幸的是我们应该注意不要在java中使用双重检查锁定机制，由于Java编译器和 JIT 的优化的原因，系统无法保证我们期望的执行次序。虽然Java语法中的volatile修饰符可以强制屏蔽编译器和 JIT 的优化工作，但它是一种非常脆弱的同步机制，比较难以控制，所以建议尽量减少使用。我们后面还提供了其它的一种实现方式。

4         单例模式的实现方式：懒汉单例类和饿汉单例类
单例模式的实现有多种方法，常见的就有懒汉式单例类和饿汉式单例类。我们前面介绍的实现方法就属于懒汉式单例类。

l         懒汉式单例类

对于懒汉模式，我们可以这样理解：该单例类非常懒，只有在自身需要的时候才会行动，从来不知道及早做好准备。它在需要对象的时候，才判断是否已有对象，如果没有就立即创建一个对象，然后返回，如果已有对象就不再创建，立即返回。

懒汉模式只在外部对象第一次请求实例的时候才去创建。

l         饿汉式单例

对于饿汉模式，我们可以这样理解：该单例类非常饿，迫切需要吃东西，所以它在类加载的时候就立即创建对象。

Java代码：

view plaincopy to clipboardprint?
final class Singleton {  
     //私有的唯一实例成员,在类加载的时候就创建好了单例对象  
     private static final Singleton instance = new Singleton();  
     //私有的构造方法,避免外部创建类实例  
     private Singleton() {  
     }  
     //静态工厂方法,返回此类的唯一实例  
     public static Singleton getInstance() {  
         return instance;  
     }  
} 
final class Singleton {
     //私有的唯一实例成员,在类加载的时候就创建好了单例对象
     private static final Singleton instance = new Singleton();
     //私有的构造方法,避免外部创建类实例
     private Singleton() {
     }
     //静态工厂方法,返回此类的唯一实例
     public static Singleton getInstance() {
         return instance;
     }
}
 

使用Java中的final关键字和.Net中sealed关键字去修饰class，目的是阻止派生子类，而派生子类可能会导致实例不唯一。使用Java中的final关键字和.Net中readonly关键字去修饰变量，就意味着只能在类初始化时或者在构造器中分配该变量。

我们对比一下懒汉模式和饿汉模式的优缺点：

这两种模式对于初始化较快，占用资源少的轻量级对象来说，没有多大的性能差异，选择懒汉式还是饿汉式都没有问题。但是对于初始化慢，占用资源多的重量级对象来说，就会有比较明显的差别了。所以，对重量级对象应用饿汉模式，类加载时速度慢，但运行时速度快；懒汉模式则与之相反，类加载时速度快，但运行时第一次获得对象的速度慢。

 

这两种模式对于初始化较快，占用资源少的对象来说，没有多大的性能差异，但是对于初始化慢，占用资源多的对象来说就会有比较明显的差别了。所以，对重量级对象应用饿汉模式，在类加载时需要较长时间，但运行时会有明显的时间效率的提升。对重量级对象应用懒汉模式，在类加载时很快，但至少第一次获得对象时需要等待很长时间。

从用户体验的角度来说，我们应该首选饿汉模式。我们愿意等待某个程序花较长的时间初始化，却不喜欢在程序运行时等待太久，给人一种反应迟钝的感觉，所以对于有重量级对象参与的单例模式，我们推荐使用饿汉模式。

而对于初始化较快的轻量级对象来说，选用哪种方法都可以。如果一个应用中使用了大量单例模式，我们就应该权衡两种方法了。轻量级对象的单例采用懒汉模式，减轻加载时的负担，缩短加载时间，提高加载效率；同时由于是轻量级对象，把这些对象的创建放在使用时进行，实际就是把创建单例对象所消耗的时间分摊到整个应用中去了，对于整个应用的运行效率没有太大影响。

5 .什么情况下使用单例模式
单例模式也是一种比较常见的设计模式，它到底能带给我们什么好处呢？其实无非是三个方面的作用：

第一、控制资源的使用，通过线程同步来控制资源的并发访问；

第二、控制实例产生的数量，达到节约资源的目的。

第三、作为通信媒介使用，也就是数据共享，它可以在不建立直接关联的条件下，让多个不相关的两个线程或者进程之间实现通信。

比如，数据库连接池的设计一般采用单例模式，数据库连接是一种数据库资源。软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的。当然，使用数据库连接池还有很多其它的好处，可以屏蔽不同数据数据库之间的差异，实现系统对数据库的低度耦合，也可以被多个系统同时使用，具有高可复用性，还能方便对数据库连接的管理等等。数据库连接池属于重量级资源，一个应用中只需要保留一份即可，既节省了资源又方便管理。所以数据库连接池采用单例模式进行设计会是一个非常好的选择。

在我们日常使用的在Windows中也有不少单例模式设计的组件，象常用的文件管理器。由于Windows操作系统是一个典型的多进程多线程系统，那么在创建或者删除某个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象。采用单例模式设计的文件管理器就可以完美的解决这个问题，所有的文件操作都必须通过唯一的实例进行，这样就不会产生混乱的现象。

再比如，每台计算机可以有若干个打印机，如果每一个进程或者线程都独立地使用打印机资源的话，那么我们打印出来的结果就有可能既包含这个打印任务的一部分，又包含另外一个打印任务的一部分。所以，大多数的操作系统最终为打印任务设计了一个单例模式的假脱机服务Printer Spooler，所有的打印任务都需要通过假脱机服务进行。

实际上，配置信息类、管理类、控制类、门面类、代理类通常被设计为单例类。像Java的Struts、Spring框架，.Net的Spring.Net框架，以及Php的Zend框架都大量使用了单例模式。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gaozhilin/archive/2009/04/18/4089838.aspx