Eureka的读写锁机制是设计初衷还是隐藏bug？

本文共计3980个文字，预计阅读时间需要16分钟。

在读写锁的认知中，我们都认为读时加读锁，写时加写锁，以保证读写和写写互斥，从而实现读写安全。但在我翻阅Eureka源码时，发现Eureka在读取数据时实际上并未使用读锁。

在对于读写锁的认识当中，我们都认为读时加读锁，写时加写锁来保证读写和写写互斥，从而达到读写安全的目的。但是就在我翻Eureka源码的时候，发现Eureka在使用读写锁时竟然是在读时加写锁，写时加读锁，这波操作属实震惊到了我，Eureka到底是故意为之还是一个bug？于是我就花了点时间研究了一下Eureka的这波操作。

Eureka服务注册实现类

众所周知，Eureka作为一个服务注册中心，肯定会涉及到服务实例的注册和发现，从而肯定会有服务实例写操作和读操作，这是每个注册中心最基本也是最核心的功能。

AbstractInstanceRegistry

如上图，AbstractInstanceRegistry是注册中心的服务注册核心实现类，这里面保存了服务实例的数据，封装了对于服务实例注册、下线、读取等核心方法。

这里讲解一下这个类比较重要的成员变量

服务注册表

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

注册表就是存储的服务实例的信息。Eureka是使用ConcurrentHashMap来进行保存的。