Java多线程 单例模式的DCL问题

public class LazyInitialization{
    private static Resource resource;
 
    public static Resource getResource(){
        if (resource == null)
            resource = new Resource();//不安全！
        return resource;
    }
}

我们都知道上面的这个代码在单线程中运行是没有问题的，但是在平时的开发中常常会使用多线程，此时这个方法就会出现问题，假设有两个线程A、B，当A线程满足判断还未来得及执行到resource = new Resource()时，线程执行资格被B拿走，此时线程B进入getResource(),而此时它也满足resource的值为null,于是导致最后产生两个实例。

针对上面的问题，于是有了相应的解决方案，即线程安全的延迟初始化，可以解决懒汉式出现的上述问题：

public class LazyInitialization{
    private static Resource resource;
 
    public synchronized static Resource getResource(){
        if (resource == null)
            resource = new Resource();
        return resource;
    }
}

上面代码通过使用synchronized关键字将getResource变成同步函数来保证方法的原子性，从而保证了线程安全而防止最后多个线程产生多个实例的现象。

我们都知道，在上述例子当中，每次在调用getResource()时都需要进行同步，而且在大多数时这种同步是没有必要的，并且大量无用的同步会对性能造成极大的影响。为什么呢？因为在第一次调用getResource()方法时就已经创建了resource实例了，之后resource就不再为空，然而之后再调用getResource时都需要进行同步，从而对性能造成了很大的影响。基于这些问题，一个新的方法也就产生了，这也是我们需要着重讨论的一个方法——双重检查加锁(Double Check Lock)DCL，首先我们看看DCL的真面目

public class DoubleCheckedLocking{
    private static Resource resource;
 
    public static Resource getResource(){
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null)
                    resource = new Resource();
            }
        }
        return resource;
    }
}

你可能会疑惑，这样做不是挺好么，这样就可以解决刚刚说的那些问题了么，当resource被实例化后再调用getResource()方法不就不会再进行同步，这样不就节约了资源，提升了性能么？

说的对，DCL确实存在着这些优点，但是与此同时，这个方法也会带来相应的问题，因为这个方法是含有缺陷的：

首先我们看到，DCL方法包含了层判断语句，第一层判断语句用于判断resource对象是否为空，也就是是否被实例化，如果为空时就进入同步代码块进一步判断，问题就出在了resource的实例化语句resource = new Resource()上，因为这个语句实际上不是原子性的。这句话可以大致分解为如下步骤：

1.给Resource的实例分配内存

2.初始化Resource构造器

3.将resource实例指向分配的内存空间，此时resource实例就不再为空

我们都希望这条语句的执行顺序是上述的1——>2——>3，但是，由于Java编译器允许处理器乱序执行，以及JDK1.5之前JMM（Java Memory Medel，即Java内存模型）中Cache、寄存器到主内存回写顺序的规定，上面的第二点和第三点的顺序是无法保证的，也就是说，执行顺序可能是1——>2——>3也可能是1——>3——>2.如果有两个线程A和B，如果A线程执行完1后先执行3然后执行2，并且在3执行完毕、2未执行之前，被切换到线程B上，这时候resource因为已经在线程A内执行过了第三点，resource已经是非空了，所以线程B直接拿走resource，然后使用，然后顺理成章地报错，而且这种难以跟踪难以重现的错误很可能会隐藏很久。
好了，关于DCL的问题阐述完了，那么这个方法既然有问题，那么该如何修改呢？在JMM的后续版本（Java 5.0及以上）中，如果把resource声明为volatile类型，因为volatile可以防止指令的重排序，那么这样就可以启用DCL，并且这种方式对性能的影响很小，因为volatile变量读取操作的性能通常只是略高于非volatile变量读取操作的性能。改进后的DCL方法如下代码所示

public class DoubleCheckedLocking{
    private static volatile Resource resource;
 
    public static Resource getResource{
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null)
                    resource = new Resource();
            }
        }
        return resource;
    }
}

但是，DCL的这种方法已经被广泛地遗弃了，因为促使该模式出现的驱动力（无竞争同步的执行速度很慢，以及JVM启动时很慢）已经不复存在，因为它不是一种高效的优化措施。延迟初始化占位类模式能带来同样的优势，并且更容易理解，延迟初始化占位类模式代码如下：

/**高富帅懒汉单例模式**/
public class BasicLazySingleton {

    private static boolean initialized = false; //单例初始化标志位，添加 volatile 保证其可见性
 
 private DBProperties dbProperties;

    private BasicLazySingleton() {
     synchronized (BasicLazySingleton.class) { //保证线程安全
         if (!initialized) { //首次初始化
             initialized = true; //改变标志位
    
    /**业务逻辑部分**/
    dbProperties = null;
         } else { //多线程同时初始化时，由于 volatile 内存屏障对可见性的保证，initialized 一定已经是 true 了
             throw new RuntimeException("单例已经被初始化过"); //抛出异常
         }
        }
    }

 //final 保证了方法不被重写
    public static final BasicLazySingleton getInstance() {
        return BasicLazySingletonHolder.LAZY;
    }

 public DBProperties getDbProperties {
  return dbProperties;
 }

 /**
 根据 Java 特性
 1、使用内部类，规避了 JVM 加载外部类的时候就单例进行初始化
 2、在外部类被调用的时候内部类才会被加载（类的懒加载）
 3、内部类必须在方法调用之前初始化（对象的懒加载，所以调用 BasicLazySingletonHolder.LAZY 之前，才会去构造 BasicLazySingleton）
 4、由 static 对外部的可见性
 5、final 保证了 LAZY 不被重写
 **/
    static class BasicLazySingletonHolder {
        private static final BasicLazySingleton LAZY = new BasicLazySingleton();
    }
}

参考文献：https://blog.csdn.net/u013393958/article/details/70941579