应用最广泛的设计模式-单例模式(1)

来源:转载

写在前面

其实我也不知道想说什么,来简书已经足足15天了,每天都在通过文字总结和分享自己的所学知识,写技术文章好像也已经成了生活中的一部分了,但是,更重要的是,我要告诉你们,作为一只异地恋狗在大街上看见别的情侣秀恩爱,真的会超想她,有没有和我一样的同胞(掩面失声痛哭),如果我的心情一片黑暗,我将用学习将它照亮!


单例模式


单例模式(Singleton pattern)是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例,要实现这一点,可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制,“阻止”所有想要生成对象的访问。使用工厂方法来限制实例化过程。这个方法应该是静态方法(类方法),因为让类的实例去生成另一个唯一实例毫无意义。其定义是: 一个类有且仅有一个实例,并且自行实例化向整个系统提供。
在安卓中,我们很多时候只需要拥有一个全局对象,这样有利于我们协调整体的行为操作,比如ImageLoader实例,在一个应用中只应该存在一个,因为在ImageLoader中又包含了线程池、缓存系统、网络请求等等,他们是非常消耗资源的,因此,没有理由让它无限制地实例化,这种我们觉得不能随意地构造对象的情况,就是单例模式的应用场景了。
实现单例模式,有几个关键点:


构造函数不对外开放,一般为private。
确保单例类的对象有且只有一个,尤其是在多线程的环境下。
通过一个静态方法或者枚举返回单例对象。
确保单例对象在反序列化的时候不会重新构造对象。

下面我们就来进行一个简单的实例演示。正如我们知道的,在一家公司中通常只有一个CEO,CEO对于公司而言是唯一的,此处我们使用CEO为模拟示例。



public class CEO {
private static final CEO mCEO = new CEO();
private CEO() {}
public static CEO getCEO() {
return mCEO;
}
}

非常简单的代码,CEO类不能通过new的形式构造对象,还能通过CEO.getCEO()函数来获取,而这个CEO对象又是静态(static)对象并且在声明的时候就已经初始化了,这就保证了CEO对象的唯一性。此处介绍的是单例模式的一种,叫做饿汉单例模式。
我们继续学习一下其他的各种单例模式,作者会尽量解释几种实现单例模式的区别。



懒汉模式

懒汉模式是声明一个静态对象,并且在用户第一次调用getInstance时进行初始化,而上面所讲述的CEO类则是在声明静态对象的时候就已经完成了实例化操作。懒汉单例模式的实现方式如下:.


public class CEO {
private static CEO instance;
private CEO() {}
public static synchronized CEO getInstance() {
if (instance == null) instance = new CEO();
return instance;
}
}


善于发现的朋友又看到了,在此处的getInstance方法中有一个关键字synchronized,对synchronized关键字不理解的同学,请跳转到深入理解java中的synchronized关键字。
关键字synchronized在此处声明getInstance为一个同步方法,也就是上面所说的在多线程情况下保证单例对象唯一性的手段。
但是此处存在一个问题,即使我们的Instance已经被初始化了(第一次调用时就会初始化),每次调用getInstance方法都会进行同步,这样会小号不必要的资源,这也是懒汉模式所存在的最大问题。那么,通过上述内容,我们对懒汉模式做一个小小的总结。


优点: 懒汉单例模式只有在使用时才会将类实例化,在一定程度上节约了资源。
缺点: 第一次加载时需要进行实例化,反应稍慢,最大的问题是每次调用getInstance方法都需要进行同步,造成不必要的同步开销。

这种方式一般不推荐使用。




Double Check Lock (DLC)实现单例

这里我们直接上示例代码



public class CEO {
private static CEO sInstance = null;
private CEO() {
}
public static synchronized CEO getInstance() {
if (sInstance == null) {
synchronized (CEO.class) {
if (sInstance == null) {
sInstance = new CEO();
}
}
}
return sInstance;
}
}


我们的关注点依然在getInstance方法上,可以看到我们在该方法中对sInstance做了两次判断是否为空:


第一层判断主要为了避免不必要的同步。
第二层为了在null的情况下创建实例。

估计此时会有部分朋友不知道我在说什么了,没关系,我们一起来进行分析:假设线程A执行到sInstance = new CEO();这里看到的只是简单的一行代码,但实际上会进行多条汇编指令,主要做了三件事情:


给CEO的实例分配内存。
调用CEO的构造函数,初始化成员字段。
将sInstance对象只想分配的内存空间中(完成此步骤时,我们的sInstance就不为null了)

以下内容可根据理解能力选择是否观看


Java编译器是允许程序乱序执行的,以及JDK1.5之前的JMM(Java Memory Model,Java内存模型)中Cache、寄存器到主内存回写顺序规定,上面第二和第三的顺序是无法保证的,也就是说,执行顺序可能是1-3-2,也可能是1-2-3。如果是前者,并且在3执行完毕、2未执行之前,被切换到线程B上,这时候sInstance因为已经在线程A内执行过第三点,sInstance已经是非空的了,所以,线程B会直接取走sInstance,然而在实际上它并没有走完过程2,再使用时就会报错,这就是DCL失效问题。
在JDK1.5以后,SUN官方调整了JVM,具体化了volatile关键字,因此,如果是JDK1.5或者之后的版本,只需要将sInstance的声明改为private volatile static CEO sInstance = null就可以保证sInstance对象每次都是从主内存中读取的,此时,使用DCL来完成单例模式一般是不会出错的,当然,volatile关键字也会牺牲一定的程序性能,但为了程序稳定,牺牲一丁点性能,是值得的。


根据以上所述,DLC模式我们同样地进行适当总结:


优点
资源利用率高,第一次执行getInstance时单例对象才会被实例化,效率高

缺点
第一次加载时反应较慢,也由于Java内存模型原因有时候会失败。
在高并发场景下有一定缺陷。
DLC模式能够在需要的时候才实例化单例对象,并且能够哎绝大多数场景下保证单例对象的唯一性,除非你的代码在高并发场景比较复杂或者低于JDK1.6的版本下使用,否则,这种方式一般能够满足需求。



静态内部单例模式

DLC模式虽然在一定程度上解决了资源消耗、多余的同步、线程安全灯问题,但是,它还是在某些情况下出现失效问题。这个问题被成为双重检查锁定(DLC)失效,在《Java并发编程与实践》一书中,指出这种“优化”是丑陋的,不赞成使用,而建议使用如下代码替代:


public class CEO {
private CEO() {}
public static synchronized CEO getInstance() {
return CEO_Holder.sInstance;
}
private static class CEO_Holder {
private static final CEO sInstance = new CEO();
}
}

当第一加载CEO类的时候并不会初始化sInstance,只有在第一次调用getInstance方法时它才会被初始化,因此,第一次调用getInstance方法会导致虚拟机加载CEO_Holder类,这种方式不仅能够保证线程安全,还能够保证单例对象的唯一性,同时也延迟了单例的实例化,所以这是推荐使用的单例模式实现方式。




分享给朋友:
您可能感兴趣的文章:
随机阅读: