基本概念

在说清楚为什么为什么要两次校验之前，先了解一下几个基本概念
在多线程中，在考察线程同步，有三个比较重要的性质：

• Atomicity，原子性
• Visibility，可见性
• Ordering，有序性

原子性

概念

原子性或者说原子操作是指一个操作时不可中断的，这个操作执行要么全部成功要不全部失败，不可能存在成功一部分，失败一部分的情况。即使是在并发场景里，原子操作一旦开始执行就不会受到其他线程的影响。

lock与unkock操作是为了保证更大范围的原子性操作，被lock和unlock操作包含了多个操作是原子性的，这些操作能够全部被执行。这两个操作映射到JVM指令中即为moniterenter和moniterexit指令，被moniterenter和moniterexit指令包含的指令可以全部被执行，代码层面上即表现为synchronized关键字，所以synchronized可以保证原子性。但是这里需要声明不是只有加锁才能保证原子性，还可以通过无锁操作(如比较并交换CAS、加载链接/条件存储LL/SC等)也能保证原子性，只要这么指令能保证操作不能被中断即可。

为什么有原子性问题

显而易见的，a =10 是原子操作，是因为虚拟机内部实现做了保证。而a++不是原子操作，看起来只有一行代码，一个操作，但是a++等同于a = a + 1处理器执行过程中被分为了三个操作，大体可以看成：

• 将a从内存中读到寄存器中，
• 在寄存器中将a的值加1，
• 将寄存器中的值写回到内存中。

类比到虚拟机中，即为将将a从主存中读到线程工作内存中，在工作内存中将a的值加1，将工作内存中的值写回到主存。它是可分的，意味着是可中断的，所以a++不是原子操作。

那么为什么会有原子性问题呢，在博客线程安全中我们提到了时间片的概念，其中时间片的轮转造成了原子性问题。时间片的轮转导致了操作被分割，一旦被分割，当前线程就失去了将操作全部完成的可能性，产生了原子性问题。

解决办法

原子性不可能由软件单独保证，必须需要硬件的支持，因此是和架构相关的。

• 总线锁：在x86 平台上，CPU提供了在指令执行期间对总线加锁的手段。
• 缓存锁：是指内存区域中的数据如果已经被缓存在处理器的缓存行中，并且缓存行的数据在Lock操作期间被锁定时，那么当它执行锁操作到内存时，通过缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行数据时，会使缓存行无效。就整体来说，是当某块CPU对缓存中的数据进行操作了之后，就通知其他CPU放弃储存在它们内部的缓存，或者从主内存中重新读取。
• 此外，我们常说的无锁操作保证原子性底层也是通过硬件保证的，如CAS是通过cmpxchg指令(IA64、x86架构)或casa指令(sparc-TSO架构)完成的、LL/SC是通过一对Idrex/strex指令(ARM、PowerPC架构)完成的。

可见性

概念

可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。在Java内存模型中，一个线程修改共享变量的值是在工作内存中完成的，而其他线程是无法访问该线程的工作内存的，修改完成后再将新的值同步回主内存中；其他线程需要从主内存读取变量的值才能获知修改，实现可见性。

为什么有可见性问题

因为在修改成新的值再到同步回主内存中这两个动作不是连续发生的，所以导致其他线程不能够立即得知这个修改。当前线程修改工作内存中该共享变量的值，其他线程读取内存中该变量未修改前的值，当前线程再将修改后的值同步回内存中，于是就产生了可见性问题。

解决办法

• 在原子性中我们提到，synchronized底层通过lock和unlock实现原子性，synchronized同样可以保证可见性。因为在Java内存模型中我们提到：对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store、write操作)。而在对一个变量执行unlock操作之前，其他线程是无法访问该变量的。而在unlock结束，其他线程访问变量的值肯定是已经修改之后的值了。
• volatile同样可以保证可见性。因为在Java内存模型中我们提到：每次修改volatile变量的值后必须立刻同步回主内存，每次使用volatile变量前必须从主内存中刷新最新值。所以每次修改后的值在其他线程使用变量前(从主内存读取)都能被感知。
• final也可以保证可见性。被final修饰的字段在构造器中一旦初始化完成，并且没有把“this”的引用传递出去，那么在其他线程中就能看见final字段的值。也有的书籍中将final的可见性称为final的不变性，因为不变，那么不需要任何同步手段，就能保证任意线程看到的final字段。

有序性

概念

Java中天然的有序性是指：在本线程内观察，操作都是有序的；如果在一个线程中观察另外一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句是指“指令重排序”和工作内存与主内存同步延迟的现象。所以，在同一个线程内，所有的操作都是串行的，有序的，但是多个线程并行的情况下，则不能保证其操作的有序性。

为什么有有序性问题

在概念中已经提到原因：指令重排序和工作内存与主内存同步延迟。这两个原因造成程序的书写顺序(单线程下串行的有序)与实际CPU的执行顺序(多线程下顺序是不可预测的)是不一致的更深层次的原因就是硬件原因了：CPU为了优化性能，缓存与主内存的访问速度差异导致最终的顺序产生变化，最终造成有序性问题。

计算机执行程序时并不一定是按照我们编写的程序由上至下顺序执行，编译器和CPU会在保证输出结果和顺序执行一样的前提下， 对指令进行重排序，使性能得到优化。如果CPU是单核，那这种优化不会带来线程执行冲突。但多核CPU的情况下，多线程并发操作共享变量，这种指令重排序可能导致意想不到的结果。

解决办法

• synchronized可以保证有序性。因为因为在Java内存模型中我们提到：一个变量在同一时刻只允许一条线程对其进行lock操作。所以，线程实质上串行执行的。
• volatile同样可以保证有序性。volatile 是因为其本身包含“禁止指令重排序”的语义

DCL单例

代码

public class SingletonDemo {
    
    private SingletonDemo() {
    
    }

    private volatile static SingletonDemo instance = null;

    public static SingletonDemo getInstance() {
    
        //第一重检查：如果已经初始化完成，直接返回实例
        if (instance == null) {
    
            synchronized (SingletonDemo.class) {
    
                //第二重锁检查(针对比如A,B两个线程都为null，第一个线程创建完对象，第二个等待锁的线程拿到锁的情况)
                if (instance == null) {
    
                    instance = new SingletonDemo();
                }
            }
        }
        return instance;
    }
}
/*
new 一个对象的过程
1.在堆中分配对象内存
2.填充对象必要信息+具体数据初始化+末位填充
3.将引用指向这个对象的堆内地址
 */

外层判空

第一个if语句，用来确认调用getInstance()时instance是否为空，如果不为空即已经创建，则直接返回，如果为空，那么就需要创建实例，于是进入synchronized同步块。

避免每次获取实例的时候都需要获取锁和释放锁，这样会带来很大的性能消耗，外层判空可以在已经初始化完成后，直接返回实例对象。

内层判空

内层判空是为了保证对象的单例，因为在多线程情况下，如果没有内层判空的话，那么多个线程可能在竞争锁之前都已经通过了外层判空逻辑，那么在这种情况下，会出现多个实例对象。所以加上内层判空，那么另一个线程进来后，再次判空的时候对象已经被之前释放锁的线程初始化完成，那么自然不会进入new对象的逻辑中，从而保证了对象的单一。

synchronized加类锁，确保同时只有一个线程能进入，进入以后进行第二次判断，是因为，对于首个拿锁者，它的时段instance肯定为null，那么进入new Singleton()对象创建，而在首个拿锁者的创建对象期间，可能有其他线程同步调用getInstance()，那么它们也会通过if进入到同步块试图拿锁然后阻塞。
这样的话，当首个拿锁者完成了对象创建，之后的线程都不会通过第一个if了，而这期间阻塞的线程开始唤醒，它们则需要靠第二个if语句来避免再次创建对象。以上就是双检索的实现思路，synchronized与第二个if即是用来保证线程安全与不产生第二个实例，也是Double_Checked_Lock由来。

volatile的使用

主要用例禁止指令重排序。因为INSTANCE = new Singleton() 主要分为三步：

1. 为对象开辟内存空间
2. 对象初始化
3. 将对象引用赋值个变量。

如果能够保证2，3的顺序那么就不会存在安全问题，但是实际因为JIT和处理器会对代码进行优化重排序，那么可能会2，3的顺序颠倒，那么就有可能会出现一个线程拿到了一个未被初始完成的对象，从而引发安全问题。所以需要添加volatile关键字禁止指令重排序

如果没有volatile会有什么后果呢？
那么，在完成1后，对象的大小和地址已经确定，因此，2和3其实存在指令重排序的可能。并且可以看到，3的操作明显比2要少，那么如果让2与3一起执行，并且反应到具体的顺序上变成了1-3-2.先完成3，引用变量instance先指向了在堆中给对象分配的空间，然后2仍在慢慢吞吞继续。这时候，被synchronized挡在外面的阻塞线程其实是不会有什么影响的，因为一定会等到对象创建完，首个拿锁者才会释放锁。
那么关键是在，此刻如果在3完成而2未完成这个临界点，有一个新线程调用getInstance()，那么第一个if，会怎么样？
答案是因为第一个if没在同步块里，而此时instance已经非空，指向具体内存地址了，所以直接返回此时未完成初始化的instance实例。

懒汉式、饿汉式

区别

• 1、懒汉比较懒，只有当调用getInstance的时候，才回去初始化这个单例。
• 2、饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了

线程安全:

饿汉式天生线程安全，可直接用于多线程，无任何问题，

懒汉风格本身是非线程安全的(双检锁解决并发问题)

资源加载和性能:

• 饿汉式在类创建的同时实例化一个静态对象出来，无论以后是否使用该单例，都会占用一定的内存，但相应地，由于其资源已初始化，第一次调用的速度也会更快。
• 懒汉式，会延迟加载，在第一次使用本单例时才会出现实例对象，第一次调用时要做初始化，如果要做的工作比较多，性能会有些延迟，以后就像饿汉式一样。

懒汉代码

/**
 * 单例模式-饿汉模式
 * 在类加载的时候就会创建对象
 */
class GirlFriend {
    
    public String name;
 
    private static GirlFriend gf = new GirlFriend("小红");
 
    public static GirlFriend getGf() {
    
        return gf;
    }
 
    /**
     * 构造器私有化,不能在本类之外new
     * @param name
     */
    private GirlFriend(String name) {
    
        this.name = name;
    }
 
    @Override
    public String toString() {
    
        return "GirlFriend{" +
                "name='" + name + '\'' +
                '}';
    }
}

饿汉代码

/**
 * 单例模式-懒汉模式
 * 1.构造器私有化
 * 2.提供一个static静态属性对象
 * 3.提供一个public的static方法,返回一个实例对象
 * 4.懒汉模式,只有在用户调用方法时,才会创建对象,之后再次调用,返回的是同一对象
 */
class Cat {
    
    private String name;
 
    private static Cat cat;
 
    private Cat(String name) {
    
        this.name = name;
    }
 
    public static Cat getCat() {
    
        if (cat == null) {
    
            cat = new Cat("加菲猫");
        }
        return cat;
    }
 
    @Override
    public String toString() {
    
        return "Cat{" +
                "name='" + name + '\'' +
                '}';
    }
}

参考博客

• 原子性、可见性、有序性
• 原子性、可见性、有序性基本概念
• 原子性、可见性、有序性
• 笔记 - 原子性、可见性和有序性

---

• DCL单例模式为什么要两次判空
• DCL的理解