龙空技术网

Java双重检查锁单例真的线程安全吗?

Java斗帝之路 115

前言:

眼前大家对“单例模式线程安全问题”都比较关注,同学们都需要分析一些“单例模式线程安全问题”的相关文章。那么小编同时在网摘上搜集了一些对于“单例模式线程安全问题””的相关文章,希望咱们能喜欢,各位老铁们一起来了解一下吧!

相信大多数同学在面试当中都遇到过手写单例模式的题目,那么如何写一个完美的单例是面试者需要深究的问题,因为一个严谨的单例模式说不定就直接决定了面试结果,今天我们就要来讲讲看似线程安全的双重检查锁单例模式中可能会出现的指令重排问题。

双重检查锁单例模式

乍一看下面单例模式没啥问题,还加了同步锁保证线程安全,从表面上看确实看不出啥问题,当在同一时间多个线程同时执行该单例时就会出现JVM指令重排的问题,从而可能导致某一个线程获取的single对象未初始化对象。

public class Single { private static Single single;  private Single() { }  public static Single getInstance() {  if(null == single) {   synchronized (Single.class) {    if(null == single) {     single = new Single();    }   }  }  return single; }}
问题前因后果

其实single = new Single()这段代码并不具备原子性,从代码层面上来说确实没问题,但是如果了解JVM指令的就知道其实在执行这句代码的时候在JVM中是需要执行三个指令来完成的,如下:

//1:分配对象的内存空间memory = allocate(); //2:初始化对象ctorInstance(memory); //3:设置instance指向刚分配的内存地址instance = memory; 

看到上面指令重排的解释之后,那么我们来回顾一下未加volatile修饰符的单例为何会出现问题。假设有A、B两个线程去调用该单例方法,当A线程执行到single = new Single()时,如果编译器和处理器对指令重新排序,指令重排后:

//1:分配对象的内存空间memory = allocate(); //3:设置instance指向刚分配的内存地址,此时对象还没被初始化instance = memory; //2:初始化对象ctorInstance(memory); 

当A线程执行到第二步(3:设置instance指向刚分配的内存地址,此时对象还没被初始化)变量single指向内存地址之后就不为null了,此时B线程进入第一个if,由于single已经不为null了,那么就不会执行到同步代码块,而是直接返回未初始化对象的变量single,从而导致后续代码报错。

解决方案

问题也搞清楚了,接下来我们就来看下如何解决这个问题。

解决问题的关键就在于volatile关键字,我们来看下volatile关键字的特性。

可见性:

- 写volatile修饰的变量时,JMM会把本地内存中值刷新到主内存 读

- volatile修饰的变量时,JMM会设置本地内存无效

有序性:

要避免指令重排序,synchronized、lock作用的代码块自然是有序执行的,volatile关键字有效的禁止了指令重排序,实现了程序执行的有序性;

看完volatile关键字的特性之后我们应该就明白了,是volatile关键字禁止了指令重排序从而解决了指令重排的问题。

更正后的单例

对比上面单例,下面单例在私有静态变量single前面加了修饰符volatile能够防止JVM指令重排,从而解决了single对象可能出现成员变量未初始化的问题。

public class Single { private volatile static Single single;  private Single() { }  public static Single getInstance() {  if(null == single) {   synchronized (Single.class) {    if(null == single) {     single = new Single();    }   }  }  return single; }}

标签: #单例模式线程安全问题