最近正在看设计模式,发现一点小东西,分享一下~
先上代码
这个相信大家都很熟悉,一眼就能看到问题之所在,这段代码的本意是在整个JVM中创建一个A的实例,所以才会有if(a==null)的检查,但在多线程的情况下了?想象一下有2个Thread,简称t1,t2好了,假设t1比t2先进入这段
1)t1进入if判断,并开始准备执行new A(),此时a还是null
2)t2这时候也进来了,a==null是true,所以t2不可避免的也new了一个
问题就出现了,t1、t2它们各自独立的拥有一个A的实例,没有达到单例的效果
为了克服这个问题,我们稍微改下
现在问题解决了,因为加了synchronized关键字
但再想,这个同步锁只需在A第一次实例化的时候起作用,但以后每次都会要去同步,反成了提升性能的瓶颈了,所以聪明的人想出了下面的优化策略;
这样小小的改动后,我们再分析一下
还是t1,t2
1)t1先到达1处,条件满足a==null,
2)t1到达2,并得到锁,到达3处
3)t1new出了一个A的实例,这时t2进来发现a!=null,所以直接return a
并调用a.getDate();
4)t1调用a.getDate();
A类的变量初始化和变量date的赋值顺序的不可预料性,如果一个线程在没有同步化的条件下去读取a的引用,并调用它的方法,可能会发现date对象的初始化还未完成,进而造成崩溃。
上面这种做法其实在C里面是很常见的,叫双重检查(Double Check),而在java中就不行了,就是因为java编译时的顺序不可预见性,所以一定要多注意.
先上代码
class A{
private static A a = null;
private A(){}
public static A getInstance(){
if(a==null){
a = new A();
}
return a;
}
}
这个相信大家都很熟悉,一眼就能看到问题之所在,这段代码的本意是在整个JVM中创建一个A的实例,所以才会有if(a==null)的检查,但在多线程的情况下了?想象一下有2个Thread,简称t1,t2好了,假设t1比t2先进入这段
1)t1进入if判断,并开始准备执行new A(),此时a还是null
2)t2这时候也进来了,a==null是true,所以t2不可避免的也new了一个
问题就出现了,t1、t2它们各自独立的拥有一个A的实例,没有达到单例的效果
为了克服这个问题,我们稍微改下
class A{
private static A a = null;
private A(){}
public static synchronized A getInstance(){
if(a==null){
a = new A();
}
return a;
}
}
现在问题解决了,因为加了synchronized关键字
但再想,这个同步锁只需在A第一次实例化的时候起作用,但以后每次都会要去同步,反成了提升性能的瓶颈了,所以聪明的人想出了下面的优化策略;
class A{
private static A a = null;
private Date date = new Date();
private A(){}
public Date getDate(){
return date;
}
public static A getInstance(){
if(a==null){//1
//2
synchronized(A.class){
//3
if(a==null){//4
a = new A();
}
}
}
return a;
}
}
这样小小的改动后,我们再分析一下
还是t1,t2
1)t1先到达1处,条件满足a==null,
2)t1到达2,并得到锁,到达3处
3)t1new出了一个A的实例,这时t2进来发现a!=null,所以直接return a
并调用a.getDate();
4)t1调用a.getDate();
A类的变量初始化和变量date的赋值顺序的不可预料性,如果一个线程在没有同步化的条件下去读取a的引用,并调用它的方法,可能会发现date对象的初始化还未完成,进而造成崩溃。
上面这种做法其实在C里面是很常见的,叫双重检查(Double Check),而在java中就不行了,就是因为java编译时的顺序不可预见性,所以一定要多注意.