死磕单例模式的DCL

饿汉式我就不写了，直接写饱汉式吧！！！！
先给大家提供一个测试类，Singleton的代码每个例子都不同，需要更改：

package com.example.demo;

public class Singleton {
    private static Singleton instance = null;
    public static Singleton getInstance() {
        if (null == instance) {
            synchronized (Singleton.class) {
                instance = new Singleton();
            }
        }
        return instance;
    }



    static class ThreadTest extends Thread{
        @Override
        public void run() {
            for (int i = 0; i < 2; i++) {
                System.out.println(Thread.currentThread().getName()+"=="+Singleton.getInstance().hashCode());
            }
        }
    }


    public static void main(String[] args) {
        ThreadTest threadTest = new ThreadTest();
        Thread thread1 = new Thread(threadTest);
        Thread thread2 = new Thread(threadTest);
        Thread thread3 = new Thread(threadTest);
        Thread thread4 = new Thread(threadTest);
        Thread thread5 = new Thread(threadTest);
        thread1.start();
        thread2.start();
        thread3.start();
        thread4.start();
        thread5.start();
    }
}

首先是第一种写法：

public class Singleton {
    private static Singleton instance = null;
    public static Singleton getInstance() {
        if(null == instance) {           
            instance = new Singleton(); 
        }
        return instance;
    }
}

这种在多线程下会有问题大家都知道，我就不赘述了

第二种：

public class Singleton {
    private static Singleton instance = null;
    public synchronized static Singleton getInstance() {
        if(null == instance) {
            instance = new Singleton();
        }
        return instance;
    }
}

或

public class Singleton {
    private static Singleton instance = null;
    public  static Singleton getInstance() {
        synchronized (Singleton.class) {
            if(null == instance) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

这两种基本上是一种写法，就是把get instance和new insatnce一整个动作全都使用锁锁起来，每一次只有一个线程去获取instance。
但存在问题：每个线程进来都是同步操作，相对于逻辑代码而言，每次的同步锁准备占了绝大部分资源，不太划算。

第三种情况：
针对第二种写法改进一点，进来先判断一下，再进入同步代码：

public class Singleton {
    private static Singleton instance = null;
    public  static Singleton getInstance() {
        if(null == instance) {    
            synchronized (Singleton.class) {
                    instance = new Singleton();    
            }
        }
        return instance;

    }
}

改进之后的代码只有当instance ==Null的时候才会进入同步代码，基本上执行完一次new instance之后就不会进入同步代码了？那这个就可以了吗？ 不行！！！ 原因在于：
假设有两个线程A,B
某时刻存在以下情景：
B线程在刚刚同步代码块内，由于B线程还没执行同步代码块，也就意味着instance此时还是等于null的，然后A拿到cpu时间片了，顺利通过了null = = instance的判断。此时由于锁被B持有，那A线程只有阻塞。当B执行完同步代码块后，也就释放了锁。A拿到了锁，进入同步代码块中，创建了一个instance。
所以，这种写法也是多线程不安全的。

那我们再改进以下，根据上面的说法，即使B线程创建了一个insatnce，A线程还是可以进入同步代码块创建对象，那我们就在同步代码块中再加入一个判断不就行了吗？
第四种情况：

public class Singleton {
    private static Singleton instance = null;
    public  static Singleton getInstance() {
        if(null == instance) {    
            synchronized (Singleton.class) {
            if(null == instance){
                    instance = new Singleton();    
                    }
            }
        }
        return instance;

    }
}

emmm，好像解决了这个问题了！！！！！！！！！开心一下。。。。
但是。。。。。。。。。。。。。。。。
学了Java虚拟机之后，我们知道。new一个对象是有三步的：
1.分配内存空间
2.执行方法
3.引用指向该对象（HotSpot采用ThreadLocal解决多线程下的不安全问题，这个有兴趣以后讲）
同时，我们还知道，Java虚拟机会指令重排序，就是对于一些指令它不按照我们预想的顺序去执行，jvm只要保证直接结果一致就行。
那就会带来一下问题：
要是jvm将new insatnce的顺序指令重排序为以下：
1.分配内存空间
2.引用指向该内存空间
3.执行方法，初始化内存空间的值
结果是不是没变，都是得到了一个instance。
欸，万一出现以下场景呢：
A，B两个线程，A进入临界区了，B在临界区外面等着。A线程new完对象了，退出临界区了。那B就进入临界区了，那你说B可以通过第二个null= =insatnce判断吗？一般情况下不行，因为A都已经new了一个了，insatnce都不为空了，B怎么进去。但是出现指令重排序了呢？A在new对象的过程中分配完对象啦，引用也指向该内存空间啦。欸，，，A就退出了同步代码块了。那这个时候B就进去了。然后B就又New了一个insatnce。。
那要怎么解决呢，那就要给这个对象加上volatile关键字了。就是禁止指令重排序（volatile关键字的详细解释以后大家有兴趣再说）
所以最终方案就是：

public class Singleton {
    private volatile static Singleton instance = null;
    public  static Singleton getInstance() {
        if(null == instance) {
            synchronized (Singleton.class) {
                if(null == instance) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}