关于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提交记录发现一些端倪：

![jdk提交记录](https://img-blog.csdnimg.cn/20210416000954923.png?x-oss-process=image/water

必看视频！获取2024年最新Java开发全套学习资料 备注Java

mark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)

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

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

下面大概的意思说，国外有个兄弟使用jdk1.6的ReentrantReadWriteLock出现内存占用很大的问题，而之前用jdk1.5时好好的，m是锁的个数，n是每个锁持有的线程数，每个线程有一个内部有一个ThreadLocal来记录锁重入，这样就会有m*n个内存占用，而且jdk1.6还存在bug，没有主动调用remove使得ThreadLocal内存泄漏，应该就是这个原因导致这位兄弟在使用的过程中出现内存占用很大的问题。后面还给了一个测试：

完结

Redis基于内存，常用作于缓存的一种技术，并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中，使用最广泛的缓存，在工作中常常会使用到。Redis也是中高级后端工程师技术面试中，面试官最喜欢问的问题之一，因此作为Java开发者，Redis是我们必须要掌握的。

Redis 是 NoSQL 数据库领域的佼佼者，如果你需要了解 Redis 是如何实现高并发、海量数据存储的，那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。

高并发、海量数据存储的，那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。

[外链图片转存中…(img-sZBoOdsc-1716357013465)]