- 浏览: 162130 次
- 性别:
- 来自: 北京
-
文章分类
- 全部博客 (130)
- Database (5)
- JavaSE (23)
- JavaScript (11)
- Struts2 (15)
- Hibernate (11)
- Spring (16)
- Linux (4)
- Jquery (3)
- Tools (12)
- Jsp (7)
- 杂谈 (9)
- WEB Project (10)
- WebService (16)
- maven (2)
- android (1)
- memcache (2)
- 网络通信 (4)
- solr (1)
- cxf (7)
- powerdesigner (1)
- jxls (1)
- springmvc (1)
- nosql (1)
- node.js (0)
- thrift (0)
- REST (1)
- tag (1)
最新评论
单例模式(Singleton Pattern)
前面说提到的五种创建模式,主要解决的问题是如何创建对象,获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。
Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集群、远程EJB等)时、涉及到单例对象被销毁后重建等。对于复杂的情况,本章中会涉及到其中一些[1]
目的:
希望对象只创建一个实例,并且提供一个全局的访问点。
场景:
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;
}
}
/**
* 实现单例访问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;
}
}
/**
* 实现单例访问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;
}
}
/**
* 实现单例访问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 static SingletonKerriganD getInstance() {
if (instance == null) {
synchronized (SingletonKerriganD.class) {
if (instance == null) {
instance = new SingletonKerriganD();
}
}
}
return instance;
}
}
/**
* 实现单例访问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之前JMM(Java Memory Medel)中Cache、寄存器到主内存回写顺序的规定,上面的第二点和第三点的顺序是无法保证的,也就是说,执行顺序可能是1-2-3也可能是1-3-2,如果是后者,并且在3执行完毕、2未执行之前,被切换到线程二上,这时候instance因为已经在线程一内执行过了第三点,instance已经是非空了,所以线程二直接拿走instance,然后使用,然后顺理成章地报错,而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来,真是一茶几的杯具啊。
DCL的写法来实现单例是很多技术书、教科书(包括基于JDK1.4以前版本的书籍)上推荐的写法,实际上是不完全正确的。的确在一些语言(譬如C语言)上DCL是可行的,取决于是否能保证2、3步的顺序。在JDK1.5之后,官方已经注意到这种问题,因此调整了JMM、具体化了volatile关键字,因此如果JDK是1.5或之后的版本,只需要将instance的定义改成“private volatile static SingletonKerriganD instance = null;”就可以保证每次都去instance都从主内存读取,就可以使用DCL的写法来完成单例模式。当然volatile或多或少也会影响到性能,最重要的是我们还要考虑JDK1.42以及之前的版本,所以本文中单例模式写法的改进还在继续。
代码倒越来越复杂了,现在先来个返璞归真,根据JLS(Java Language Specification)中的规定,一个类在一个ClassLoader中只会被初始化一次,这点是JVM本身保证的,那就把初始化实例的事情扔给JVM好了,代码被改成这样:
Java代码
/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {
/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();
public static SingletonKerriganE getInstance() {
return instance;
}
}
/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {
/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();
public static SingletonKerriganE getInstance() {
return instance;
}
}
好吧,如果这种写法是完美的话,那前面那么几大段话就是作者在消遣各位读者。这种写法不会出现并发问题,但是它是饿汉式的,在ClassLoader加载类后Kerrigan的实例就会第一时间被创建,饿汉式的创建方式在一些场景中将无法使用:譬如Kerrigan实例的创建是依赖参数或者配置文件的,在getInstance()之前必须调用某个方法设置参数给它,那样这种单例写法就无法使用了。
再来看看下面这种我觉得能应对较多场景的单例写法:
Java代码
/**
* 实现单例访问Kerrigan的第六次尝试
*/
public class SingletonKerriganF {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
}
public static SingletonKerriganF getInstance() {
return SingletonHolder.INSTANCE;
}
}
/**
* 实现单例访问Kerrigan的第六次尝试
*/
public class SingletonKerriganF {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
}
public static SingletonKerriganF getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种写法仍然使用JVM本身机制保证了线程安全问题;由于SingletonHolder是私有的,除了getInstance()之外没有办法访问它,因此它是懒汉式的;同时读取实例的时候不会进行同步,没有性能缺陷;也不依赖JDK版本。
其他单例模式的写法还有很多,如使用本地线程(ThreadLocal)来处理并发以及保证一个线程内一个单例的实现、GoF原始例子中使用注册方式应对单例类需要需要继承时的实现、使用指定类加载器去应对多ClassLoader环境下的实现等等。我们做开发设计工作的时,应当既要考虑到需求可能出现的扩展与变化,也应当避免“幻影需求”导致无谓的提升设计、实现复杂度,最终反而带来工期、性能和稳定性的损失。设计不足与设计过度都是危害,所以说没有最好的单例模式,只有最合适的单例模式。
到这里为止,单例模式本身就先告一段落了,最后在介绍从其他途径屏蔽构造单例对象的方法:
1.直接new单例对象
2.通过反射构造单例对象
3.通过序列化构造单例对象。
对于第一种情况,一般我们会加入一个private或者protected的构造函数,这样系统就不会自动添加那个public的构造函数了,因此只能调用里面的static方法,无法通过new创建对象。
对于第二种情况,反射时可以使用setAccessible方法来突破private的限制,我们需要做到第一点工作的同时,还需要在在 ReflectPermission("suppressAccessChecks") 权限下使用安全管理器(SecurityManager)的checkPermission方法来限制这种突破。一般来说,不会真的去做这些事情,都是通过应用服务器进行后台配置实现。
对于第三种情况,如果单例对象有必要实现Serializable接口(很少出现),则应当同时实现readResolve()方法来保证反序列化的时候得到原来的对象。
基于上述情况,将单例模式增加两个方法:
Java代码
/**
* 能应对大多数情况的单例实现
*/
public class SingletonKerrigan implements Serializable {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
}
public static SingletonKerrigan getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* private的构造函数用于避免外界直接使用new来实例化对象
*/
private SingletonKerrigan() {
}
/**
* readResolve方法应对单例对象被序列化时候
*/
private Object readResolve() {
return getInstance();
}
}
/**
* 能应对大多数情况的单例实现
*/
public class SingletonKerrigan implements Serializable {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
}
public static SingletonKerrigan getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* private的构造函数用于避免外界直接使用new来实例化对象
*/
private SingletonKerrigan() {
}
/**
* readResolve方法应对单例对象被序列化时候
*/
private Object readResolve() {
return getInstance();
}
}
总结:
本章通过一次次的的尝试,去了解单例模式各种实现方案的优缺点。对双锁锁定检测进行了简单的讨论,相信大家能从各种尝试的演化过程中,明白为何单例模式是最简单而又最复杂的一种构造模式。
各种构造模式之间可以互相比较,但是没有优劣好坏之分,只有确定了上下文环境,才能谈应用什么模式。学习设计模式我觉得也没有必要去强背一些代码模版,应当去理解每种模式的出现的原因和解决的问题,当你发现你的设计需要更大灵活性时,设计便会向着合适的模式演化,这时候你就真正的掌握了设计模式。
前面说提到的五种创建模式,主要解决的问题是如何创建对象,获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。
Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集群、远程EJB等)时、涉及到单例对象被销毁后重建等。对于复杂的情况,本章中会涉及到其中一些[1]
目的:
希望对象只创建一个实例,并且提供一个全局的访问点。
场景:
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;
}
}
/**
* 实现单例访问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;
}
}
/**
* 实现单例访问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;
}
}
/**
* 实现单例访问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 static SingletonKerriganD getInstance() {
if (instance == null) {
synchronized (SingletonKerriganD.class) {
if (instance == null) {
instance = new SingletonKerriganD();
}
}
}
return instance;
}
}
/**
* 实现单例访问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之前JMM(Java Memory Medel)中Cache、寄存器到主内存回写顺序的规定,上面的第二点和第三点的顺序是无法保证的,也就是说,执行顺序可能是1-2-3也可能是1-3-2,如果是后者,并且在3执行完毕、2未执行之前,被切换到线程二上,这时候instance因为已经在线程一内执行过了第三点,instance已经是非空了,所以线程二直接拿走instance,然后使用,然后顺理成章地报错,而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来,真是一茶几的杯具啊。
DCL的写法来实现单例是很多技术书、教科书(包括基于JDK1.4以前版本的书籍)上推荐的写法,实际上是不完全正确的。的确在一些语言(譬如C语言)上DCL是可行的,取决于是否能保证2、3步的顺序。在JDK1.5之后,官方已经注意到这种问题,因此调整了JMM、具体化了volatile关键字,因此如果JDK是1.5或之后的版本,只需要将instance的定义改成“private volatile static SingletonKerriganD instance = null;”就可以保证每次都去instance都从主内存读取,就可以使用DCL的写法来完成单例模式。当然volatile或多或少也会影响到性能,最重要的是我们还要考虑JDK1.42以及之前的版本,所以本文中单例模式写法的改进还在继续。
代码倒越来越复杂了,现在先来个返璞归真,根据JLS(Java Language Specification)中的规定,一个类在一个ClassLoader中只会被初始化一次,这点是JVM本身保证的,那就把初始化实例的事情扔给JVM好了,代码被改成这样:
Java代码
/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {
/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();
public static SingletonKerriganE getInstance() {
return instance;
}
}
/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {
/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();
public static SingletonKerriganE getInstance() {
return instance;
}
}
好吧,如果这种写法是完美的话,那前面那么几大段话就是作者在消遣各位读者。这种写法不会出现并发问题,但是它是饿汉式的,在ClassLoader加载类后Kerrigan的实例就会第一时间被创建,饿汉式的创建方式在一些场景中将无法使用:譬如Kerrigan实例的创建是依赖参数或者配置文件的,在getInstance()之前必须调用某个方法设置参数给它,那样这种单例写法就无法使用了。
再来看看下面这种我觉得能应对较多场景的单例写法:
Java代码
/**
* 实现单例访问Kerrigan的第六次尝试
*/
public class SingletonKerriganF {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
}
public static SingletonKerriganF getInstance() {
return SingletonHolder.INSTANCE;
}
}
/**
* 实现单例访问Kerrigan的第六次尝试
*/
public class SingletonKerriganF {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
}
public static SingletonKerriganF getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种写法仍然使用JVM本身机制保证了线程安全问题;由于SingletonHolder是私有的,除了getInstance()之外没有办法访问它,因此它是懒汉式的;同时读取实例的时候不会进行同步,没有性能缺陷;也不依赖JDK版本。
其他单例模式的写法还有很多,如使用本地线程(ThreadLocal)来处理并发以及保证一个线程内一个单例的实现、GoF原始例子中使用注册方式应对单例类需要需要继承时的实现、使用指定类加载器去应对多ClassLoader环境下的实现等等。我们做开发设计工作的时,应当既要考虑到需求可能出现的扩展与变化,也应当避免“幻影需求”导致无谓的提升设计、实现复杂度,最终反而带来工期、性能和稳定性的损失。设计不足与设计过度都是危害,所以说没有最好的单例模式,只有最合适的单例模式。
到这里为止,单例模式本身就先告一段落了,最后在介绍从其他途径屏蔽构造单例对象的方法:
1.直接new单例对象
2.通过反射构造单例对象
3.通过序列化构造单例对象。
对于第一种情况,一般我们会加入一个private或者protected的构造函数,这样系统就不会自动添加那个public的构造函数了,因此只能调用里面的static方法,无法通过new创建对象。
对于第二种情况,反射时可以使用setAccessible方法来突破private的限制,我们需要做到第一点工作的同时,还需要在在 ReflectPermission("suppressAccessChecks") 权限下使用安全管理器(SecurityManager)的checkPermission方法来限制这种突破。一般来说,不会真的去做这些事情,都是通过应用服务器进行后台配置实现。
对于第三种情况,如果单例对象有必要实现Serializable接口(很少出现),则应当同时实现readResolve()方法来保证反序列化的时候得到原来的对象。
基于上述情况,将单例模式增加两个方法:
Java代码
/**
* 能应对大多数情况的单例实现
*/
public class SingletonKerrigan implements Serializable {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
}
public static SingletonKerrigan getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* private的构造函数用于避免外界直接使用new来实例化对象
*/
private SingletonKerrigan() {
}
/**
* readResolve方法应对单例对象被序列化时候
*/
private Object readResolve() {
return getInstance();
}
}
/**
* 能应对大多数情况的单例实现
*/
public class SingletonKerrigan implements Serializable {
private static class SingletonHolder {
/**
* 单例对象实例
*/
static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
}
public static SingletonKerrigan getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* private的构造函数用于避免外界直接使用new来实例化对象
*/
private SingletonKerrigan() {
}
/**
* readResolve方法应对单例对象被序列化时候
*/
private Object readResolve() {
return getInstance();
}
}
总结:
本章通过一次次的的尝试,去了解单例模式各种实现方案的优缺点。对双锁锁定检测进行了简单的讨论,相信大家能从各种尝试的演化过程中,明白为何单例模式是最简单而又最复杂的一种构造模式。
各种构造模式之间可以互相比较,但是没有优劣好坏之分,只有确定了上下文环境,才能谈应用什么模式。学习设计模式我觉得也没有必要去强背一些代码模版,应当去理解每种模式的出现的原因和解决的问题,当你发现你的设计需要更大灵活性时,设计便会向着合适的模式演化,这时候你就真正的掌握了设计模式。
发表评论
-
Java编程中“为了性能”尽量要做到的一些地方
2012-07-04 14:44 6631.慎用synchronized,尽量减小synchroniz ... -
利用Session防止表单重复提交
2011-12-13 18:36 12021 由于服务器缓慢或者 ... -
java format(MessageFormat)
2011-12-06 17:20 795java.text.Format |__java. ... -
java 主线程等待子线程执行完成后再执行
2011-12-06 09:47 3390原文:http://www.jiacheo.org/blog ... -
Ognl/MVEL/Aviator/JSEL 四种表达式引擎执行效率对比
2011-11-24 10:33 3112http://jindw.iteye.com/blog/732 ... -
java模拟javascript的encodeURI方法
2011-10-27 15:52 2966import java.io.UnsupportedEncod ... -
3种下载文件程序的思考,为何使用NIO进行异步网络通讯
2011-10-08 14:37 730原文链接:http://suhuanzheng7784877 ... -
cglib 动态代理
2011-08-12 10:35 760cglib is a powerful, high perfo ... -
【温故而知新】log4j输出多个自定义日志文件,动态配置路径
2011-08-10 15:38 9061. log4j输出多个自定义日志文件 log ... -
java7 新特性
2011-08-10 10:48 760原文链接:http://www.iteye ... -
Java版短网址(ShortUrl)的算法
2011-06-09 10:42 2760最近,我的项目中需要用到短网址(ShortUrl)的算法,于是 ... -
设计模式学习——适配器模式
2011-06-07 10:30 765某个类拥有我们所 ... -
用spring做一个javaMail功能的例子
2011-05-16 09:37 1236前言:项目中要做一个发送邮件的功能,在网上搜了一些代码,说的都 ... -
UML中几种类间关系:继承、实现、依赖、关联、聚合、组合的联系与区别
2010-10-14 18:38 906今天看到一篇好文,觉得还不错,褪去的记忆被唤醒:http:/ ... -
动态代理
2010-07-13 11:11 763http://www.iteye.com/topic/7103 ... -
ASCLL,Unicode 和 UTF-8
2010-05-15 13:36 14831.Ascll 算是比较早的编码,七位二进制数表示,当然在 ... -
String 详解
2010-05-12 10:29 830解析Java中的String对象的数据类型 1. 首先S ... -
判断数据的类型
2010-05-04 15:24 855// 字符类型 String if (pramets.get( ... -
关于ThreadLocal模式的体会
2010-03-18 11:00 1212本文转至::http://www.iteye.com/topi ... -
javaClassLoader类加载器详解<转>
2010-03-12 14:43 1057由于一个JDBC的基本封装 ...
相关推荐
内容概要:本文详细介绍了基于MATLAB GUI界面和卷积神经网络(CNN)的模糊车牌识别系统。该系统旨在解决现实中车牌因模糊不清导致识别困难的问题。文中阐述了整个流程的关键步骤,包括图像的模糊还原、灰度化、阈值化、边缘检测、孔洞填充、形态学操作、滤波操作、车牌定位、字符分割以及最终的字符识别。通过使用维纳滤波或最小二乘法约束滤波进行模糊还原,再利用CNN的强大特征提取能力完成字符分类。此外,还特别强调了MATLAB GUI界面的设计,使得用户能直观便捷地操作整个系统。 适合人群:对图像处理和深度学习感兴趣的科研人员、高校学生及从事相关领域的工程师。 使用场景及目标:适用于交通管理、智能停车场等领域,用于提升车牌识别的准确性和效率,特别是在面对模糊车牌时的表现。 其他说明:文中提供了部分关键代码片段作为参考,并对实验结果进行了详细的分析,展示了系统在不同环境下的表现情况及其潜在的应用前景。
嵌入式八股文面试题库资料知识宝典-计算机专业试题.zip
嵌入式八股文面试题库资料知识宝典-C and C++ normal interview_3.zip
内容概要:本文深入探讨了一款额定功率为4kW的开关磁阻电机,详细介绍了其性能参数如额定功率、转速、效率、输出转矩和脉动率等。同时,文章还展示了利用RMxprt、Maxwell 2D和3D模型对该电机进行仿真的方法和技术,通过外电路分析进一步研究其电气性能和动态响应特性。最后,文章提供了基于RMxprt模型的MATLAB仿真代码示例,帮助读者理解电机的工作原理及其性能特点。 适合人群:从事电机设计、工业自动化领域的工程师和技术人员,尤其是对开关磁阻电机感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解开关磁阻电机特性和建模技术的研究人员,在新产品开发或现有产品改进时作为参考资料。 其他说明:文中提供的代码示例仅用于演示目的,实际操作时需根据所用软件的具体情况进行适当修改。
少儿编程scratch项目源代码文件案例素材-剑客冲刺.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 转瞬即逝.zip
内容概要:本文详细介绍了基于PID控制器的四象限直流电机速度驱动控制系统仿真模型及其永磁直流电机(PMDC)转速控制模型。首先阐述了PID控制器的工作原理,即通过对系统误差的比例、积分和微分运算来调整电机的驱动信号,从而实现转速的精确控制。接着讨论了如何利用PID控制器使有刷PMDC电机在四个象限中精确跟踪参考速度,并展示了仿真模型在应对快速负载扰动时的有效性和稳定性。最后,提供了Simulink仿真模型和详细的Word模型说明文档,帮助读者理解和调整PID控制器参数,以达到最佳控制效果。 适合人群:从事电力电子与电机控制领域的研究人员和技术人员,尤其是对四象限直流电机速度驱动控制系统感兴趣的读者。 使用场景及目标:适用于需要深入了解和掌握四象限直流电机速度驱动控制系统设计与实现的研究人员和技术人员。目标是在实际项目中能够运用PID控制器实现电机转速的精确控制,并提高系统的稳定性和抗干扰能力。 其他说明:文中引用了多篇相关领域的权威文献,确保了理论依据的可靠性和实用性。此外,提供的Simulink模型和Word文档有助于读者更好地理解和实践所介绍的内容。
嵌入式八股文面试题库资料知识宝典-2013年海康威视校园招聘嵌入式开发笔试题.zip
少儿编程scratch项目源代码文件案例素材-驾驶通关.zip
小区开放对周边道路通行能力影响的研究.pdf
内容概要:本文探讨了冷链物流车辆路径优化问题,特别是如何通过NSGA-2遗传算法和软硬时间窗策略来实现高效、环保和高客户满意度的路径规划。文中介绍了冷链物流的特点及其重要性,提出了软时间窗概念,允许一定的配送时间弹性,同时考虑碳排放成本,以达到绿色物流的目的。此外,还讨论了如何将客户满意度作为路径优化的重要评价标准之一。最后,通过一段简化的Python代码展示了遗传算法的应用。 适合人群:从事物流管理、冷链物流运营的专业人士,以及对遗传算法和路径优化感兴趣的科研人员和技术开发者。 使用场景及目标:适用于冷链物流企业,旨在优化配送路线,降低运营成本,减少碳排放,提升客户满意度。目标是帮助企业实现绿色、高效的物流配送系统。 其他说明:文中提供的代码仅为示意,实际应用需根据具体情况调整参数设置和模型构建。
少儿编程scratch项目源代码文件案例素材-恐怖矿井.zip
内容概要:本文详细介绍了基于STM32F030的无刷电机控制方案,重点在于高压FOC(磁场定向控制)技术和滑膜无感FOC的应用。该方案实现了过载、过欠压、堵转等多种保护机制,并提供了完整的源码、原理图和PCB设计。文中展示了关键代码片段,如滑膜观测器和电流环处理,以及保护机制的具体实现方法。此外,还提到了方案的移植要点和实际测试效果,确保系统的稳定性和高效性。 适合人群:嵌入式系统开发者、电机控制系统工程师、硬件工程师。 使用场景及目标:适用于需要高性能无刷电机控制的应用场景,如工业自动化设备、无人机、电动工具等。目标是提供一种成熟的、经过验证的无刷电机控制方案,帮助开发者快速实现并优化电机控制性能。 其他说明:提供的资料包括详细的原理图、PCB设计文件、源码及测试视频,方便开发者进行学习和应用。
基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf
嵌入式八股文面试题库资料知识宝典-CC++笔试题-深圳有为(2019.2.28)1.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 V1.5.zip
Android系统开发_Linux内核配置_USB-HID设备模拟_通过root权限将Android设备转换为全功能USB键盘的项目实现_该项目需要内核支持configFS文件系统
C# WPF - LiveCharts Project
少儿编程scratch项目源代码文件案例素材-恐怖叉子 动画.zip
嵌入式八股文面试题库资料知识宝典-嵌⼊式⼯程师⾯试⾼频问题.zip