糟糕的双重检查加锁(DCL)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了糟糕的双重检查加锁(DCL)相关的知识,希望对你有一定的参考价值。

  在Java并发编程时,同步都会存在着巨大的性能开销,因此,人们使用了很多的技巧来降低同步的影响,这其中有一些技巧很好,但是也有一些技巧存在一些缺陷,下面要结束的双重检查加锁(DCL)就是有缺陷的一类。

  由于早期的JVM在性能上存在一些有待优化的地方,因此在并发编程中,延迟初始化经常被用来降低程序的开销。编写正确的延迟初始化需要使用同步,但是直接在初始化之前使用同步会对性能产生影响。所以一些人就提出了双重检查加锁,并声称能够解决这个矛盾。如图所示就是双重检查加锁的代码。

技术分享

  上图代码中,对Resource资源进行延时初始化,在初始化之前需要判断资源是否已经初始化过,所以进行了第一次没有同步的非空判断,resource对象却是为空时,再来对resource对象进行初始化,并将这部分初始化的代码加了类锁进行同步。这代码咋一看确实非常好,首先在第一次非空判断的时候,没有进行同步,只要对象完成了初始化,那么代码就永远走不到同步块中,所以不会有性能问题。但是仔细分析之后,其实是有缺陷的。

  这段代码的缺陷就是线程有可能会使用一个仅被部分构造的Resource对象。双重检查加锁的问题在于,当在没有同步的情况下读取一个共享对象的时候,最坏的情况下,有可能得到的是一个失效的值。这是由于我们在判断对象是否完成初始化是,只是判断对象的引用是否非空,然后在初始化对象时,JVM会在堆上给对象分配一块内存,然后JVM会干两件事,将内存的地址作为引用分配给变量和在堆上初始化这个对象,但是这两件事的先后顺序是不确定的,因此有可能resource非空,但是对象并没有初始化完成。

  所以在实际编程中一定要注意尽量不要使用双重检查加锁,如果一定要使用,那么可以将resource声明为volatile类型,这种方式对性能的影响是很小的,并且还能保证每个线程都能获取到最新的对象。

以上是关于糟糕的双重检查加锁(DCL)的主要内容,如果未能解决你的问题,请参考以下文章

单例模式-双重检查加锁

单例模式双重检查(DCL)引发的多线程问题

java单例模式(双重检查加锁)的原因

双检查锁失效

双重检查加锁单例模式为什么两次判断

单例模式的双重加锁机制为啥要两次检查,第一次检查完不是已经知道了吗?