@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