我的java天地

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

@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

posted on 2011-11-21 15:28 tobyxiong 阅读(225) 评论(0)  编辑  收藏 所属分类: java


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(3)

随笔分类(144)

随笔档案(157)

相册

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜