单例模式能够保证一个类仅有唯一的实例,并提供一个全局访问点。
我们是不是可以通过一个全局变量来实现单例模式的要求呢?我们只要仔细地想想看,全局变量确实可以提供一个全局访问点,但是它不能防止别人实例化多个对象。通过外部程序来控制的对象的产生的个数,势必会系统的增加管理成本,增大模块之间的耦合度。所以,最好的解决办法就是让类自己负责保存它的唯一实例,并且让这个类保证不会产生第二个实例,同时提供一个让外部对象访问该实例的方法。自己的事情自己办,而不是由别人代办,这非常符合面向对象的封装原则。
按照以上的思路,我们可以这样来设计单例类:
Java代码:
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、单例类必须为其他对象提供唯一的实例。
安全的单例模式:双重检查锁定机制
我们虽然实现了单例模式,但是目前的解决办法并不安全,依然存在着一定的缺陷:
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对象。
为了实现线程安全,我们对代码进行了一定的改造:
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或者.Net的lock同步化限制,各个线程到达临界区时,就会按照线性方式逐个执行。
我们再来分析一下:
(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 的优化工作,但它是一种非常脆弱的同步机制,比较难以控制,所以建议尽量减少使用。我们后面还提供了其它的一种实现方式。
什么情况下使用单例模式
单例模式也是一种比较常见的设计模式,它到底能带给我们什么好处呢?其实无非是三个方面的作用:
第一、控制资源的使用,通过线程同步来控制资源的并发访问;
第二、控制实例产生的数量,达到节约资源的目的。
第三、作为通信媒介使用,也就是数据共享,它可以在不建立直接关联的条件下,让多个不相关的两个线程或者进程之间实现通信。
比如,数据库连接池的设计一般采用单例模式,数据库连接是一种数据库资源。软件系统中使用数据库连接池,主要是节省打开或者关闭数据库连接所引起的效率损耗,这种效率上的损耗还是非常昂贵的。当然,使用数据库连接池还有很多其它的好处,可以屏蔽不同数据数据库之间的差异,实现系统对数据库的低度耦合,也可以被多个系统同时使用,具有高可复用性,还能方便对数据库连接的管理等等。数据库连接池属于重量级资源,一个应用中只需要保留一份即可,既节省了资源又方便管理。所以数据库连接池采用单例模式进行设计会是一个非常好的选择。
在我们日常使用的在Windows中也有不少单例模式设计的组件,象常用的文件管理器。由于Windows操作系统是一个典型的多进程多线程系统,那么在创建或者删除某个文件的时候,就不可避免地出现多个进程或线程同时操作一个文件的现象。采用单例模式设计的文件管理器就可以完美的解决这个问题,所有的文件操作都必须通过唯一的实例进行,这样就不会产生混乱的现象。
再比如,每台计算机可以有若干个打印机,如果每一个进程或者线程都独立地使用打印机资源的话,那么我们打印出来的结果就有可能既包含这个打印任务的一部分,又包含另外一个打印任务的一部分。所以,大多数的操作系统最终为打印任务设计了一个单例模式的假脱机服务Printer Spooler,所有的打印任务都需要通过假脱机服务进行。
实际上,配置信息类、管理类、控制类、门面类、代理类通常被设计为单例类。像Java的Struts、Spring框架,.Net的Spring.Net框架,以及Php的Zend框架都大量使用了单例模式