Android设计模式之单例模式
Posted 冰糖葫芦三剑客
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android设计模式之单例模式相关的知识,希望对你有一定的参考价值。
设计模式中,最简单不过的就是单例模式。先看看单例模式
Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集群、远程EJB等)时、涉及到单例对象被销毁后重建等。
目的:
希望对象只创建一个实例,并且提供一个全局的访问点。
图6.1 单例模式的UML图
结构是简单的,但是却存在一下情况;
1.每次从getInstance()都能返回一个且唯一的一个对象。
2.资源共享情况下,getInstance()必须适应多线程并发访问。
3.提高访问性能。
4.懒加载(Lazy Load),在需要的时候才被构造。
首先实现1中的单例模式A:
[java] view plain copy- 4.public class SingletonA
- 5.
- 6. /**
- 7. * 单例对象实例
- 8. */
- 9. private static SingletonA instance = null;
- 10.
- 11. public static SingletonA getInstance()
- 12. if (instance == null) //line 12
- 13. instance = new SingletonA(); //line 13
- 14.
- 15. return instance;
- 16.
- 17.
这个写法我们把四点需求从上往下检测,发现第2点的时候就出了问题,假设这样的场景:两个线程并发调用Singleton.getInstance(),假设线程一先判断完instance是否为null,既代码中的line 12进入到line 13的位置。刚刚判断完毕后,JVM将CPU资源切换给线程二,由于线程一还没执行line 13,所以instance仍然是空的,因此线程二执行了new Signleton()操作。片刻之后,线程一被重新唤醒,它执行的仍然是new Signleton()操作。所以这种设计的单例模式不能满足第2点需求。
下面我们继续
实现2中单例模式B:
[java] view plain copy- 4.public class SingletonB
- 5.
- 6. /**
- 7. * 单例对象实例
- 8. */
- 9. private static SingletonB instance = null;
- 10.
- 11. public synchronized static SingletonB getInstance()
- 12. if (instance == null)
- 13. instance = new SingletonB();
- 14.
- 15. return instance;
- 16.
- 17.
比起单例A仅仅在方法中多了一个synchronized修饰符,现在可以保证不会出线程问题了。但是这里有个很大(至少耗时比例上很大)的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数之外,以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是很小的,绝大部分的耗时都用在synchronized修饰符的同步准备上,因此从性能上说很不划算。
实现3单例模式C:
[java] view plain copy- 4.public class SingletonC
- 5.
- 6. /**
- 7. * 单例对象实例
- 8. */
- 9. private static SingletonKerriganD instance = null;
- 10.
- 11. public static SingletonC getInstance()
- 12. if (instance == null)
- 13. synchronized (SingletonC.class)
- 14. if (instance == null)
- 15. instance = new SingletonC();
- 16.
- 17.
- 18.
- 19. return instance;
- 20.
- 21.
看起来这样已经达到了我们的要求,除了第一次创建对象之外,其他的访问在第一个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好了.实现4单例模式D:
[java] view plain copy- 4.public class SingletonD
- 5.
- 6. /**
- 7. * 单例对象实例
- 8. */
- 9. private static SingletonD instance = new SingletonD();
- 10.
- 11. public static SingletonD getInstance()
- 12. return instance;
- 13.
- 14.
可带参数单例模式E:
[java] view plain copy- 4.public class SingletonE
- 5.
- 6. private static class SingletonHolder
- 7. Android设计模式之单例模式