承接上文证明CPU指令是乱序执行的

DCL单例（Double Check Lock）到底需不需要volatile？

new对象这一步，对应着汇编层面的这3个指令，

指令0是申请空间，设置默认值；

指令7是执行构造方法，设置初始值；

指令4是建立栈中的对象名称和堆中对象的关联。

下面详细的介绍下该过程，

在多线程访问的情况下：线程1执行指令1，new对象，此时m值为0即还没有调用构造方法的时候t已经有默认值0了。

在单线程的情况下，只要不影响最终一致性，4和7两个指令可以任意换顺序。

在多线程的情况下，就会出现问题：

假设4和7突然换了顺序即发生了指令重排（new一半发生了指令重排），t和astore先建立关联，

t就指向了创建一半的对象；

当t指向了new了一半的对象的时候，在这个时间点，第二个线程过来了，第二个线程首先判断是否为空，

此时这个t不等于空了，因为它已经指向了初始化一半的对象了，不为空的话，就不需要上锁了，直接拿来用就可以了，此时就访问到了m为0这个状态的对象了即使用了初始化一半的对象。

这个问题就是由于指令的重排序造成的，此时你可能有这个疑问？

都上锁了，只有一个线程才能运行，其他线程居然还能访问到中间状态？

synchroinzed确实可以保证原子性，也能够保证可见性，但是唯一不能保证的是有序性。

synchroinzed里面的顺序，可以随便换，只要能保证单线程的最终一致性。

如果两段代码都是位于同一把锁的情况下，绝对不可能这个线程执行了一半，另外的线程可以看到，

判断实例是否为空的的代码是未上锁的，第二个线程来的时候，不需要上锁就可以进行这个判断。

上锁的代码和不上锁的代码之间是并发运行的，它们之间没有互斥和序列化，未上锁的代码就可以访问到中间状态，虽然上了锁的代码new对象实例化了一半，没有上锁的代码也是可以访问到的，这个时候如果重排序的话，就会访问到中间状态。

这2个指令（指令4和7）为什么可以换顺序？难道java中的指令都可以随便换顺序吗？

不能随便换顺序，比如一个对象还没有new完的时候，就不可能执行finalize方法进行回收或者还没有new完就不能启动。

程序里面规定了这8种情形不可以换顺序，这种被称为happens-before原则，

对象的创建过程

在run main方法的时候，先将源码编译成字节码，然后通过Idea的Show Bytecode With Jclasslib插件工具查看字节码的内容，

这是main方法中生成的整个字节码，相当于java的汇编语言，这段字节码一共有5条语句构成。

new对象的时候转换成java的二进制码会执行这5条指令：

第一步new（对应指令0），申请一块空间，刚刚申请出这块空间的时候m是0；

指令4是一个特殊调用，T.init方法是指执行构造方法，构造方法执行完之后，m才会变成8；

astore指令将栈里面的t和这个对象建立关联。

new一个对象的时候，会有3步构成：

• 指令0：申请一块空间，初始值是0

• 指令4：执行构造方法，初始化成8

• 指令7：将栈中的t和对象关联起来

java中为什么要给个初始值0?

在c++或c语言中申请一块内存的时候，里面有一个成员变量，这个成员变量最开始的值会是多少？

如果不给它赋予初始值，最开始的值叫遗留值，是指原来在这块内存中被用过的值，具体值是随机的，这是c或c++的做法，这也是c++不安全的地方。

java的做法是先给它一个默认的初始化值0，java为什么这么做？

主要是为了安全，如果这里装的正好是上一个程序的密码，如果随随便便的就能访问到上一个程序的遗留值就能够拿到密码了，java做了很多安全上的设计。

著名的this溢出问题

this实际上是方法里面一个默认的形参，this指向的就是自己这个对象的本身。

当new这个对象的时候，申请空间里面的num值会有一个变成0的过程，调用完成构造方法之后才会变成8，在这个构造方法还没有完成的时候，这个线程就启动了，这里的this.num会把0打印出来；

这两条语句（指令4和7）是可以换顺序的；

t看成this，当m=0的时候，4和7交换位置，先执行astore（astore执行完了才会给this.num赋值），构造方法还没有执行完呢，就可以直接建立关联（栈中的t和对象建立关联）了，这个this就是初始化了一半的对象， 这个就叫溢出问题，形象的比喻：穿衣服还没有穿好，就出去见人了。

所以不要在构造方法中启动线程，因为很可能访问到对象初始化一半的状态，不是你期望的那个结果。

单例模式

构造方法被private修饰，目的就是不给别人用，只能自己创建当前类的对象。

但这种写法有问题，在这个对象还没有用的时候，直接先把它创建出来了，会造成空间和cpu资源的浪费，能不能等用到的时候再new？

（为了暴露多线程的问题这里设了一个毫秒）

这是懒汉式单例模式即什么时候用到了才去new，但会出现更大的问题：在多线程访问的情况下，很可能访问的不是同一个对象。

将方法上锁，在同一个时间段内只能有一个线程执行里面的代码，这个线程执行完了，另外一个线程才允许执行里面的代码，这是多线程的原子性，整个的语句当作一个原子，不可分割。

如果锁定的代码中有一些业务逻辑，就会发现锁定的代码耗时就会太长了，比如从db中读取数据的业务逻辑没有必要上锁，为了让锁的粒度稍微变得细一点，让可执行的时间效率稍微高一点，则不给整个方法上锁，

这样缩小了锁的粒度，不将业务代码的是否等于空的判断加锁，等判断为空之后，再上锁，上完锁，再new对象，这是追求效率的写法，但在多线程访问的情况下能不能保证数据的一致性？

第一个线程判断对象为空，在获取锁之前，切换给了第二个线程执行，第二个线程判断对象为空，获取锁，上完锁后，new对象，把锁释放，然后第二个线程结束，在这个时候第一个线程继续运行，因为第一个线程已经判断完了，直接申请上锁，此时是可以上锁成功的，因为第二个线程已经把锁释放了，线程1又new了一个对象。

上完锁之后，再判断是否依然为空，如果依然为空，说明在上锁的过程当中没有其他人把它给new出来，如果还依然保持为空，就把它new出来。

第一个线程在做第一步判断的时候是不为空的，因为第二个线程已经把它new出来了，所以不会再new第二遍，这样就会保证单例的唯一。

双重检查中间加了一个锁，这是很多开源软件非常标准的做法。

最外层的判空有必要吗？

一定有必要存在，假如不做这个判断，确实可以保证整个单例只有一个，但是效率会偏低。

如果有1万个线程都来去new这个对象 ，如果外面没有这层检查，1万个线程都会申请上锁，因为所有线程来了之后都会执行这句话，申请上锁的过程是一个非常重要的过程，只要有外面这层检查的话，只有一个线程new成功了，其他线程来了判断一下不为空，就再也不需要上锁的过程了，这个判断仅1、2个纳秒而已，而这个上锁的动作需要好几百个纳秒，所以外面那层检查是不可以省略的。