关于ReentrantReadWriteLock，首个获取读锁的线程单独记录问题讨论（该如何更好的阅读源码

---

读了ReentrantReadWriteLock的源码，知道读写锁共用一个state，低16位表示写锁的状态和重入，高16位表示读锁的状态，右移16位表示持有读锁的线程数，那么该读锁是如何记录每个线程的重入呢？

本篇不是科普ReentrantReadWriteLock的读锁怎么记录重入，而是讨论官方为什么要把第一个获取读锁的线程单独拎出来记录重入次数？想了解ReentrantReadWriteLock更多源码细节请移步《AQS源码解读（七）——ReentrantReadWriteLock原理详解》

firstReader表示第一个获取读锁的线程，若当前线程等于firstReader，读锁重入时firstReaderHoldCount+1，而非首个获取读锁的线程则用一个继承了ThreadLocal的内部类ThreadLocalHoldCounter给每个线程计数。为什么第一个线程不用ThreadLocalHoldCounter计数呢？单独拎出来的意义何在？

源码再现

---

ReadLock的获取和释放都需要区分对待首个获取读锁的线程，为什么第一个线程不也用ThreadLocal计数呢？

姑且看看firstReader和firstReaderHoldCount+1还用在哪里？获取当前线程读锁重入次数有用到，难道是为了提升一丝丝性能？再无其他用处？没有太get到作者的脑回路啊。

发现端倪

---

昨日正好一个朋友也在研究AQS读写锁的源码，对此有同样的疑问，大佬牛逼啊，对比了jdk提交记录发现一些端倪：

该条更新记录是Doug lea提的，备注：Excessive ThreadLocal storage used by ReentrantReadWriteLock，意思就是ReentrantReadWriteLock用的ThreadLocal太多了，然后看更新对比，多了firstReader（最新的源码记录线程id了，不记录线程对象）和firstReaderHoldCount，这么说原先都是用ThreadLocal计数的，为什么要这么改？而且Doug lea顺便还修了一个bug，在jdk1.6时，释放完锁ThreadLocal不用时没有调用remove，这就有可能导致内存泄漏啊！

我这位大佬朋友也真是大佬，直接搜了提交记录前的一串数字6625723，哈哈，好像找到了专门记录java bug的网站

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

最后

现在正是金三银四的春招高潮，前阵子小编一直在搭建自己的网站，并整理了全套的**【一线互联网大厂Java核心面试题库+解析】：包括Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等**

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
[外链图片转存中…(img-deMGmNOW-1712707364600)]