首先,介绍一下单例模式:
在Java应用中,单例对象能保证在一个JVM中,该对象只有一个实例存在。
正是由于这个特点,单例对象通常作为程序中的存放配置信息的载体,因为它能保证其他对象读到一致的信息。例如在
某个服务器程序中,该服务器的配置信息可能存放在数据库或 文件中,这些配置数据由某个单例对象统一读取,服务进程中的其他对象如果要获取这些配置信息,只需访问该单例对象即可。这种方式极大地简化了在复杂环境 下,尤其是多线程环境下的配置管理,但是随着应用场景的不同,也可能带来一些同步问题。
单例模式的两种实现方式:
第一种方式:饿汉式,使用static final修饰单例
//饿汉式,静态初始化创建好实例
class Single{
private static final Single s = new Single();
private Single();
public static Single getInstance(){
return s;
}
}
第二种方式:懒汉式,需使用同步保证单例的唯一性
//懒汉式
class SingleLazy{
private static SingleLazy s = null;
private SingleLazy(){}
public static SingleLazy getInstance(){
if(s==null){
synchronized(SingleLazy.class){
if(s==null)
s= new SingleLazy();
}
}
}
}
我们会发现在使用懒汉式的时候使用同步机制,会造成线程的长时间等待,效率不高。这时候聪明的程序猿们使用了双重校验锁。
下列论述摘自:http://www.ibm.com/developerworks/cn/java/j-dcl.html (大家可以看看这篇文章,写的非常好)
双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug,而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”,这也是这些习语失败的一个主要原因。
我们这里只做结论:
为避免单例中代价高昂的同步,程序员非常聪明地发明了双重检查锁定习语。不幸的是,鉴于当前的内存模型的原因,该习语尚未得到广泛使用,就明显成为了一种不安全的编程结构。重定义脆弱的内存模型这一领域的工作正在进行中。尽管如此,即使是在新提议的内存模型中,双重检查锁定也是无效的。对此问题最佳的解决方案是接受同步或者使用一个 static field
。