`
wolfcame
  • 浏览: 77964 次
  • 性别: Icon_minigender_1
  • 来自: 成都
社区版块
存档分类
最新评论

双检锁(Double-checked Locking)

    博客分类:
  • J2SE
 
阅读更多
双检锁英文又称Double-checked Locking,是在实际开发过程中对多线程单例模式下的延迟加载需求所提出的一个方案。
下面是一个基本的单例模式
 
package cn.fsf.thread; 
public class DoubleCheckedLock { 
    private static DoubleCheckedLock aInstance = new DoubleCheckedLock(); 
    public static DoubleCheckedLock getInstance() { 
        return aInstance; 
    } 
} 


为了提高系统启动速度,我们决定使用延时加载技术,于是对其进行了改进
package cn.fsf.thread;

public class DoubleCheckedLock {
	private static DoubleCheckedLock aInstance;

	public static DoubleCheckedLock getInstance() {
		if (aInstance == null) {
			aInstance = new DoubleCheckedLock();
		}
		return aInstance;
	}
}

现在该类需要在多线程环境下工作,于是又对其进行了改进
package cn.fsf.thread;

public class DoubleCheckedLock {
	private static DoubleCheckedLock aInstance;

	public static synchronized DoubleCheckedLock getInstance() {
		if (aInstance == null) {
			aInstance = new DoubleCheckedLock();
		}
		return aInstance;
	}
}


这样的代码已经能够正常工作了,但是其性能却不甚乐观,为什么呢?原因在于getInstance()方法整个方法体都是同步的,这就限定了其访问速度,最关键的是其实我们增加同步的关键仅仅是同步首次初始化该对象,而对于之后的获取却是不需要进行同步锁定的。于是有人就又做了进一步的改进
package cn.fsf.thread;

public class DoubleCheckedLock {
	private static DoubleCheckedLock aInstance;

	public static DoubleCheckedLock getInstance() {
		if (aInstance == null) {
			synchronized (DoubleCheckedLock.class) {
				if (aInstance == null) {
					aInstance = new DoubleCheckedLock();
				}
			}
		}
		return aInstance;
	}
}


这次改进把同步放到了方法体内,这样仅在第一次调用初始化时才会进入同步代码块,之后便巧妙的避开了同步锁定。大家看这样的代码有问题么?

遗憾的是,这段代码存在很隐蔽的错误,这样的写法在一些平台和优化编译器上可能导致一些问题。

原因在于初始化对象的过程并不是原子操作。
对于 aInstance = new DoubleCheckedLock();一些编译器可以这样处理:
1,aInstantce=新分配的内存地址。
2,执行DoubleCheckedLock的构造函数进行变量初始化。
问题就来了,假如线程A刚执行完第一步,CPU时间耗尽,线程B进入判断第一次的aInstance == null 就不成立了,因为它已经有内存地址了,所以就直接返回了这个对象,但是这个对象还没有被合理的初始化,这样就造成了很隐蔽的错误。

有没有解决的办法呢,
方案一:使用标志位避免对象初始化未完成被其他进程误用
package cn.fsf.thread;

public class DoubleCheckedLock {
	private static DoubleCheckedLock aInstance;
	private static boolean isInstanced;

	public static DoubleCheckedLock getInstance() {
		if (!isInstanced) {
			synchronized (DoubleCheckedLock.class) {
				if (aInstance == null) {
					aInstance = new DoubleCheckedLock();
					isInstanced = true;
				}
			}
		}
		return aInstance;
	}
}

此方法为个人所想出,如您发现有不妥之处,请指出~
2
0
分享到:
评论
7 楼 deyami 2012-05-29  
”问题就来了,假如线程A刚执行完第一步,CPU时间耗尽,线程B进入判断第一次的aInstance == null 就不成立了,因为它已经有内存地址了“

这句话依据从何而来?在synchronized中会发生换出?
6 楼 wzb56 2012-04-28  
package cn.fsf.thread;

public class DoubleCheckedLock {
	private static DoubleCheckedLock aInstance;

	public static DoubleCheckedLock getInstance() {
		if (aInstance == null) {
			synchronized (DoubleCheckedLock.class) {
				if (aInstance == null) {
					DoubleCheckedLock tmp = new DoubleCheckedLock();
                                        aInstance = tmp;
				}
			}
		}
		return aInstance;
	}
}

5 楼 wzb56 2012-04-28  

package cn.fsf.thread;

public class DoubleCheckedLock {
       private DoubleCheckedLock() {}
       
private static DoubleCheckedLock aInstance;

public static DoubleCheckedLock getInstance() {
if (aInstance == null) {
synchronized (DoubleCheckedLock.class) {
if (aInstance == null) {
DoubleCheckedLOck tmp = new DoubleCheckedLock();
                                      aInstance  = tmp;
}
}
}
return aInstance;
}
}
4 楼 wolfcame 2012-02-02  
嗯 谢谢你的意见~
3 楼 iamiwell 2012-02-02  
isInstanced和aInstance是没有数据依赖的,所以在两种情况下都没有顺序保证:
1)编译器做优化的时候(c编译器),因为没有数据依赖,可能为了辅助CPU的流水处理,会重排代码,当然,得根据具体编译器而言,但可以确定的是,既然没有数据依赖,那就没有确定顺序,除非自己添加屏障(java版的volatile的JVM实现就用到了优化屏障)
2) CPU的乱序处理,既然没有数据依赖,那谁先谁后就看CPU了,同样,java版的volatile也是因为增加了内存屏障才予以保证;
我记得这个问题,网上资料应该还蛮多的。
2 楼 wolfcame 2012-02-02  
iamiwell 写道
其实你这种方法,理论上错误依旧,如果aInstantce=新分配的内存地址和isInstanced = true
,都在init之前完成呢。
一种方式:不需要isInstanced,aInstance声明成volatile;
或者,声明isInstanced为volatile也行;

首先,我也考虑到过你说的这个问题,就是isInstanced=true在init之前被调用了,但是这种情况会出现么?我感觉出现的前提是编译器颠倒了代码的执行顺序把isInstanced=true提到了前面执行,否则应该会在init完之后才会调用isInstanced=true这句才对。
其次,假设存在编译器会颠倒代码顺序的情况,那么我们设想下这个在单线程情况下代码的执行情况也就没办法保证了:
1,MyClass myClass = new MyClass();
2,myClass.getXX();


那么现在这个普通的情况下也不能保证在new MyClass()完成init之后才会调用getXX()了,如果是这样,显然java语言稳定性就极差了。所以反过来讲,我觉得应该不会出现这样的情况。
1 楼 iamiwell 2012-02-02  
其实你这种方法,理论上错误依旧,如果aInstantce=新分配的内存地址和isInstanced = true
,都在init之前完成呢。
一种方式:不需要isInstanced,aInstance声明成volatile;
或者,声明isInstanced为volatile也行;

相关推荐

    C++ and the Perils of Double-Checked Locking

    C++ and the Perils of Double-Checked Locking 关于单例模式C++实现的一些问题

    C++ and the Perils of Double Checked Locking.zip

    C++ and the Perils of Double Checked Locking.zip

    基于Java零基础实现《学生成绩管理系统》的简单小项目.zip

    这个小程序涉及到了以下知识点: Java基础知识 队列《数据结构》 单例模式“双检锁/双重校验锁(DCL,即 double-checked locking)”

    c++ and Peris of Double Checked Locking

    C++ 怎么解决 单例模式的线程安全问题

    ACE中的DoubleCheckedLocking模式

    北京火龙果软件工程技术中心意图无论什么时候当临界区中的代码仅仅需要加锁一次,同时当其获取锁的时候必须是线程安全的,可以用DoubleCheckedLocking模式来减少竞争和加锁载荷。动机1、标准的单例。开发正确的有效...

    C++CLI中实现singleton模式

    双重检测锁(Double-Checked Locking)实现的Singleton模式在多线程应用中有相当的价值。在ACE的实现中就大量使用ACE_Singleton模板类将普通类转换成具有Singleton行为的类。这种方式很好地消除了一些重复代码臭味,...

    设计模式解析习题解答,已经做好目录标签

    • Chapter 21: The Singleton Pattern and the Double-Checked Locking Pattern • Chapter 22: The Object Pool Pattern • Chapter 23: The Factory Method Pattern • Chapter 24: Summary of Factories (no ...

    设计模式解析-英文

    各种工厂模式 242 第21章 Singleton模式和Double-Checked Locking模式 249 第22章 Object Pool模式 257 第23章 Factory Method模式 267 第24章 工厂模式的总结 272 第八部分 终点与起点 第25章 设计模式回顾:总结与...

    单例模式详解

    但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器...

    design-patterns:普通英语和简单代码的Java设计模式

    Double checked Locking Initialization on demand holder Strategy Observer Built-in Self made Decorator Description Singleton 确保类只有一个实例,并提供一个全局访问点。 Strategy 策略模式定义了可以相互...

    二十三种设计模式【PDF版】

    主要是介绍各种格式流行的软件设计模式,对于程序员的进一步提升起推进作用,有时间可以随便翻翻~~ 23种设计模式汇集 如果你还不了解设计模式是什么的话? 那就先看设计模式引言 ! 学习 GoF 设计模式的重要性 ...

Global site tag (gtag.js) - Google Analytics