单例模式
清单1.单例创建习语
import java.util.*; class Singleton { private static Singleton instance; private Vector v; private boolean inUse; private Singleton() { v = new Vector(); v.addElement(new Object()); inUse = true; } public static Singleton getInstance() { if (instance == null) //1 instance = new Singleton(); //2 return instance; //3 } } |
此类的设计确保只创建一个 Singleton
对象。构造函数被声明为 private
,getInstance()
方法只创建一个对象。这个实现适合于单线程程序。然而,当引入多线程时,就必须通过同步来保护
getInstance()
方法。如果不保护 getInstance()
方法,则可能返回 Singleton
对象的两个不同的实例。假设两个线程并发调用
getInstance()
方法并且按以下顺序执行调用:
- 线程 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
对象,而它本该只创建一个对象。通过同步
getInstance()
方法从而在同一时间只允许一个线程执行代码,这个问题得以改正,如清单 2 所示:
清单2 线程安全的getInstance
()方法
public static synchronized Singleton getInstance() { if (instance == null) //1 instance = new Singleton(); //2 return instance; //3 } |
清单 2 中的代码针对多线程访问 getInstance()
方法运行得很好。然而,当分析这段代码时,您会意识到只有在第一次调用方法时才需要同步。由于只有第一次调用执行了 //2 处的代码,而只有此行代码需要同步,因此就无需对后续调用使用同步。所有其他调用用于决定
instance
是非 null
的,并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。尽管如此,由于该方法是
synchronized
的,需要为该方法的每一次调用付出同步的代价,即使只有第一次调用需要同步。
为使此方法更为有效,一个被称为双重检查锁定的习语就应运而生了。这个想法是为了避免对除第一次调用外的所有调用都实行同步的昂贵代价。同步的代价在不同的 JVM 间是不同的。在早期,代价相当高。随着更高级的 JVM 的出现,同步的代价降低了,但出入
synchronized
方法或块仍然有性能损失。不考虑 JVM 技术的进步,程序员们绝不想不必要地浪费处理时间。
因为只有清单 2 中的 //2 行需要同步,我们可以只将其包装到一个同步块中,如清单 3 所示:
清单3getInstance
()方法
public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { instance = new Singleton(); } } return instance; } |
清单 3 中的代码展示了用多线程加以说明的和清单 1 相同的问题。当 instance
为 null
时,两个线程可以并发地进入
if
语句内部。然后,一个线程进入 synchronized
块来初始化 instance
,而另一个线程则被阻断。当第一个线程退出
synchronized
块时,等待着的线程进入并创建另一个 Singleton
对象。注意:当第二个线程进入
synchronized
块时,它并没有检查 instance
是否非 null
。
双重检查锁定
为处理清单 3 中的问题,我们需要对 instance
进行第二次检查。这就是“双重检查锁定”名称的由来。将双重检查锁定习语应用到清单 3 的结果就是清单 4
清单 4双重检查锁定示例
public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { //1 if (instance == null) //2 instance = new Singleton(); //3 } } return instance; } |
双重检查锁定背后的理论是:在 //2 处的第二次检查使(如清单 3 中那样)创建两个不同的 Singleton
对象成为不可能。假设有下列事件序列:
- 线程 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 创建的对象被返回。
双重检查锁定背后的理论是完美的。不幸地是,现实完全不同。双重检查锁定的问题是:并不能保证它会在单处理器或多处理器计算机上顺利运行。
双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug,而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”,这也是这些习语失败的一个主要原因。
无序写入
为解释该问题,需要重新考察上述清单 4 中的 //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
对象的构造函数并将引用返回给它,来完成对该对象的初始化。
此事件序列发生在线程 2 返回一个尚未执行构造函数的对象的时候。
为展示此事件的发生情况,假设为代码行 instance =new Singleton();
执行了下列伪代码: instance =new Singleton();
mem = allocate(); //Allocate memory for Singleton object. instance = mem; //Note that instance is now non-null, but //has not been initialized. ctorSingleton(instance); //Invoke constructor for Singleton passing //instance. |
这段伪代码不仅是可能的,而且是一些 JIT 编译器上真实发生的。执行的顺序是颠倒的,但鉴于当前的内存模型,这也是允许发生的。JIT 编译器的这一行为使双重检查锁定的问题只不过是一次学术实践而已。
为说明这一情况,假设有清单 5 中的代码。它包含一个剥离版的 getInstance()
方法。我已经删除了“双重检查性”以简化我们对生成的汇编代码(清单 6)的回顾。我们只关心 JIT 编译器如何编译
instance=new Singleton();
代码。此外,我提供了一个简单的构造函数来明确说明汇编代码中该构造函数的运行情况。
双重检查锁定:获取两个
考虑到当前的双重检查锁定不起作用,我加入了另一个版本的代码,如清单 7 所示,从而防止您刚才看到的无序写入问题。
清单 7 解决无序写入问题的尝试
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; } |
看着清单 7 中的代码,您应该意识到事情变得有点荒谬。请记住,创建双重检查锁定是为了避免对简单的三行 getInstance()
方法实现同步。清单 7 中的代码变得难于控制。另外,该代码没有解决问题。仔细检查可获悉原因。
此代码试图避免无序写入问题。它试图通过引入局部变量 inst
和第二个 synchronized
块来解决这一问题。该理论实现如下:
- 线程 1 进入
getInstance()
方法。 - 由于
instance
为null
,线程 1 在 //1 处进入第一个synchronized
块。 - 局部变量
inst
获取instance
的值,该值在 //2 处为null
。 - 由于
inst
为null
,线程 1 在 //3 处进入第二个synchronized
块。 - 线程 1 然后开始执行 //4 处的代码,同时使
inst
为非null
,但在Singleton
的构造函数执行前。(这就是我们刚才看到的无序写入问题。) - 线程 1 被线程 2 预占。
- 线程 2 进入
getInstance()
方法。 - 由于
instance
为null
,线程 2 试图在 //1 处进入第一个synchronized
块。由于线程 1 目前持有此锁,线程 2 被阻断。 - 线程 1 然后完成 //4 处的执行。
- 线程 1 然后将一个构造完整的
Singleton
对象在 //5 处赋值给变量instance
,并退出这两个
synchronized
块。 - 线程 1 返回
instance
。 - 然后执行线程 2 并在 //2 处将
instance
赋值给inst
。 - 线程 2 发现
instance
为非null
,将其返回。
这里的关键行是 //5。此行应该确保 instance
只为 null
或引用一个构造完整的
对象。该问题发生在理论和实际彼此背道而驰的情况下。
Singleton
由于当前内存模型的定义,清单 7 中的代码无效。Java 语言规范(Java Language Specification,JLS)要求不能将
块中的代码移出来。但是,并没有说不能将
synchronizedsynchronized
块外面的代码移入
synchronized
块中。
JIT 编译器会在这里看到一个优化的机会。此优化会删除 //4 和 //5 处的代码,组合并且生成清单 8 中所示的代码。
清单8从清单7中优化来的代码
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 = new Singleton(); } //instance = inst; //5 } } } return instance; } |
如果进行此项优化,您将同样遇到我们之前讨论过的无序写入问题。
最好的解决方法:
public class Test { static { System.out.println("我是用来做测试的,传统的单例模式会在这个时机被实例化"); } public static Test getInstance() { return TestInstance.getInstance(); } private Test() { System.out.println("oh! test"); } private static class TestInstance { private static Test instance = new Test(); private TestInstance() { } private static Test getInstance() { return instance; } }; public static void main(String[] args) { System.out.println(Test.class); System.out.println("========================"); System.out.println(Test.getInstance()); } }