1.单例模式
先来看一个例子,一台计算机上可以连好几个打印机,但是这个计算机上的打印程序只能有一个,这里就可以通过单例模式来避免两个打印作业同时输出到打印机中,即在整个的打印过程中我只有一个打印程序的实例。简单说来,单例模式(也叫单件模式)的作用就是保证在整个应用程序的生命周期中,任何一个时刻,单例类的实例都只存在一个(当然也可以不存在)。
2.单例模式结构图
看看下面的结构图
从图中我们可以看出,在单例类中有一个私有的构造函数Singleton(“-”号表示私有),有一个公开的GetInstance()方法,由此我们不难看出单例模式的特点,从而给出单例模式的定义:单例模式保证一个类仅有一个实例,同时这个类还必须提供一个访问该类的全局访问点。
3.单例模式的写法
3.1饿汉式单例类
//饿汉式单例类.在类初始化时,已经自行实例化
public class SingletonClass {
private static final SingletonClass instance = new SingletonClass();
private SingletonClass() {
}
public static SingletonClass getInstance() {
return instance;
}
}
问题:SingletonClass在加载的时候就已经实例化了,而我们还不知道这个类会不会被用到,那么做的就是无用功啊。 3.2懒汉式单例类
//懒汉式单例类.在第一次调用的时候实例化
public class SingletonClass {
//注意,这里没有final
private static SingletonClass instance = null;
private SingletonClass() {
}
public static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}
}
代码的变化有两处,instance初始化为null,直到第一词使用的时候通过判断是否为空来创建对象。因为创建过程不在声明处,所以那个final的修饰必须去掉。
3.3同步
上面的代码在单线程的情况下是没有问题的,可是在多线程的情况下,问题就来了。
现在有线程A希望使用SingletonClass,调用getInstance()方法。因为是第一次调用,A就发现instance是null的,于是它开始创建实例,就在这个时候,CPU发生时间片切换,线程B开始执行,它要使用SingletonClass,调用getInstance()方法,同样检测到instance是null——注意,这是在A检测完之后切换的,也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后,切换到A继续执行,因为它已经检测完了,所以A不会再检测一遍,它会直接创建对象。这样,线程A和B各自拥有一个SingletonClass的对象——单例失败!
解决方法有,就是加锁,是要getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。
public class SingletonClass {
private static SingletonClass instance = null;
public synchronized static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}
private SingletonClass() {
}
}
3.4.性能
上面的解决方案既清楚又简单,但是还是有问题的,那就是性能问题,synchronized修饰的同步块可是要比一般的代码段慢上几倍的!如果存在很多次getInstance()的调用,那性能问题就不得不考虑了!
让我们来分析一下,究竟是整个方法都必须加锁,还是仅仅其中某一句加锁就足够了?我们为什么要加锁呢?分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行,那么单例就已经保证了。于是,我们开始修改代码:
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
return instance;
}
private SingletonClass() {
}
}
首先去掉getInstance()的同步操作,然后把同步锁加载if语句上。但是这样的修改起不到任何作用:因为每次调用getInstance()的时候必然要同步,性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢?
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if (instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}
private SingletonClass() { }
}
3.5静态内部类
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种方式同样利用了
classloder
的机制来保证初始化
instance
时只有一个线程,它跟第三种和第四种方式不同的是(很细微的差别):第三种和第四种方式是只要
Singleton
类被装载了,那么
instance
就会被实例化(没有达到
lazy loading
效果),而这种方式是
Singleton
类被装载了,
instance
不一定被初始化。因为
SingletonHolder
类没有被主动使用,只有显示通过调用
getInstance
方法时,才会显示装载
SingletonHolder
类,从而实例化
instance
。想象一下,如果实例化
instance
很消耗资源,我想让他延迟加载,另外一方面,我不希望在
Singleton
类加载时就实例化,因为我不能确保
Singleton
类还可能在其他的地方被主动使用从而被加载,那么这个时候实例化
instance
显然是不合适的。这个时候,这种方式相比第三和第四种方式就显得很合理。