双检锁英文又称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;
}
}
此方法为个人所想出,如您发现有不妥之处,请指出~