@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