单例模式的一些版本及演变过程

单例模式的一些版本及演变过程

@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
版本一:只支持单线程，多线程第一次实例化会有两个实例生成
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
} 版本二：多线程版本:每个线程过来都会到要到synchronized 方法块，这样处理效率较低.第一个初始化helper的时候需要locking(加锁)，而后面取用helper的时候，根本不需要线程同步 // Correct multithreaded version
class Foo {
private Helper helper = null;
public synchronized Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
} 版本三：解决每次新建实例都要 synchronized的问题，运用双检锁来实现.此种方法行不通
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}

思路很简单，就是我们只需要同步（synchronize）初始化helper的那部分代码从而使代码既正确又很有效率。

这就是所谓的“双检锁”机制（顾名思义）。

很可惜，这样的写法在很多平台和优化编译器上是错误的。

原因在于：helper = new Helper()这行代码在不同编译器上的行为是无法预知的。一个优化编译器可以合法地如下实现helper = new Helper():

1. helper = 给新的实体分配内存

2. 调用helper的构造函数来初始化helper的成员变量

现在想象一下有线程A和B在调用getHelper，线程A先进入，在执行到步骤1的时候被踢出了cpu。然后线程B进入，B看到的是 helper已经不是null了（内存已经分配），于是它开始放心地使用helper，但这个是错误的，因为在这一时刻，helper的成员变量还都是缺 省值，A还没有来得及执行步骤2来完成helper的初始化。

当然编译器也可以这样实现：

1. temp = 分配内存

2. 调用temp的构造函数

3. helper = temp

如果编译器的行为是这样的话我们似乎就没有问题了，但事实却不是那么简单，因为我们无法知道某个编译器具体是怎么做的，因为在Java的 memory model里对这个问题没有定义（C++也一样），而事实上有很多编译器都是用第一种方法（比如symantec的just-in-time compiler），因为第一种方法看起来更自然。

在上面的参考文章中还提到了更复杂的修改方法，不过很可惜，都是错误的

关于Out-of-order writes现象，就是

helper = new Helper();;

helper已经非空，但对象还没完成实例化，即new new Helper()未完成

详见：

http://www.ibm.com/developerworks/java/library/j-dcl.html

版本四：目前知道最后版。实际应用时需验证一下

private volatile static Singleton instance;  

  

public static Singleton getInstance() {  

    if (instance == null) {  

        synchronized(Singleton.class) {  //1  

            if (instance == null)          //2  

                instance = new Singleton();  //3  

        }  

    }  

    return instance;  

}  

因为存在Out-of-order writes现象，所以这里volatile关键字是在当instance被初始化给Singleton实例时保证多线程正确地处理instance变量，那这里与线程间的可见性有关吗？

我觉得与可见性无关，因为synchronized block已经可以保证块内变量的可见性，这里应该是变量操作的原子性


http://en.wikipedia.org/wiki/Double-checked_locking