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

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

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

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

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

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