单例模式(Singleton Pattern)
Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的
UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton
模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double
checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时、涉及到跨JVM(集
群、远程EJB等)时、涉及到单例对象被销毁后重建等。
目的:
希望对象只创建一个实例,并且提供一个全局的访问点。
场景:
Kerrigan对于Zerg来说是个至关重要的灵魂人物,无数的Drone、Zergling、
Hydralisk……可以被创造、被牺牲,但是Kerrigan得存在关系到Zerg在这局游戏中的生存,
而且Kerrigan是不允许被多次创造的,必须有且只有一个虫族刀锋女王的实例存在,这不是
游戏规则,但这是个政治问题。
分析:
如前面一样,我们还是尝试使用代码来描述访问Kerrigan的过程,看看下面的UML图,
简单得我都不怎么好意思放上来占版面。
单例模式的UML图
结构是简单的,只是我们还有一些小小的要求如下:
1.最基本要求:每次从getInstance()都能返回一个且唯一的一个Kerrigan对象。
2.稍微高一点的要求:Kerrigan很忙,很多人找,所以希望这个方法能适应多线程并发
访问。
3.再提高一点的要求:Zerg是讲究公务员效率的社会,希望找Kerrigan的方法性能尽可
能高。
4.最后一点要求是Kerrigan自己提出的:体谅到Kerrigan太累,希望多些睡觉时间,因
此Kerrigan希望实现懒加载(Lazy Load),在需要的时候才被构造。
5.原本打算说还提要处理多ClassLoader、多JVM等情况,不过还是不要把情况考虑的太
复杂了,暂且先放过作者吧(-_-#)。
我们第一次写的单例模式是下面这个样子的:
Java代码
* 实现单例访问 Kerrigan 的第一次尝试
*/
1. /**
2.
3.
4. public
5.
6.
7.
8.
9.
10.
11.
12.
class
SingletonKerriganA
{
/**
* 单例对象实例
*/
private
static
SingletonKerriganA
instance
=
null;
public
static
if
SingletonKerriganA
{
null)
(instance
==
getInstance()
{
//line
A
instance =
new SingletonKerriganA();
//line
B
}
return
instance;
}
13.
14.
15.
16.
17. }
/**
* 实现单例访问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 的第二次尝试
*/
class
SingletonKerriganB
{
/**
* 单例对象实例
*/
private
static
SingletonKerriganB
instance
=
null;
public
synchronized static
SingletonKerriganB
getInstance()
if
(instance
==
null)
{
instance =
new SingletonKerriganB();
}
return
instance;
}
1. /**
2.
3.
4. public
5.
6.
7.
8.
9.
10.
11.
{
12.
13.
14.
15.
16.
17. }
/**
* 实现单例访问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 的第三次尝试
*/
1. /**
2.
3.
4. public
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
class
SingletonKerriganC
{
/**
* 单例对象实例
*/
private
static
SingletonKerriganC
instance
=
null;
public
SingletonKerriganC
static
synchronized (SingletonKerriganC.class)
getInstance()
{
{
if
(instance
==
null)
{
instance =
new SingletonKerriganC();
}
}
return
instance;
}
15.
16.
17.
18.
19. }
/**
* 实现单例访问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代码
1. /**
2.
* 实现单例访问 Kerrigan 的第四次尝试
class
SingletonKerriganD
{
/**
* 单例对象实例
*/
private
static
SingletonKerriganD
instance
=
null;
public
static
if
SingletonKerriganD
{
null)
(instance
==
getInstance()
{
synchronized (SingletonKerriganD.class)
{
if
(instance
==
null)
{
instance =
new SingletonKerri
}
}
}
return
instance;
}
*/
3.
4. public
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
ganD();
16.
17.
18.
19.
20.
21. }
/**
* 实现单例访问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好了,代码被改成这样:
* 实现单例访问 Kerrigan 的第五次尝试
*/
Java代码
1. /**
2.
3.
4. public
5.
6.
7.
8.
9.
class
SingletonKerriganE
{
/**
* 单例对象实例
*/
private
static
SingletonKerriganE
instance
=
new
Singleton
KerriganE();
public
static
return
SingletonKerriganE
instance;
getInstance()
{
}
10.
11.
12.
13.
14. }
/**
* 实现单例访问Kerrigan的第五次尝试
*/
public class SingletonKerriganE {
/**
* 单例对象实例
*/
private static SingletonKerriganE instance = new SingletonKerriganE();
public static SingletonKerriganE getInstance() {
return instance;
}
}
好吧,如果这种写法是完美的话,那前面那么几大段话就是作者在消遣各位读者。这种
写法不会出现并发问题,但是它是饿汉式的,在ClassLoader加载类后Kerrigan的实例就会
第一时间被创建,饿汉式的创建方式在一些场景中将无法使用:譬如Kerrigan实例的创建是
依赖参数或者配置文件的,在getInstance()之前必须调用某个方法设置参数给它,那样这
种单例写法就无法使用了。