前言
读了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的网站
下面大概的意思说，国外有个兄弟使用jdk1.6的ReentrantReadWriteLock出现内存占用很大的问题，而之前用jdk1.5时好好的，m是锁的个数，n是每个锁持有的线程数，每个线程有一个内部有一个ThreadLocal来记录锁重入，这样就会有m*n个内存占用，而且jdk1.6还存在bug，没有主动调用remove使得ThreadLocal内存泄漏，应该就是这个原因导致这位兄弟在使用的过程中出现内存占用很大的问题。后面还给了一个测试：
官方给出了回答，看着有些敷衍，但又有些无奈，承认有问题，但是不能去掉每个线程的ThreadLocal计数，尽量会减少这个内存的占用，同时会加一个构造器让使用者可以显式的关闭还是开启追踪每个线程的计数的功能。
但是没有看到官方说的加个显式开关，只是把第一个线程不使用
ThreadLocal了，同时修了bug（这个很重要）。再次思考第一个线程不使用ThreadLocal有哪些作用：
- 在一定程度上确实可以减少
ThreadLocal的使用，降低一些内存吧，假设有50000个锁，就可以最多减少50000个ThreadLocal的内存。 - 对于无竞争时，只有一个线程获取读锁的计数省去了去
ThreadLocal中查找而性能高效。但是一般情况都是有竞争的，所以实际收效甚微。 - 获取当前线程的读锁重入次数，若是第一个线程则可以免去
ThreadLocal中查找，也能提高一点性能。
启发，源码应该这么看
java的源码是优美的，有很多值得斟酌的地方，有时候一些细节get不到作者的思路，国内论坛又少有人深究，都做了拿来主义，人云亦云，道听途说，做学问不可，需要真理！
方法论很重要，看源码提交的记录，看当时作者修改的意图，然后去国外的网站查找，是一个不错的办法。在github上openjdk官方已经开源了，可以clone到本地，看每个文件的提交记录，介于github有时打不开或者很慢，我把jdk源码clone到码云上了，jdk gitee：gitee.com/stefanpy/jd…。
再次感谢和我一起讨论的大佬朋友，良师益友，受益良多。
PS: 如若文章中有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。我是徐同学，愿与你共同进步！
