下面我们来谈一下双重检查锁定与延迟初始化
volatile解决重排序问题
在前面学习懒汉模式实现单例模式的时候,我们已经使用过下面的这一套优化流程了
- 代码块中加锁判断单例对象是否已经初始化
- 如果已经初始化,直接返回单例对象
- 再进行判断多一次单例对象是否已经初始化,来判断单例模式对象是否已经初始化,因为可能同时有多个线程判断出单例对象未初始化,这时上一把锁,让一个线程进去初始化了,初始化了之后,应该再让其他线程再判断一次,看前面一个线程初始化没有(感觉这个方案可以解决一下缓存雪崩)
- 如果已经初始化,返回单例对象
- 给单例对象加volatile修饰,防止其构造指令出现重排序
代码如下(instance记得要被volatile修饰)
类初始化解决重排序问题
上面使用volatile可以解决重排序问题,在这里也是可以用类来解决重排序问题的
JVM在类的初始化阶段时,即在Class被加载后,且正在被线程使用之前,会执行类的初始化(初始化静态变量),在执行类的初始化期间,JVM会去获取一个锁,这个锁可以同步多个线程对同一个类的初始化,总的来说,就是利用类的初始化这个机制,让实例变量初始化的时候可以发生重排序,但其他线程看不到这个重排序,必须要等待完成整个类初始化过程才可以被访问这个类
还是以单例模式为例
要用类初始化来实现单例模式,其实就是使用静态内部类
当多个线程调用getInstance时候,会发生阻塞(JVM获得锁),只有一个线程可以去加载初始化这个InnerSIngle类,然后该线程初始化里面的single静态变量
类初始化过程中的同步机制
下面来看一下JVM是怎么保证类初始化过程中的同步
第一阶段
第一阶段是:通过在Class对象上进行同步(即获取Class对象的初始化锁),来控制类或者接口的初始化,当多个线程初始化同一个类的时候,只有一个线程可以获得这个Class对象的初始化锁,其他线程会一直等待获取锁的线程去释放锁
第二阶段
第二阶段是:抢到类的初始化锁的线程去执行初始化,未抢到锁的线程在初始化锁对应的condition上等待,相当于是等待抢到类的初始化锁的线程去完成初始化动作
初始化的动作先简单理解成是执行类的静态初始化代码和初始化类中声明的静态字段,底层方面的知识是涉及到JVM相关知识的
过程如下所示
第三阶段
第三阶段是:获取到锁的线程去唤醒在condition中等待的所有线程,提醒这些线程,类已经初始化好了
第四阶段
第四阶段是:被唤醒的线程结束自己对类的初始化处理
第五阶段
第五阶段是:后面的线程如果再对类进行初始化,那么只会简单的获取锁,发现已经被初始化好了,释放锁,直接获取类
volatile与类初始化的两个方案之间存在什么区别
区别如下
- 类初始化的代码比较简单、间接
- 不过类初始化只能针对静态字段来实现延迟初始化
- volatile不仅可以针对静态字段实现延迟初始化,还可以针对实例字段来实现延迟初始化