什么是读写锁？微服务注册中心是如何进行读写锁优化的？ _读写锁

本文转载自公众号：石杉的架构笔记

作者：中华石杉，十余年BAT架构经验倾囊相授。个人微信公众号：石杉的架构笔记（ID：shishan100）

一、读写锁的介绍
本文我们来聊一下读写锁。所谓的读写锁，就是将一个锁拆分为读锁和写锁两个锁，然后加锁的时候，可以加写锁，也可以加读锁。
如下面代码所示：

文章插图

如果有一个线程加了写锁，那么其他线程就不能加写锁了，同一时间只能允许一个线程加写锁。
因为加了写锁就意味着有人要写一个共享数据，那同时就不能让其他人来写这个数据了。
如果有线程加了写锁，其他线程就不能加读锁了，因为既然都有人在写数据了，你其他人当然不能来读数据了！
如果有一个线程加了读锁，别的线程是可以同时加读锁的，因为只是有线程在读数据而已，此时别的线程也是可以来读数据的！
同理，如果一个线程加了读锁，此时其他线程是不可以加写锁的，因为既然有人在读数据，那就不能让你随意来写数据了！
好了！这个就是初步介绍一下读写锁的使用方法，相信很多同学应该之前都知道了，因为这个是JAVA开发中非常基础的一块知识。
二、微服务注册中心的读写锁优化
【什么是读写锁？微服务注册中心是如何进行读写锁优化的？】现在进入主题，我们主要聊一下微服务注册中心里面的读写锁优化。
为什么要聊这个问题？
因为如果你出去面试，很可能被问到读写锁的问题，此时你可以自然的带出来，你之前了解过Spring Cloud微服务技术架构，同时对里面的微服务注册中心的注册表读写锁优化有一些自己的感悟和看法。
这样的话，相比于你简单的给面试官聊聊读写锁的基本概念和使用方法，要增色不少！
首先，大家需要了解一点微服务的整体架构知识，可以参考之前写过的一篇文章拜托，面试请不要再问我Spring Cloud底层原理！。
同时还需要了解一下Spring Cloud Eureka（即微服务注册中心）的核心原理。
这个可以参考之前写过的一篇文章【双11狂欢的背后】微服务注册中心是如何承载大型系统千万级访问的。
了解了这些前置知识之后，我们正式开始。
先来看看下面的图，现在我们知道一个微服务注册中心（可以是Eureka或者Consul或者你自己写的一个微服务注册中心）肯定会在内存中有一个服务注册表的概念。
这个服务注册表中存放了各个微服务注册时发送过来的自己的地址信息，里面保存了每个服务有多少个服务实例，每个服务实例部署在哪台机器上监听哪个端口号，主要是这样的一些信息，如下图所示：

文章插图

那现在问题来了，这个服务注册表的数据，其实是有人读也有人写的，对不对？
举个例子，比如有的服务启动的时候会来注册，此时就会修改服务注册表的数据，这个就是写的过程。
接着，别的服务也会来读这个服务注册表的数据，因为每个服务都需要感知到其他服务在哪些机器上部署。
所以，这个内存里的服务注册表数据，天然就是有读写并发问题的！可能会有多个线程来写，也可能会有多个线程来读！
如果你对同一份内存中的注册表数据不加任何保护措施，那么可能会有多线程并发修改共享数据的问题，可能导致数据错乱，对吧？
上述过程，大家看看下面的图，就明白了。

文章插图

此时你可能会想，如果对服务注册表的服务注册和读取服务注册表的方法，都加一个synchronized关键字，不就可以了？
你也许会说，加上synchronized，直接让所有线程对服务注册表的读写操作，全部串行化。那不就可以保证内存中的服务注册表数据安全了吗？
下面是一段伪代码，大家来感受一下：