在看Nacos的源代码时,发现多处都应用了“双重查看锁”的机制,算是十分好的实际案例。这篇文章就着案例来剖析一下双重查看锁的应用以及劣势所在,目标就是让你的代码格调更加高一个档次。
同时,基于单例模式,解说一下双重查看锁的演变过程。
Nacos中的双重查看锁
在Nacos的InstancesChangeNotifier类中,有这样一个办法:
private final Map<String, ConcurrentHashSet<EventListener>> listenerMap = new ConcurrentHashMap<String, ConcurrentHashSet<EventListener>>();private final Object lock = new Object();public void registerListener(String groupName, String serviceName, String clusters, EventListener listener) { String key = ServiceInfo.getKey(NamingUtils.getGroupedName(serviceName, groupName), clusters); ConcurrentHashSet<EventListener> eventListeners = listenerMap.get(key); if (eventListeners == null) { synchronized (lock) { eventListeners = listenerMap.get(key); if (eventListeners == null) { eventListeners = new ConcurrentHashSet<EventListener>(); listenerMap.put(key, eventListeners); } } } eventListeners.add(listener);}
该办法的次要性能就是对监听器事件进行注册。其中注册的事件都存在成员变量listenerMap当中。listenerMap的数据结构是key为String,value为ConcurrentHashSet的Map。也就是说,一个key对应一个汇合。
针对这种数据结构,在多线程的状况下,Nacos解决流程如下:
- 通过key获取value值;
- 判断value是否为null;
- 如果value值不为null,则间接将值增加到Set当中;
- 如果为null,就须要创立一个ConcurrentHashSet,在多线程时,有可能会创立多个,因而要应用锁。
- 通过synchronized锁定一个Object对象;
- 在锁内再获取一次value值,如果仍然是null,则进行创立。
- 进行后续操作。
上述过程,在锁定前和锁定之后,做了两次判断,因而称作”双重查看锁“。应用锁的目标就是防止创立多个ConcurrentHashSet。
Nacos中的实例略微简单一下,上面以单例模式中的双重查看锁的演变过程。
未加锁的单例
这里间接演示单例模式的懒汉模式实现:
public class Singleton { private static Singleton instance; private Singleton() { } public Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }
这是一个最简略的单例模式,在单线程下运行良好。但在多线程下会呈现显著的问题,可能会创立多个实例。
以两个线程为例:
能够看到,当两个线程同时执行时,是有可能会创立多个实例的,这很显著不合乎单例的要求。
加锁单例
针对上述代码的问题,很直观的想到是进行加锁解决,实现代码如下:
public class Singleton { private static Singleton instance; private Singleton() { } public synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; }}
与第一个示例惟一的区别是在办法上增加了synchronized关键字。这时,当多个线程进入该办法时,须要先取得锁能力进行执行。
通过在办法上增加synchronized关键字,看似完满的解决了多线程的问题,但却带了性能问题。
咱们晓得应用锁会导致额定的性能开销,对于下面的单例模式,只有第一次创立时须要锁(避免创立多个实例),但查问时是不须要锁的。
如果针对办法进行加锁,每次查问也要承当加锁的性能损耗。
双重查看锁
针对下面的问题,就有了双重查看锁,示例如下:
public class Singleton { private static Singleton instance; private Singleton() { } public Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; }}
第一,将锁的范畴放大的办法内;
第二,锁之前先判断一下是不是null,如果不为null,阐明曾经实例化了,间接返回,没必要进行创立;
第三,如果为null,进行加锁,而后再次判断是否为null。为什么要再次判断?因为一个线程判断为null之后,另外一个线程可能曾经创立了对象,所以在锁定之后,须要再次核实一下,真的为null,则进行对象创立。
改良之后,既保证了线程的安全性,又防止了锁导致的性能损失。问题到此结束了吗?并没有,持续往下看。
JVM的指令重排
在某些JVM当中,编译器为了性能问题,会进行指令重排。在上述代码中new Singleton()并不是原子操作,有可能会被编译器进行重排操作。
创建对象可形象为三步:
memory = allocate(); //1:调配对象的内存空间 ctorInstance(memory); //2:初始化对象 instance = memory; //3:设置instance指向刚调配的内存地址
下面操作中,操作2依赖于操作1,但操作3并不依赖于操作2。因而,JVM是能够进行指令重排优化的,可能会呈现如下的执行程序:
memory = allocate(); //1:调配对象的内存空间 instance = memory; //3:instance指向刚调配的内存地址,此时对象还未初始化ctorInstance(memory); //2:初始化对象
指令重排之后,将操作3的赋值操作放在了后面,那就会呈现一个问题:当线程A执行完步骤赋值操作,但还未执行对象初始化。此时,线程B进来了,在第一层判断时发现Instance曾经有值了(实际上还未初始化),间接返回对应的值。那么,程序在应用这个未初始化的值时,便会呈现谬误。
针对此问题,可在instance上增加volatile关键字,使得instance在读、写操作前后都会插入内存屏障,防止重排序。
最终,单例模式实现如下:
public class Singleton { private static volatile Singleton instance; private Singleton() { } public Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; }}
至此,一个欠缺的单例模式实现了。此时,你是否有一个疑难,为什么Nacos中的双重查看锁没有应用volatile关键字呢?
答案很简略:下面单例模式如果呈现指令重排,会导致单例实例被应用。那么,再看Nacos的代码,因为创立ConcurrentHashSet并不会影响到查问,而真正影响查问的是listenerMap.put办法,而ConcurrentHashSet自身是线程平安的。因而,也就不会呈现线程平安问题,不必应用volatile关键字了。
小结
浏览源码最有意思的一个中央就是能够看到很多经典常识的实际,如果可能深刻思考,拓展一下,会取得意想不到的播种。
再回顾一下本文的重点:
- 浏览Nacos源码,发现双重查看锁的应用;
- 未加锁单例模式应用,会创立多个对象;
- 办法上加锁,导致性能降落;
- 代码内部分加锁,双重判断,既满足线程平安,又满足性能需求;
- 单例模式特例:创建对象分多步,会呈现指令重排景象,采纳volatile进行防止指令重排;
最初,想学习更多相似干货,关注一下吧,继续输入。
博主简介:《SpringBoot技术底细》技术图书作者,热爱钻研技术,写技术干货文章。
公众号:「程序新视界」,博主的公众号,欢送关注~
技术交换:请分割博主微信号:zhuan2quan