读写锁的简单介绍
所谓的读写锁，就是将一个锁拆分为读锁和写锁两个锁，然后你加锁的时候，可以加读锁，也可以加写锁。
ReentrantLock lock=new ReentrantLock();
lock.wirteLock.lock();
lock.wirteLock.unlock();
lock.readLock.lock();
lock.readLock.unlock();如果有一个现场加了写锁，那其他线程就不能加写锁了，同一时间只允许一个线程加锁，因为加了写锁的就意味着有人要写一个共享数据，那同时就不能让全体人来写这个数据了。
同时如果有线程加了写锁，其他线程也不能加读锁了，因为既然都有人在写数据了，你其他人当然不能来读数据了。
如果有一个线程加了读锁，别的线程是可以随意加读锁的，因为只是有线程在读数据，其他线程也可以来读数据。
同时如果一个线程加了读锁，此时其他线程是不可以加写锁的，因为既然有人在读数据了，就不能随便让你来写数据了。
微服务注册中心的读写锁优化
我们知道，微服务的注册中心在内存中，肯定会有一个服务注册表的概念。这个服务注册表存放了各个微服务注册时候发来的自己的地址信息，里面保存了服务有多少个服务实例，每个服务实例部署在哪台机器山监听哪个端口号，主要是这样的信息。
OK，那现在问题来了，这个服务注册表的数据，有人读，也有人写。
比如：有的服务器启动的时候回来猪儿，此时要修改服务注册表的数据。这个就是写的过程。
接着，别的服务也会来读取这个服务注册表的数据，因为每个服务都需要感知其他服务在哪些机器山部署。
所以这个内存里的服务注册表的数据，天然就是有并发读写问题的，可能会有多个检查来写，也可能会有多个线程来读。
如果你对同一份注册表的数据，不加任何的保护措施，那可能存在多线程并发修改共享数据的问题，可能导致数据错乱。
1、可以考虑加synchronized,直接让所有线程对服务注册表的读写操作，全部串行化。
这种做法，太暴力了，在并发的场景下，性能也不会很高。
2、使用读写锁。
一旦有人在写服务器注册表的数据，我们就加一个写锁，此时别人不能写，也不能读。
一旦有人在读数据，此时可以让别人读，但是不允许别人写。
这样做的好处是：我们的业务大部分都是读操作，写数据的场景比较少，此时写数据，使用读锁可以让大量线程同时来读数据，不需要阻塞不需要排队，保证高并发的读写性能比较高。
然后少量的场景，可以加写锁，一个一个写。
还有一个问题，就是大量加读锁的阻塞，会导致写数据时间过长，这种情况能否避免呢，就是通过多级缓存机制来避免。
伪代码如下：
public class ServiceRegistry {
//服务注册表
private Map> registry=new HashMap<>();
//针对注册表准备的读写锁
private ReentrantReadWriteLock lock=new ReentrantReadWriteLock();
private ReentrantReadWriteLock.WriteLock writeLock=lock.writeLock();
private ReentrantReadWriteLock.ReadLock readLock=lock.readLock();
public void register(){
writeLock.lock();
//将服务实例信息写入到内存中
writeLock.unlock();
}
public Map> getRegistry(){
readLock.lock();
//返回服务注册表的数据
readLock.unlock();
}
}
