单例模式——线程同步与线程安全分析

说起单例模式，大家都不会陌生，就拿懒汉式单例模式做介绍，最简单的写法如下：

public class Single {

    private static Single single;

    private Single(){

    }

    public static Single getInstance(){
        if(single==null){
            single = new Single();
        }
        return single;
    }

}

尽管单例模式一眼看上去真的很简单，但是，任何东西与多线程挂上关系，难度就会瞬间提高n个档次。

所以虽然本篇介绍的是单例模式，但是实际上是挂着羊头卖狗肉哈。

目录

一.防止反射打破单例

二.使用synchronized关键字同步代码块

1.多线程的原子性

2.根据原子性思考该代码的问题所在

3.synchronized关键字添加原子性

4.减少同步代码块，优化程序

三.你以为这样就完了？

1.指令重排优化对单例模式的影响

2.volatile关键字屏蔽指令重排优化

---

一.防止反射打破单例

在多线程大餐到来之前，我们先来一个开胃小菜。

众所周知，反射是可以暴力破解private方法的，因此，为了防止我们辛辛苦苦写的单例模式被暴力反射，应当修改构造方法，在遇到反射时，抛出异常。

public class Single {

    private static Single single;

    private static int ctrl = 0;//控制反射时使用，如果实例对象被创建，ctrl=1
    private Single(){
        if(single!=null||ctrl==0){
            //如果single不为空，继续调用构造方法说明此时是被反射调用了，抛出异常
            //如果single为空，但是ctrl=0，说明不是getInstance调用的方法，抛出异常
            throw new RuntimeException("亲，这边拒绝使用反射");
        }
    }


    public static Single getInstance(){
        if(single==null){
            ctrl++;//实例被创建时++，说明Single已经有了实例对象了。
            single = new Single();
        }
        return single;
    }

}

二.使用synchronized关键字同步代码块

在吃完了前面的开胃小菜，我们来分析一下这个单例为什么不是安全的。

1.多线程的原子性：

所谓原子性，和数据库的事务也很像，意思就是说，一段代码，要么全部执行，要么全部不执行。

同样的，就像数据库事务部分字段天生具有原子性，程序代码被细分到极致，也具有原子性（64位操作系统一次原子操作是64位，32位操作系统则是32位，因此在32位操作系统上读取double和long变量并不是原子操作，但是主流的商用虚拟机都会将读取long和double封装成原子操作）。

但是一行Java代码并不代表这一行代码就具有原子性了，实际上被编译成字节码之后，一行代码可能就需要执行很多步才能达到目的。

更何况字节码还要被解析，最终执行者是C语言（这里说的是被C执行，而不是解析成C执行），最后又可能成为汇编语言和机器码，这个时候，简单的一行代码就可能需要几十次原子操作才能完成。 

因此，在绝大部分情况下，我们都可以认为，Java的任意一行代码，都不具有原子性。

2.根据原子性思考该代码的问题所在

if(single==null){
     ctrl++;
     single = new Single();
}

这是我们创建单例对象的代码，且不说底层机器码是否是原子操作，光是Java代码就有两行（不包括ctrl++的话），因此，我们创建对象的过程并不具有原子性，那么在多线程的环境下，该代码可能被线程A执行到一半，就切换给线程B执行了，最后可能产生2个甚至多个对象。

这显然不是我们想要的。

3.synchronized关键字添加原子性

为了让我们创建对象的过程具有原子性，也就是说这个过程要么不执行，如果执行，就要有头有尾，我们需要使用synchronized给该代码添加原子性，最简单的办法，就是加在方法体上：

    public synchronized static Single getInstance(){
        if(single==null){
            ctrl++;
            single = new Single();
        }
        return single;
    }

通过synchronized关键字修饰之后，程序在执行的过程中，同一时间只允许一个线程执行该同步方法，这样做确实可以保证我们的Single对象是单例的。

但是：因为同步的是整块方法，也就是说，即便在Single创建好之后（这个时候我们的代码仅仅只是返回single对象在堆中的内存地址，可以说是很安全的操作），依旧需要排队才能获取single对象，并且本身synchronized关键字就是需要映射到操作系统底层的，使用该关键字如果没有起到该有的作用，会浪费大量的时间（准确来说是因为线程的等待和唤醒需要消耗大量的时间）。

4.减少同步代码块，优化程序

在知道了synchronized关键字会造成性能丢失之后，我们就需要考虑如何解决这个问题。

在上一步的分析中，我们已经知道了性能低下是因为在获取对象操作（该操作在本案例中即便不加锁也是线程安全的）使用同步代码块造成的。

因此我们的解决方案就是，只有当Single创建的时候，才加锁。但是锁加在哪里，就是一门学问了。

错误写法示例：

    public static Single getInstance() {
        //在此处添加锁，程序代码依旧需要先获取锁才能够得到single对象，性能依旧低下。
        synchronized (Single.class) {
            if (single == null) {
                ctrl++;
                single = new Single();
            }
        }
        return single;
    }

    public static Single getInstance() {
        
        //此处有判断条件，因此如果对象已经创建，则不需要进入同步代码块获取锁
        if (single == null) {

            //但是如果线程A在创建对象的过程中，线程B执行到此处，
            //线程B因为没有获取锁，会等待线程A释放锁
            //当线程A创建好single对象并且释放锁之后，线程B则会获取锁并且进入，
            //此时，线程B又会继续new一个新对象
            //线程A：MMP
            synchronized (Single.class) {
                ctrl++;
                single = new Single();
            }
        }
        return single;
    }

正确写法：

    public static Single getInstance() {
        if (single == null) {
            synchronized (Single.class) {
                //在错误示范2的基础上，再加一次判断。
                //即便阻塞之后，线程B执行同步代码块时，sing已经不为null，因此
                //此时线程B不会创建新对象
                if (single == null) {
                    ctrl++;
                    single = new Single();
                }
            }
        }
        return single;
    }

三.你以为这样就完了？

在经过了二的摧残之后，虽然在代码层面，我们的单例模式已经很完美了。

但是

指令重排优化了解一下？

Single单例：MMP

什么是指令重排优化呢？

一般情况下，JVM和CPU为了加快执行效率，会允许在不影响程序结果的情况下，对程序的执行顺序进行重新排序。

例如：

int a = 10;
int c = 20;
a = 50;
c = 80;

上述四句代码在执行时，可能真正执行的顺序是这样

int c = 20;
c = 80;
int a = 10;
a = 50;

当然，真正的JVM和CPU执行过程不是这个样子，他们可能会进行各种优化，但是这并不妨碍我们通过这个例子来了解指令重排优化。

上面四句代码不论是否指令重排，虽然重排后程序的运行顺序发生了很多变化，但是得出的结果都是a=50,c=80，在单线程中，即便指令重排，也不会影响结果。

可如果放到多线程，那就不一定了。

多线程：我有一句MMP不知当讲不当讲。

1.指令重排优化对单例模式的影响

我们已经明白了什么是指令重排优化，那么这个玩意，对我们的单例模式有什么影响呢？

在上面我们说过，我们可以认为任何一句Java代码被编译执行之后，都是不具备原子性的。

就拿创建对象而言：

Single single = new Single();

这一行代码被编译后就是这样：（伪代码）

//1.分配内存地址
addr = new addr();

//2.实例化对象
new Single();

//3.将实例对象的地址传值给single
single = addr;

而经过指令重排优化后，可能执行的顺序就是这样(伪代码)：

//1.分配内存地址
addr = new addr();

//3.将实例对象的地址传值给A
single = addr;

//2.实例化对象
new Single();

也就是说，原本实例化的过程被放到最后执行，而优先将内存地址分配给了single，当分配内存之后，single！=null，但是此时的A实例化还没有完成！！！

如果在线程A实例化single的过程中（此时因为指令重排优化，导致single虽然没有实例化完成，但是已经是个非空对象。）线程B执行getInstance方法，因为single!=null ，所以线程B会直接得到single的地址，但是此时的single还没有实例化完成。

2.volatile关键字屏蔽指令重排优化

volatile关键字修饰的变量被使用时，会为其前后的代码块添加屏蔽字段，该字段被识别后，CPU不会使用指令重排优化来优化处于该字段中的指令，改用正常的顺序执行。

所以，我们的单例模式最终版就是这样子了：

public class Single {
    
    //加上volatile关键字屏蔽指令重排优化
    private volatile static Single single = null;
    private static int ctrl = 0;

    private Single() {
        if (single != null || ctrl == 0) {
            throw new RuntimeException("亲，这边拒绝使用反射");
        }
    }


    public static Single getInstance() {
        if (single == null) {
            synchronized (Single.class) {
                if (single == null) {
                    ctrl++;
                    single = new Single();
                }
            }
        }
        return single;
    }

}

volatile关键字除了可以屏蔽指令重排优化，还能够保证被修饰的字段的可见性。

也就是不管在哪个线程修改了volatile关键字修饰的字段，其他的线程都会感知到，但是在本单例模式中，volatile仅仅用来屏蔽指令重排优化，并没有起到可见性的作用，因此不做介绍。（这个知识点和线程栈有关系，本人很懒，写不动了）。