源码篇 预防针💉：
源码篇 必然会有很多代码，希望大家不要有畏难情绪，虽然我也是看到一大串代码就头疼。 我贴代码只是为了方便我的文字解答，源码只是辅助我文字讲解，所以大家尽量关注我的文字就好啦。
前言
在上一篇文章中，我们得知了 ReentrantReadWriteLock 给每个线程都维护了一个 ThreadLocal 类型的 HoldCount 对象，用来维护每个线程的读锁重入次数。
然后我留下了一些疑问：
-
为什么每个线程都维护了 HoldCounter，还需要额外维护一个 firstReader ？
-
为什么需要特意维护 CacheHoldCounter？
为什么需要特意维护 firstReader 和 cacheHoldCount
为什么 ReentrantReadWriteLock 特意维护了 第一个线程 和 最后一个 获取锁成功的线程？
只维护头和尾能带来性能上的提升吗？具体体现在哪里？
ThreadLocal 的查询
我们先来看 为什么需要
cacheHoldCount
在源码 fullTryAcquireShared 方法中其实我们可以看到有这么一个注释：
显然 cacheHoldCounter 是为了 释放锁 而特意维护的。
那 cacheHoldCounter 究竟能帮助我们怎么去优化 释放锁 呢？
看到这里基本上就是真相大白了。
cachedHoldCounter 是用来优化 锁释放时 的 ThreadLocal 查找的。
而且这里提到了一个普遍的例子就是：通常来说需要释放的线程，就是最后一个获取锁的线程。
在这种场景下，我们就不需要去通过 ThreadLocal 去查，而是直接通过我们这个 cacheHoldCounter。
那为什么需要维护
firstReader捏？
通过注释其实是不太好找到线索的。
但是我们可以先确定的一件事就是，firstReader 肯定能起到跟 cachHoldCounter 的作用，也就是在优化了在 ThreadLocal 的查找。
tryReleaseShared读锁释放逻辑：
ThreadLocal 的内存溢出风险
我们通过
jdk的git历史提交记录可以看到，这个firstReader其实是后来才加进来的。
Excessive ThreadLocal storage used by ReentrantReadWriteLock。
大概意思就是：ReentrantReadWriteLock 用 ThreadLocal 太多了。
ThreadLocal 虽然是一个好东西，但是它有一个非常大的问题就是它存在 内存溢出 的风险。
现在多加了一个 firstReader，相当于是一把 ReentrantReadWriteLock 就优化一个 ThreadLocal 变量。
积少成多，也是对性能比较极致的追求。
而且我们还可以看到这个提交记录中还包括了对锁中的 ThreadLocal 对象手动清除： readHolds.remove()。
这属于是一个 bug，也是在这次提交中修复了。
感兴趣的大兄弟可以去具体 oracle 官网查看：Bug ID: JDK-6625723 Excessive ThreadLocal storage used by ReentrantReadWriteLock (java.com)
总结
为什么需要
cacheHoldCounter?
cacheHoldCounter 是维护最后一个成功获取到锁的线程。
维护它是为了在 锁释放 中减少对于 ThreadLocal 的查询。
为什么需要
firstReader？
目的是为了优化 读写锁 中对 ThreadLocal 的过度使用导致内存溢出问题。
在早期设计 读写锁 中是没有 firstReader，后来人们提出他对于 ThreadLocal 的使用已经达到了 滥用 这个级别。
但是又不得不用 ThreadLocal，所以 Doug Lea 采用了维护一个 firstReader 的方法，尽可能地去减少这个内存的占用。
同时 fistReader 在 锁释放 的时候也可以优化 ThreadLocal 的查询。
参考
来都来了，点个赞，留个言再走吧彦祖👍，这对我来说非常重要！