设计模式总结:单例模式(以及多线程、无序写入、volatile对单例的影响)
单例模式
http://www.ibm.com/developerworks/cn/java/j-dcl.html
定义:
Ensure a class has only one instance, and provide a global point of access to it.
确保某个类只有一个实例,并提供一个全局访问点。
类图:
public class Singleton{ private static final Singleton instance; private Singleton(){ } public static Singleton getInstance(){ if(instance == null){ //1 instance = new Singleton();//2 } return instance; //3 } ... }
优点:
1)内存中只有一个对象,减少内存开支;
2)单例可避免对资源的多重占用,例如写文件动作,可避免对同一资源文件的同时写操作。
缺点:
1)单例模式一般没有接口,扩展很困难;
——单例并不是用来继承的。
2)不利于测试,并行开发时,若单例未完成,则不能进行测试;
3)与单一职责原则冲突,把“要单例”和业务逻辑融合在一个类中。
使用场景:
若出现多个对象就会出现“不良反应”,应该用单例,具体场景如下:
1)要求生成唯一序列号的环境;
2)在整个项目中需要一个共享访问点或共享数据。例如页面计数器;
3)创建一个对象需要消耗的资源过多时;
4)需要定义大量的静态常量和静态方法的环境。
为什么不直接用全局变量来实现单例?
有缺点:全局变量必须在程序一开始就创建好。而单例模式可以延迟初始化。
类加载器对单例的影响:
不同的类加载器可能会加载同一个类。
如果程序有多个类加载器,可在单例中指定某个加载器,并指定同一个加载器。
多线程的影响:
上文代码示例在多线程环境下有bug:
- 线程 1 调用
getInstance()
方法并决定instance
在 //1 处为null
。
- 线程 1 进入
if
代码块,但在执行 //2 处的代码行时被线程 2 预占。
- 线程 2 调用
getInstance()
方法并在 //1 处决定instance
为null
。
- 线程 2 进入
if
代码块并创建一个新的Singleton
对象并在 //2 处将变量instance
分配给这个新对象。
- 线程 2 在 //3 处返回
Singleton
对象引用。
- 线程 2 被线程 1 预占。
- 线程 1 在它停止的地方启动,并执行 //2 代码行,这导致创建另一个
Singleton
对象。
- 线程 1 在 //3 处返回这个对象。
结果是
getInstance()
方法创建了两个
Singleton
对象。
解决方法一:不用延迟初始化
public class Singleton{ private static final Singleton instance = new Singleton(); private Singleton(){ } public static Singleton getInstance(){ return instance; } ... }
解决方法二:同步getInstance
public class Singleton{ private static final Singleton instance; private Singleton(){ } //同步getInstance public static synchronized Singleton getInstance(){ if(instance == null){ //1 instance = new Singleton();//2 } return instance; //3 } ... }
但是 synchronized
方法会降低性能,尤其这里仅当第一次调用getInstance时才需要同步,只有执行//2代码行时才需要同步。
你可能想到只同步方法块,即只对//2进行同步:
public static Singleton getInstance(){ if(instance == null){ synchronized(Singleton.class) { instance = new Singleton(); } } return instance; }
但这样做并不难解决问题:
当 instance 为 null 时,两个线程可以并发地进入if 语句内部。
然后,一个线程进入 synchronized 块来初始化 instance,而另一个线程则被阻断。
当第一个线程退出 synchronized 块时,等待着的线程进入并创建另一个Singleton 对象。
注意:当第二个线程进入 synchronized 块时,它并没有检查 instance 是否非 null。
还是会创建2个对象!!!!
解决方法三:双重检查加锁
针对上述方法的缺点,我们在//2代码行时 再检查一次null,就能保证只创建一个对象:
//注意volatile private volatile static Singleton instace; public static Singleton getInstance(){ if(instance == null){ synchronized(Singleton.class) { //1 if(instance == null){ //2 instance = new Singleton();//3 } } } return instance; }
假设有下列事件序列:
- 线程 1 进入 getInstance() 方法。
- 由于 instance 为 null,线程 1 在 //1 处进入synchronized 块。
- 线程 1 被线程 2 预占。
- 线程 2 进入 getInstance() 方法。
- 由于 instance 仍旧为 null,线程 2 试图获取 //1 处的锁。然而,由于线程 1 持有该锁,线程 2 在 //1 处阻塞。
- 线程 2 被线程 1 预占。
- 线程 1 执行,由于在 //2 处实例仍旧为 null,线程 1 还创建一个Singleton 对象并将其引用赋值给instance。
- 线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。
- 线程 1 被线程 2 预占。
- 线程 2 获取 //1 处的锁并检查 instance 是否为 null。
- 由于 instance 是非 null 的,并没有创建第二个Singleton 对象,由线程 1 创建的对象被返回。
为什么要用volatile:无序写入
如果不用volatile,则因为内存模型允许所谓的“无序写入”,可能导致失败。——某个线程可能会获得一个为完全初始化的实例。
考察上述代码中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 instance 来引用此对象。这行代码的问题是:在Singleton 构造函数体执行之前,变量instance 可能成为非 null 的。
什么?这一说法可能让您始料未及,但事实确实如此。
在解释这个现象如何发生前,请先暂时接受这一事实,我们先来考察一下双重检查锁定是如何被破坏的。假设清单 4 中代码执行以下事件序列:
- 线程 1 进入 getInstance() 方法。
- 由于 instance 为 null,线程 1 在 //1 处进入synchronized 块。
- 线程 1 前进到 //3 处,但在构造函数执行之前,使实例成为非null。
- 线程 1 被线程 2 预占。
- 线程 2 检查实例是否为 null。因为实例不为 null,线程 2 将instance 引用返回,返回一个构造完整但部分初始化了的Singleton 对象。
- 线程 2 被线程 1 预占。
- 线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它,来完成对该对象的初始化。
注意,1.4之前许多JVM对volatile关键字的实现有问题,还是会导致“双重检查加锁”的失效。
如果想不用volatile:
如果想不用volatile,并且避免无序写入带来的问题,可以用如下代码:
public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { //1 Singleton inst = instance; //2 if (inst == null) { synchronized(Singleton.class) { //3 inst = new Singleton(); //4 } instance = inst; //5 } } } return instance; }
这里的关键行是 //5。此行应该确保 instance 只为 null 或引用一个构造完整的Singleton 对象
BUT,Java 语言规范(Java Language Specification,JLS)要求不能将synchronized 块中的代码移出来。但是,并没有说不能将synchronized 块外面的代码移入synchronized 块中。JIT 编译器会在这里看到一个优化的机会。此优化会删除 //4 和 //5 处的代码,导致还是会有无序写入带来的问题!!!