java并发编程实战(5) happen-before原则和彻底明白DCL的volatile作用。

﹏ヽ暗。殇╰゛Y 2022-09-26 00:27 6阅读 0赞

> 应用场景：我们需要一个单例模式：一个类有且仅有一个实例，并且自行实例化向整个系统提供。

# 一、普通懒汉式单例模式 #

--------------------

我们先看单例模式里面的懒汉式：

public class Singleton \{  
    private static Singleton singleton;

private Singleton()\{\}

public static Singleton getInstance()\{  
        if(singleton == null)\{  
            singleton = new Singleton();  
        \}

return singleton;  
    \}  
\}  
我们都知道这种写法是错误的，因为它无法保证线程的安全性。为了确保安全性，就是在getInstance方法上面做了同步，但是synchronized就会导致这个方法比较低效，导致程序性能下降。

因此我们把synchronized放在方法同步为：DCL  即Double Check Lock，中卫双重检查锁定。

public class Singleton {
        private static Singleton singleton;
    
        private Singleton(){}
    
        public static Singleton getInstance(){
            if(singleton == null){                              // 1
                synchronized (Singleton.class){                 // 2
                    if(singleton == null){                      // 3
                        singleton = new Singleton();            // 4
                    }
                }
            }
            return singleton;
        }
    }

就如上面所示，DCL：A 线程进行判空检查之后开始执行synchronized代码块时发生线程切换(线程切换可能发生在任何时候)，B 线程也进行判空检查，B线程检查 singleton == null 结果为true，也开始执行synchronized代码块，虽然synchronized 会让二个线程串行执行，如果synchronized代码块内部不进行二次判空检查，singleton 可能会初始化二次。

这个代码看起来很完美，理由如下：

1.  如果检查第一个singleton不为null,则不需要执行下面的加锁动作，极大提高了程序的性能；
2.  如果第一个singleton为null,即使有多个线程同一时间判断，但是由于synchronized的存在，只会有一个线程能够创建对象；
3.  当第一个获取锁的线程创建完成后singleton对象后，其他的在第二次判断singleton一定不会为null，则直接返回已经创建好的singleton对象；

但是这种DCL方式其实是有缺陷的，具体什么缺陷呢？我们先看看happen-before原则

# 二、happen-before原则 #

--------------------

Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程的程序执行，却会影响到多线程并发执行的正确性。可以通过volatile、synchronize、Lock来保证一定的有序性。

JMM中具有一定先天的有序性，不需要任何手段就能保证有序性，这就是我们经常见到的happens-before原则。重排序需要遵守happens-before规则，不能说你想怎么排就怎么排。

**Happen-Before八大原则：**

> **1）单线程happen-before原则（程序顺序规则）：**在同一个线程中，书写在前面的操作happen-before后面的操作。
> 
> 这条规则是说，在单线程中操作间happen-before关系完全是由源代码的顺序决定的，这里的前提“在同一个线程中”是很重要的。
> 
> **2）锁的happen-before原则（****锁管理原则****）：**同一个锁的unlock操作happen-before此锁的lock操作。
> 
> 这里的“后续”指的是时间上的先后关系，unlock操作发生在退出同步块之后，lock操作发生在进入同步块之前。这是条最关键性的规则，线程安全性主要依赖于这条规则。
> 
> 这里关键条件是必须对“同一个锁”的lock和unlock。但是仅仅是这条规则仍然不起任何作用，它必须和**传递性原则**联合起来使用才显得意义重大。
> 
> **3）volatile的happen-before原则（）：**对一个volatile变量的写操作happen-before对此变量的任意（读/写）操作(当然也包括写操作了)。
> 
> **4）happen-before的传递性原则：**如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。

前四条规则是比较重要的，后四条是比较显而易见的。

> **5）线程启动的happen-before原则（****start()规则****）：**同一个线程的start方法happen-before此线程的其它方法。
> 
> **6）线程中断的happen-before原则（**程序中断规则**）：**即对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。(**线程t1写入的所有变量，调用Thread.interrupt()，被打断的线程t2，可以看到t1的全部操作**)
> 
> 7）线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。可以通过Thread.join（）方法结束、Thread.isAlive（）的返回值等手段检测到线程已经终止执行。  
> (**线程t1写入的所有变量，在任意其它线程t2调用t1.join()，或者t1.isAlive() 成功返回后，都对t2可见。**)
> 
> **8）对象创建的happen-before原则（对象finalize规则）：**一个对象的初始化完成先于他的finalize方法调用。(**对象调用finalize()方法时，对象初始化完成的任意操作，同步到全部主存同步到全部cache。**)

**如果两个操作的执行次序无法从happens-before规则推导出来，那么就不能保证他们的有序性，虚拟机就可以随意的对他们进行重排序。**

举例（即happens-before关系并不代表了最终的执行顺序）

public double rectangleArea(double length , double width){
            double len;
            double wid;
            len=length;//A
            wid=width;//B
            double area=leng*wid;//C
            return area;
    }

上面的操作在运行之前编译器和处理器可能会进行优化，在程序中

A  happens-before  B

B  happens-before C

A  happens-before C //happens-before具有传递规则

（1）因为A  happens-before  B，所以A操作产生的结果leng一定要对B操作可见，但是现在B操作并没有用到length，所以这两个操作可以重排序；

（2）如果A操作和C操作进行了重排序，因为leng没有被赋值，所以leng=0，area=0\*wid也就是area=0，A和C不能进行重排序；

# 三、DCL方式的缺陷分析 #

--------------------

但是这种DCL方式其实是有缺陷的，具体什么缺陷呢？

当线程A在获取了Instance.class锁时，对singleton进行 singleton = new Instance() 初始化时，实例化一个对象要分为三个步骤：

step1、 分配内存空间。  
step2、 初始化对象。  
step3、 将内存空间的地址赋值给对应的引用。

**我们使用synchronized ，在synchronized代码块内 ，指令符合****锁的happen-before原则（****锁管理原则****）****，**但step2和step3这两步并不违反Happen-Before规则，因此可以指令重排序，类似的有x=1，y=1，z=x+y可以被编译器优化为y=1，x=1，z=x+y。  
正是因为指令重排序，所以上面的过程也可能变为如下的过程：  
step1、 分配内存空间。  
step3、 将内存空间的地址赋值给对应的引用。  
step2、 初始化对象 。

如果发生了重排序：，此时线程A的singleton只分配内存地址，但还没有初始化对象，此时singleton是不为空的。

那么就回导致线程B在红框部分判断会出错,直接返回singleton变量，即return的singleton对象是一个没有被初始化的对象。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70][]

当然，指令重排序的问题并非每次都会进行，在某些特殊的场景下，编译器和处理器是不会进行重排序的，但上述的举例场景则是大概率会出现指令重排序问题。

# 四、解决方案 #

--------------------

## 1、基于volatile解决方案 ##

[java并发编程实战(2)：volatile实现原理][java_2_volatile]：volatile的特性是确保变量可见性和禁止指令重排。

对于上面的DCL其实只需要做一点点修改即可：将变量singleton声明为volatile即可：

public class Singleton {
        //通过volatile关键字来确保安全
        private volatile static Singleton singleton;
    
        private Singleton(){}
    
        public static Singleton getInstance(){
            if(singleton == null){
                synchronized (Singleton.class){
                    if(singleton == null){
                        singleton = new Singleton();
                    }
                }
            }
            return singleton;
        }
    }

当singleton声明为volatile后：对它的写操作就会有一个内存屏障，这样，在singleton的赋值完成之前，就不用会调用读操作。

> 注意：volatile阻止的不是singleton = newSingleton()这句话内部\[step1、step2、step3\]的指令重排，而是保证了在一个写操作（\[step1、step2、step3\]完成之前，不会调用读操作（if (instance == null)）。

### 2、基于饿汉模式的类初始化解决方案 ###

该解决方案的根本就在于：**利用classloder的机制来保证初始化**singleton**时只有一个线程。JVM在类初始化阶段会获取一个锁，这个锁可以同步多个线程对同一个类的初始化**。

public class Singleton {
        private static class SingletonHolder{
            public static Singleton singleton = new Singleton();
        }
    
        public static Singleton getInstance(){
            return SingletonHolder.singleton;
        }
    }

这种解决方案的实质是：运行步骤2和步骤3重排序，但是不允许其他线程看见。缺点就是有可能singleton在整个程序运行生命周期都没有用到。

# #

## 3、内部类解决 ##

public class Singleton {
    
        /**
         * 构造方法私有化
         */
        private Singleton(){
        }
        
        private static class SingleHolder{
            private static final Singleton singleton = new Singleton();
        }
    
        /**
         * 内部类方式获取单例
         * @return
         */
        public static Instance getInstance(){
            return SingleHolder.singleton;
        }
        
    }

这种从jvm虚拟机上保证了单例，并且也是懒式加载。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70]: /images/20220717/885d08680f604771b55018e298e92f92.png
[java_2_volatile]: https://guisu.blog.csdn.net/article/details/112064787