一次群聊引发的血案（一）

就在不久前，读者群因为一个提问引发了激烈的讨论！

从问题来看，大家讨论的问题的焦点在于 map 去 put 一个对象的时候，究竟会不会因为对象没有完全初始化完成而导致另外一个线程 get 的时候只是拿到了对象的引用，导致报错呢？

从提供的代码的写法来看，是一个最基本的DCL稍微改变了的写法，在探讨map的问题之前，我想先从DCL(双重检查校验)说起。

DCL的由来

在最初的时候，我们常规的单例写法就像这样：

 
很容易你就应该知道，这段代码不是线程安全的，所以有了加锁的单例方法实现。

 
但是synchronized又会导致多线程下性能开销过大，虽然现在优化了，但是早期synchronized的性能是堪忧的，所以就诞生了双重检查锁定DCL的写法。先判断一次null，然后再加锁，这样第一次检查不是null的话就不需要加锁了，就可以避免synchronized的性能开销过大的问题。

 
看样子问题是解决了，就很棒的样子，但是回到开头说的问题。

DCL的问题

从CPU的角度来看，instance = new Instance()可以分为分为几个步骤：

1. 分配对象内存空间
2. 执行构造方法，对象初始化
3. instance指向分配的内存地址
   实际上，由于指令重排的问题，2、3的步骤可能会发生重排序，那么问题就发生了。

 
instance先被指向内存地址，然后再执行初始化，如果此时另外一个线程来访问getInstance方法，就会拿到instance不是null，最后拿到的将是一个没有被完全初始化的对象！

实际上，这个问题已经是大部分人都知道的DCL的一个问题了。

因为根据Java内存模型语义来说，不管编译器和处理器怎么排序，单线程的执行结果都不能改变，只要数据没有依赖关系，就都可以重排序。

那对上面的例子来说重排序改变了单线程下程序结果吗？并没有，因为无论线程A内是先初始化对象还是先把instance指向分配好的内存地址，对于单线程A的结果来说是没有任何改变的。

也就是说，对于重排序的结果来说，只要保证线程B在访问对象的时候能拿到instance引用就可以，无论线程A内部初始化和执行内存地址两个步骤怎么重排序都不会影响到最终结果。

重排序的结果只是造成了线程B拿到的是一个没有完全初始化完成的对象而已，可能这时候构造方法没有执行，拿到的对象属性可能是错误的，也有可能如果拿着这个没有完全初始化完成的对象去操作，可能会导致空指针的问题。

 
所以，一般在使用DCL的时候会把变量声明为volatile，因为volatile的语义会禁止指令重排，而本质上就是加上了内存屏障。

文章转自公众号：艾小仙